這是一個非常關鍵且常被忽視的問題。在容器化（Docker / Kubernetes）環境中運行 Java 應用時，是否使用 -XX:MaxRAMPercentage（或舊版 -XX:MaxRAMFraction）直接決定了 JVM 能否正確感知容器內存限制。

✅ 正確做法：必須使用 MaxRAMPercentage

為什麼？

• JVM 默認按物理機總內存計算堆大小
  例如：宿主機有 32GB 內存，即使你的容器 limit 只有 2GB，JDK 8~10 的 JVM 仍可能嘗試分配 8GB 堆 → 超出容器限制 → 被 OOMKilled。
• 從 JDK 8u191 和 JDK 10 起，JVM 支持容器感知（UseContainerSupport）
  啓用後，JVM 會讀取 cgroup 的內存限制（如 Docker 的 -m 2g 或 K8s 的 resources.limits.memory），並據此計算堆大小。

推薦配置：

java \
  -XX:+UseContainerSupport \          # 默認已開啓（JDK 8u191+）
  -XX:MaxRAMPercentage=75.0 \         # 堆佔容器內存的 75%
  -XX:MaxMetaspaceSize=256m \         # 非堆也需限制
  -jar app.jar

📌 MaxRAMPercentage=75.0 是最佳實踐：
留出 25% 內存給：

• Metaspace（類元數據）
• 線程棧（每個線程約 256KB~1MB）
• 直接內存（NIO、Netty）
• JVM 本身開銷

❌ 錯誤做法：硬編碼 -Xmx

# 危險！不要這樣做！
CMD ["java", "-Xmx4g", "-jar", "app.jar"]

後果：

• 容器 limit = 2GB，但 JVM 試圖用 4GB → 立即被 kill
• 即使 limit = 4GB，Metaspace + 線程棧 + 直接內存可能超限 → 運行一段時間後 OOMKilled

🔍 如何驗證你的應用是否正確配置？

方法 1：查看 JVM 實際堆大小

進入容器執行：

jcmd <pid> VM.flags | grep -E "MaxRAMPercentage|Xmx"

或

java -XX:+PrintFlagsFinal -version | grep -E "MaxRAMPercentage|MaxHeapSize"

方法 2：檢查容器內存使用

# 查看容器內存 limit
cat /sys/fs/cgroup/memory/memory.limit_in_bytes

# 查看 JVM 堆最大值（應 ≈ limit * 0.75）
jstat -gc <pid>  # 查看 NGCMX / OGCMX

方法 3：模擬 OOM 場景

故意設置過高的 MaxRAMPercentage=90.0，觀察是否在接近容器 limit 時被 kill。

📊 不同 JDK 版本的支持情況

⚠️ 注意：即使 UseContainerSupport 默認開啓，仍需顯式設置 MaxRAMPercentage，因為默認值可能不合理（如 JDK 8 默認按物理機 1/4 計算）。

💡 最佳實踐總結

1. 永遠不要在容器中硬編碼 -Xmx
2. 始終使用 -XX:MaxRAMPercentage=70.0~75.0
3. 同時限制非堆內存：

-XX:MaxMetaspaceSize=256m
-XX:MaxDirectMemorySize=256m

1. K8s 中合理設置 requests/limits：

resources:
  limits:
    memory: "2Gi"
  requests:
    memory: "1.5Gi"

✅ 結論

如果你的容器化 Java 應用沒有使用 -XX:MaxRAMPercentage，那麼你正在“裸奔”——隨時可能因內存超限被系統殺死。

請立即檢查你的啓動腳本，並在所有容器化部署中加入該參數。這是保障 Java 應用在雲原生環境中穩定運行的最基本、最重要的一步。