本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

其他考量

本節涵蓋不是特定於 Java EE 應用程式的 Java 容器化的一般考量事項。

使用小基礎映像

建議您建立小型 (小於 500 MB) 且維護良好的基礎映像。減少基礎映像大小可降低網路和作業成本。較小的基礎映像也可透過減少可利用的元件數量來提高安全性。可以使用基於 Debian 的 distroless 映像之一。這些映像上安裝了最少數量的工具，並且不包含軟件包管理器或 shell。這些 distroless 映像也減少了整體攻擊表面。Distroless 影像可以小於 150 MB。如需詳細資訊，請參閱 Distroless 容器映像 GitHub 儲存庫。

最佳實務是遵循處置原則，並為您的容器映像制定快速啟動時間。透過使用諸如提前編譯 (OpenJDK 文件) 或應用程式類別資料共用 (OpenJDK 文件)，您可以在啟動虛擬機器之前將 Java 類別編譯成原生程式碼並允許將一組類別預先處理為共用封存檔案，藉此改善整體啟動時間。也可使用 GraalVM 為 Java 應用程式建置最小的 Docker 映像檔。如需詳細資訊，請參閱使用 GraalVM 為 Java 應用程式建置最小 Docker 映像 AWS 部落格文章。

升級至容器感知的 JDK 版本

在 JDK 8u131 之前，JVM 無法識別 Docker 引擎使用標記設定的記憶體或 CPU 限制。這意味著每當您在容器中執行應用程式時，JVM 都會「看到」系統上可用的處理器總數，如果是虛擬機，則為虛擬系統。預設記憶體限制也是如此：JVM 將查看主機的整體記憶體並將它用於設定其預設值。因此，JVM 可以請求比容器平台允許的更多記憶體，這會導致容器平台 (Docker) 結束 Java 處理序。解決此問題的一種方法是在容器化之前將 Java 應用程式遷移到 Java 9 或 8u131+。Java 10 及更高版本具有完整的容器感知和支援。