因記憶體不足問題所造成的應用程式重新開機問題
注意
基本、標準和企業方案將從 2025 年 3 月中旬開始淘汰，並停用 3 年。 建議您轉換至 Azure Container Apps。 如需詳細資訊，請參閱 Azure Spring Apps 淘汰公告。
標準 耗用量和專用 方案將從 2024 年 9 月 30 日起淘汰，並在六個月後完成關閉。 建議您轉換至 Azure Container Apps。 如需詳細資訊，請參閱 將 Azure Spring Apps 標準取用和專用方案遷移至 Azure Container Apps。
本文適用於：✅ 基本/標準 ✅ 企業
本文說明 Azure Spring Apps 中 JAVA 應用程式的記憶體不足 (OOM) 問題。
記憶體不足問題的類型
記憶體不足的問題有兩種：容器 OOM 和 JVM OOM。
容器 OOM 也稱為系統 OOM，會在可用的應用程式記憶體用盡時發生。容器 OOM 問題會導致應用程式重新啟動事件，這些事件會在 Azure 入口網站的 [資源健康情況] 區段中回報。 通常，容器 OOM 是因不正確的記憶體大小設定所造成。
當已使用記憶體的數量達到 JVM 選項中所設定的大小上限時，就會發生 JVM OOM。 JVM OOM 不會造成應用程式重新開機。 一般而言，JVM OOM 是錯誤程式碼所造成的結果，您可以在應用程式記錄中尋找
java.lang.OutOfMemoryError例外狀況來找到它。 JVM OOM 對應用程式和 JAVA 分析工具 (例如 JAVA Flight Recorder) 有負面影響。
本文著重於如何修正容器 OOM 問題。 若要修正 JVM OOM 問題，請檢查堆積傾印、執行緒傾印和 JAVA Flight Recorder 等工具。 如需相關資訊，請參閱手動擷取堆積傾印和執行緒傾印，並在 Azure Spring Apps 中使用 Java Flight Recorder。
修正因 OOM 而導致的應用程式重新開機問題
下列各節說明您可用來診斷和修正容器 OOM 問題的工具、計量和 JVM 選項。
檢視 [資源健康情況] 頁面上的警示
Azure 入口網站上的 [資源健康情況] 頁面會顯示因容器 OOM 所造成的應用程式重新開機事件，如下列螢幕擷取畫面中所示：
設定記憶體大小
應用程式記憶體用量、jvm.memory.used 及 jvm.memory.committed 計量提供了記憶體使用量的檢視畫面。 如需相關資訊，請參閱排解記憶體疑難問題的工具的計量區段。 在 JVM 選項中設定記憶體大小上限，以確保記憶體低於限制量。
JAVA 記憶體模型中所有部分的最大記憶體大小總和應該小於實際可用的應用程式記憶體。 若要設定記憶體大小上限，請參閱 JAVA 記憶體管理的記憶體使用量配置一節中所述的一般記憶體配置。
在設定記憶體大小上限時找到一個平衡點。 當您將記憶體大小上限設的太高時，會有發生容器 OOM 問題的風險。 若您將記憶體大小上限設的太低時，則會有發生 JVM OOM 問題的風險，而記憶體回收將會是造成應用程式變慢的原因且會減慢應用程式的速度。
控制堆積記憶體
您可以使用 -Xms、-Xmx、-XX:InitialRAMPercentage 及 -XX:MaxRAMPercentage JVM 選項來設定堆積大小的上限。
當 jvm.memory.used 的值在計量中太高時，您可能需要調整最大的堆積大小設定。 如需相關資訊，請參閱排解記憶體疑難問題的工具的 jvm.memory.used/committed/max 區段。
控制直接記憶體
請務必基於下列原因來設定 -XX:MaxDirectMemorySize JVM 選項：
- 當 nio 和 gzip 等架構在使用直接記憶體時，您可能不會注意到。
- 直接記憶體的記憶體回收只會在完整記憶體回收期間處理，而且只有在堆積接近滿時，才會進行完整記憶體回收。
通常，您可以將 MaxDirectMemorySize 設為小於 [應用程式記憶體大小減去堆積記憶體減去非堆積記憶體] 的值。
控制中繼空間
您可以透過設定 -XX:MaxMetaspaceSize JVM 選項來設定中繼空間大小的上限值。 -XX:MetaspaceSize 選項會設定臨界值來觸發完整的記憶體回收。
中繼空間記憶體通常穩定。