容器环境中Java应用被OOMKilled杀掉，往往是两个原因叠加的结果：一是JVM堆内存配置没有正确适配容器的内存限制，二是应用本身存在缓慢的对象泄漏。前者是配置问题，改几个参数就能解决；后者才是真正的内存泄漏，需要通过堆转储分析找到泄漏源头。这篇文章把这两条线索拆开来讲，先解决配置层面的坑，再深入堆内存分析方法，最后落到GC调优上，形成一套完整的排查闭环。
容器内存限制与JVM参数：先排除配置层面的坑
很多人把OOMKilled误判为内存泄漏，其实容器被杀和堆内存溢出是两回事。OOMKilled是内核层面的行为：当Pod的内存用量触及limits上限时，cgroup会直接杀掉进程，JVM自己甚至来不及打出任何日志。而堆内存溢出会抛出java.lang.OutOfMemoryError，日志里有明确的堆栈信息。如果进程死得悄无声息，第一件事应该是检查容器的内存限制和JVM的内存结构是否匹配。
JVM进程占用的内存远不止堆，还包括元空间、线程栈、直接内存、JIT编译缓存等。一个常见的错误是给容器限制4G内存，同时配置-Xmx4g，这样堆本身就把限额吃满了，非堆部分没有任何余量，必然被杀。合理的比例是堆占容器限额的50%到75%。JDK 8u191以上的版本默认启用了容器感知，JVM能正确识别cgroup的限制，但显式配置仍然更稳妥：
# 容器限制4G内存的推荐配置
java -XX:MaxRAMPercentage=65.0 \
-XX:InitialRAMPercentage=65.0 \
-jar app.jar
# 或者直接指定堆大小，堆3G，留1G给非堆
java -Xms3g -Xmx3g -XX:MaxMetaspaceSize=256m \
-Xss1m -XX:ReservedCodeCacheSize=240m \
-jar app.jar另外要注意一个隐蔽的坑：直接内存。如果应用使用了Netty、Rocketty这类基于NIO的框架，MaxDirectMemorySize默认等于-Xmx的值，这部分内存不在堆里，GC日志完全看不到，但确实计入容器内存统计。建议显式限制它，比如-XX:MaxDirectMemorySize=512m，避免它成为压垮容器的最后一根稻草。
堆转储分析：用证据定位泄漏对象
配置确认无误之后，如果堆内存依然只涨不降，就要怀疑真正的内存泄漏了。定位泄漏的核心手段是堆转储（Heap Dump），它是某一时刻堆内所有对象的完整快照。获取转储有两种时机：一种是在OOM时自动生成，配置-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/dumps/，注意这个路径要挂载到宿主机或emptyDir卷上，否则容器一销毁文件就没了；另一种是在运行中手动触发，用jmap -dump:live,format=b,file=heap.hprof <pid>，其中live参数会先触发一次Full GC再转储，拿到的快照只含存活对象，分析起来干扰更少。不过要警惕生产环境执行jmap的代价：一个3G的堆生成转储可能让应用停顿十几秒，还会瞬间占用几个G的磁盘，最好在低峰期或摘掉流量的实例上操作。
拿到hprof文件后，推荐用Eclipse MAT分析。打开文件后先看 Leak Suspects 报告，它会自动列出疑似泄漏点。重点看两个指标：一是 Dominator Tree（支配树），按对象保留内存排序，排在前面的对象就是内存占用的主要来源；二是 GC Roots 引用链，顺着链路往上找，能定位到是哪个类、哪个集合、哪个线程持有了大量对象。
一个典型的泄漏报告长这样：某个本地缓存Map占了40%的堆，引用链指向一个只增不删的静态Map。分析时可以结合代码确认三类常见源头：一是无界缓存，比如自己写的静态HashMap做缓存却从不淘汰，应改用Caffeine并设置最大条目数；二是监听器或回调未注销，对象被注册到全局事件总线后一直被引用；三是ThreadLocal在线程池场景下没有remove，线程不销毁导致Entry永远无法回收。确认源头后修复代码，再通过压测验证堆内存能否在GC后回落到基线水平。
GC调优：让回收行为可观察、可控制
泄漏修完之后，GC调优解决的是另一个问题：即使没有泄漏，不合理的GC配置也会导致频繁Full GC、长时间停顿，间接放大内存压力。调优的第一步永远是开启GC日志，没有数据的调优全是猜测。JDK 11及以上用统一日志格式，JDK 8用-XX:+PrintGCDetails：
# JDK 11+ 推荐的GC日志配置
java -Xlog:gc*,gc+heap=debug:file=/logs/gc.log:time,uptime,level,tags:filecount=5,filesize=50m \
-XX:+UseG1GC -XX:MaxGCPauseMillis=200 \
-jar app.jarG1收集器的调优重点抓三个参数。MaxGCPauseMillis设定期望停顿目标，默认200ms，G1会据此调整每次回收的Region数量，注意它只是目标不是保证，设得过小会迫使G1减小年轻代、增加GC频率，反而降低吞吐；InitiatingHeapOccupancyPercent（IHOP，默认45%）决定并发标记周期的启动时机，如果堆增长快、经常出现并发模式失败退化为Full GC，可以把它降到35左右让标记提前启动；G1ReservePercent（默认10%）是应对晋升失败的预留空间，晋升失败频发时适当调大。此外，除非日志明确显示对象晋升过快，否则不要手动设置年轻代大小，那会破坏G1的自适应能力。
读GC日志时关注几个信号：Young GC频率正常应在每分钟几次到十几次之间，单次耗时几十毫秒属于健康范围；如果出现 to-space exhausted 或 Full GC 字样，说明老年代空间吃紧，要么堆太小，要么存在泄漏残留；停顿时间长期超出目标值两倍以上，需要重新评估目标或增大堆。调优不是一次性的工作，每次只改一个参数，压测对比，用gceasy这类在线工具可视化日志做前后对比，才能确认改动是否真的有效。把GC日志接入监控平台（如Prometheus加Grafana），持续观察堆使用曲线和GC趋势，才算建立了长效的内存健康机制。