为什么在容器中的JVM还会OOM，不是说容器是可以自动扩缩容的嘛
容器确实提供了自动扩缩容的能力，但这种能力主要是指容器可以在运行时根据工作负载的变化动态地调整其CPU和内存资源限制。然而，这并不意味着JVM内的应用程序就可以无限制地使用内存。
在 K8S Pod 中，我们是否有必要指定 Java 堆大小配置
Java 提供了如下三组参数用于限制容器中 Java 堆内存占用大小
- -XX:MaxRAMFraction, -XX:MinRAMFraction
- -XX:MaxRAMPercentage, -XX:MinRAMPercentage
- -Xmx, -Xms
-
MaxRAMFraction/MinRAMFraction 版本支持：’-XX:MaxRAMFraction’, ‘-XX:MinRAMFraction’ JVM 参数仅支持从 Java 8 更新 131 到 Java 8 更新 190。因此，如果您使用任何其他版本的 JDK，则不能使用此选项。 如何配置：如果您打算使用“-XX:MaxRAMFraction” JVM 参数，请确保同时传递这两个额外的 JVM 参数“-XX:+UnlockExperimentalVMOptions -XX:+UseCGroupMemoryLimitForHeap”。只有当您传递这两个 JVM 参数时，JVM 才会从容器的内存大小派生堆大小值，否则，它将从底层主机的内存大小派生堆大小值。具体参考 默认情况下，JVM 分配大约 25% 的最大 RAM，因为 -XX:MaxRAMFraction默认为 4。
-
MaxRAMPercentage/MinRAMPercentage Java 8 update 191 及更高版本支持“-XX:MaxRAMPercentage”、“-XX: MinRAMPercentage” JVM 参数。因此，如果您在较旧的 JDK 版本上运行，则不能使用此 JVM 参数。
-Xmx/-Xms 这一对参数配置最大优点就是所有 JDK 版本都支持 -Xmx
配置建议：
- 容器内存 Request >= 1.25 * JVM 最大堆内存 ；
- 容器内存 Limit >= 2 * JVM 最大堆内存；
- 镜像中尽可能包含日常需要的工具，比如常见的 mysql-client、redis-client、网络工具等，当出现问题时，这些工具可能可以帮助你第一时间定位和发现问题。
- 如果您在容器内仅运行 Java 应用程序，则将初始堆大小与最大堆大小最好相等。如此设置会产生较低的垃圾收集暂停时间。因为每当堆大小从初始分配的大小增长时，会发生 STW。当您将初始和最大堆大小设置为相同时，它可以在一定程度上被规避。
- 配置 JVM 启动的垃圾收集日志打印并分析是否因容器中的新设置而受到影响。给出一个常用 GC 日志输出配置：-XX:+UseG1GC -XX:InitialRAMPercentage=75.0 -XX:MaxRAMPercentage=75.0 -XX:MinRAMPercentage=75.0 -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+PrintTenuringDistribution -XX:+PrintHeapAtGC -XX:+PrintReferenceGC -XX:+PrintGCApplicationStoppedTime -Xloggc:gc-%t.log -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=15 -XX:GCLogFileSize=50M
- 添加监控， 你可以可以选择 Prometheus，具体不在赘述具体实践参考[5] 或者其它 java 体系自带的监控，参考[6]
- 添加健康检查探针，帮助服务重启和启动过程的预热，但要根据实际情况配置探针的探测频率和超时时间，防止反复重启。Kubernetes生产环境最佳实践服务
- 添加优雅关闭，防止不必要的流量损失。K8s Pod优雅关闭，没你想象的那么简单！
目前启动脚本中的参数到底有没有起作用，如果没有是为什么？
-XX:+UnlockExperimentalVMOptions -XX:+UseCGroupMemoryLimitForHeap -XX:MaxRAMFraction=2 前两个参数告诉JVM身在何处。MaxRAMFraction控制最大堆内存占容器内存的比例，即容器内存/MaxRAMFraction，只能取整数。
参考： java容器化参数配置最佳实践
