Java应用K8s中OOMKilled问题：内存去向及排查步骤咨询

缺失内存的可能去向 #

• 未被NMT统计的本地内存：JNI调用中直接通过C标准库分配的内存（未走JVM内存分配接口）、第三方Native库的内存分配，这些不会被JVM的Native Memory Tracking捕获。此外，Linux内核为进程分配的页表、内核栈、Socket缓冲区等内存，属于进程RSS但不会被NMT统计。
• 文件缓存（Page Cache）：K8s的内存限制统计包含容器内的文件缓存，如果应用读取大量文件，页缓存会占用物理内存，这部分内存不会被NMT计入，却会被算入cgroup的内存使用量，触发OOMKilled。
• Reserved内存的特殊占用：部分标记为reserved的虚拟内存区域，可能因系统机制被实际占用物理内存（如共享库的加载页），但NMT仅标记为reserved未统计到committed中。

后续调试步骤 #

• 查看cgroup内存明细：在Pod内执行cat /sys/fs/cgroup/memory/memory.stat，分析rss、cache、kernel_stack、page_tables等字段的数值，定位哪部分内存占用超出预期。
• 用pmap分析进程内存映射：执行pmap -x <Java进程PID>，查看进程的所有内存区域，重点关注大的匿名映射或未被NMT覆盖的文件映射，找出异常内存块。
• 排查Native代码内存分配：检查应用是否使用JNI或第三方Native库（如Netty、JNI扩展等），确认这些组件是否存在内存泄漏或过度分配情况，可通过valgrind（需在容器中安装）跟踪Native内存分配。
• 启用NMT详细模式：执行jcmd <PID> VM.native_memory detail，获取更细粒度的内存分配数据，排查NMT summary中未体现的隐藏内存占用。
• 查看系统OOM日志：在K8s节点上执行dmesg | grep -i oom，获取OOM Killer触发时的详细日志，确认触发时的内存分布，判断是用户态还是内核态内存导致的OOM。
• 验证容器内存范围：确认Pod中是否存在Sidecar容器或其他进程，这些进程的内存占用也会被计入Pod总内存限制，可能导致Java进程未超自身内存但Pod整体超限制。

内容的提问来源于stack exchange，提问作者Joan