线上Pod突然重启。
你第一反应是去看CPU和内存。
CPU没打满。
内存监控最高也就60%左右。
看起来离100%还远。
结果再看Pod状态：
Last State: Terminated Reason: OOMKilled Exit Code: 137这就很容易让人懵：
内存才60%，怎么会被OOMKilled？
甚至第一反应会怀疑：
监控是不是错了？
Kubernetes是不是误杀？
JVM是不是有Bug？
如果这时候直接让 ChatGPT、Codex：
“帮我分析为什么Java堆内存泄漏。”
很可能一开始方向就偏了。
因为真正应该先确认的不是：
Heap用了多少。
而是：
容器真正被哪个内存边界杀掉了，以及你监控里的“60%”到底代表什么。
一、先给核心判断：监控60%，不代表距离OOM还有40%
这是这类问题最关键的一点。
你看到的“Memory 60%”，可能是很多不同指标算出来的。
比如：
当前Working Set / Request。
当前RSS / Node Memory。
JVM Heap / Xmx。
某个时间窗口里的平均值。
但Kubernetes真正判断容器是否突破内存限制时，看的是：
cgroup实际内存使用和容器Memory Limit之间的关系。
这两个口径如果不一样，就会出现：
监控看着还没满，容器却已经触发OOM。
所以第一步一定要先问：
这个60%的分母到底是谁？
二、第一步先看Pod的Memory Limit，不要先看Dashboard
比如Deployment里配置：
resources: requests: memory: "1Gi" limits: memory: "2Gi"如果Dashboard里的60%是：
1.2Gi / 2Gi
那确实还有空间。
但如果Dashboard算的是：
600Mi / 1Gi Request
那显示60%，和真正2Gi的Limit其实不是一回事。
反过来也一样。
有些监控展示的是：
使用量占Node总内存。
Pod只占整台机器10%，看起来非常低。
但它自己的Container Limit可能只有512Mi。
只要容器超过512Mi，一样可能被杀。
所以看到“60%”以后，先确认三件事：
当前使用量是多少。
Request是多少。
Limit是多少。
不要只看一个百分比。
三、第二个高频误区：你看的可能只是JVM Heap
Java服务尤其容易出现这种情况。
比如JVM配置：
-Xmx1024m
监控里看到：
Heap只用了700Mi。
大概70%。
看起来还很安全。
但Java进程真正占用的内存远远不只有Heap。
还包括：
Metaspace。
Thread Stack。
Direct Buffer。
Code Cache。
JIT。
JNI / Native Library。
GC自身内存。
以及其他Native Memory。
所以：
Heap Memory ≠ Process Memory
你可能看到：
Heap 700Mi。
但进程RSS已经接近1.8Gi。
如果容器Limit是2Gi，
这时候距离OOM已经非常近。
四、真实场景：线程数暴涨，也可能把Pod打死
假设一个Java服务：
Heap一直很稳定。
GC也正常。
看起来没有明显内存泄漏。
但某次流量高峰以后：
线程数从300涨到了1500。
如果每个线程都需要Thread Stack，
那新增线程本身就会消耗大量Native Memory。
于是你可能看到：
Heap没怎么涨。
但Container Memory突然上升。
最后直接：
OOMKilled。
所以排查Java OOM时，不能只盯：
Heap Dump。
还要看：
Native Memory和线程数量。
如果只是一直分析Heap对象，
很可能永远找不到真正原因。
五、Direct Memory也是很容易被漏掉的一块
比如你使用：
Netty。
NIO。
某些HTTP Client。
高性能序列化。
它们可能大量使用Direct Buffer。
这些内存不一定完整体现在JVM Heap里。
所以某些服务会出现：
Heap看着只有50%。
GC也很健康。
但是Native Direct Memory不断上涨。
最终容器仍然被OOMKilled。
这种场景特别容易误判成：
“Kubernetes内存统计不准。”
其实只是：
你看的内存层级太窄。
六、为什么Page Cache也可能让你觉得“内存对不上”？
Linux内存统计本身就不是只有：
“应用申请了多少Heap”。
文件IO、日志、大量读写都可能带来Page Cache。
而不同监控指标对：
Active File。
Inactive File。
Cache
的处理方式可能不同。
比如某些Dashboard更偏向展示Working Set。
它可能和cgroup真正的Memory Usage不是完全一样。
所以出现：
Dashboard曲线看着没到100%。
但cgroup边界已经非常紧张。
并不奇怪。
这也是为什么：
不同指标之间不能直接互相替代。
七、还有一种特别隐蔽的情况：短时尖峰被监控采样漏掉了
这个现场我觉得特别典型。
Prometheus每15秒采一次。
或者Dashboard展示的是1分钟平均值。
但真实OOM可能发生在：
某个2秒内的瞬时峰值。
比如：
一次大对象分配。
批量读入文件。
瞬间创建大量Buffer。
短时间大量并发请求。
内存可能这样变化：
10:00:00 1.1Gi 10:00:06 2.1Gi ← 瞬时突破Limit 10:00:07 Container被Kill 10:00:15 新Container启动 600Mi如果监控只在：
10:00:00
和：
10:00:15
采样，
你甚至根本看不到中间那个2.1Gi。
最后Dashboard可能显示：
“最高60%”。
但真实峰值已经突破过限制。
八、先别急着认定是“内存泄漏”
OOMKilled不等于一定是：
Memory Leak。
还可能是：
单次批量任务。
突发流量。
大文件读取。
线程暴涨。
Direct Buffer。
Page Cache。
Native Library。
内存Limit配得太低。
所以更稳的排查方式应该是：
先区分“持续增长”还是“瞬时峰值”。
如果内存一路缓慢上涨，长期不回落：
更像泄漏。
如果平时稳定，某个时间点突然冲高：
更像突发分配或者并发问题。
这两个方向完全不同。
九、还有一个边界场景：主容器没问题，Sidecar出问题了
一个Pod里可能不止一个Container。
例如：
主应用。
日志Sidecar。
Service Mesh Proxy。
监控Agent。
如果你看的Dashboard只展示主应用Container，
那主应用可能确实只有60%。
但Sidecar可能已经接近自己的Memory Limit。
最终你看到Pod异常重启时，就容易误以为：
“Java服务被OOM了。”
所以第一件事一定要确认：
到底是哪一个Container被OOMKilled。
不要只看Pod级别状态。
十、最快排查顺序，我一般按这7步走
以后看到：
“内存明明没满，却OOMKilled”
我建议直接按这个顺序。
第一步：确认被杀的是哪个Container
看Container Status和Last State。
不要先假设就是主应用。
第二步：确认Memory Limit
先找到真正的硬边界是多少。
第三步：确认监控60%的计算口径
到底是：
Heap？
RSS？
Working Set？
占Request？
还是占Limit？
第四步：对齐OOM时间点
把：
Container重启时间。
Event。
内存曲线。
GC日志。
应用日志
放在同一条时间线上。
第五步：区分Heap和Native
Java重点看：
Heap。
Metaspace。
Thread。
Direct Buffer。
Native Memory。
第六步：检查短时尖峰
看看监控采样间隔是不是太大。
是否存在大对象、批处理、突发并发。
第七步：再判断泄漏还是容量问题
最后才决定：
Heap Dump。
Native Memory Tracking。
调整Limit。
还是改业务逻辑。
这个顺序会比：
“先抓Heap Dump”
效率高很多。
十一、Java场景里，我最想先看哪几个指标？
如果是Java服务，我通常会把这些放在一起看：
- Container Working Set；
- Container RSS；
- JVM Heap Used；
- JVM Non-Heap；
- Thread Count；
- Direct Buffer；
- GC频率；
- Container Restart；
- Memory Limit。
最重要的不是某一个数字。
而是：
Heap和Container Memory之间的差值到底越来越大没有。
如果Heap一直稳定，
但Container Memory越来越高，
那就应该优先怀疑：
Native Memory。
Thread。
Direct Buffer。
Page Cache。
而不是继续在Heap对象里找半天。
十二、具体怎么修？先不要一上来就把Limit翻倍
看到OOM最简单的动作就是：
memory limit: 2Gi → 4Gi
有时候确实能暂时止血。
但它只能回答：
“现在还能不能活着？”
不能回答：
“为什么会涨到这里？”
如果真正原因是：
内存泄漏。
线程失控。
Direct Buffer不释放。
那Limit翻倍只是：
晚一点再死。
所以修复要根据根因来。
如果是：
Limit明显太小
→ 合理增加容器内存。
如果是：
JVM Xmx太接近容器Limit
→ 给Native Memory留空间。
如果是：
线程太多
→ 控制线程池、并发和Thread Stack。
如果是：
Direct Buffer
→ 排查Buffer生命周期和上限。
如果是：
瞬时批处理
→ 分批处理、流式读取。
如果是：
内存泄漏
→ 再做Heap Dump / Native分析。
十三、JVM的Xmx为什么不要直接顶到Container Limit？
比如：
Container Limit = 2Gi。
你却设置：
-Xmx2g
这其实就已经很危险。
因为Heap一旦吃满2Gi，
JVM自身还需要：
Metaspace。
线程栈。
Code Cache。
Direct Memory。
Native结构。
于是Container总内存很容易超过2Gi。
所以更合理的是：
给Heap之外的内存预留空间。
具体比例不能死套一个数字，
要根据：
线程数。
Direct Memory。
框架。
业务模型。
压测结果
来定。
但核心原则很简单：
Xmx不能默认等于Container Limit。
十四、修完以后怎么验证？
不要只看：
“这两天没再OOM”。
更靠谱的是主动重新制造原来的压力。
比如：
恢复相同并发。
跑相同批处理。
加载相同大文件。
重新执行高峰任务。
然后同时观察：
Container Memory峰值。
Heap峰值。
Native Memory。
Thread Count。
GC。
Restart Count。
最关键的两个问题是：
峰值是否还会接近Limit？
以及：
流量结束以后，内存能不能正常回落？
如果高峰结束后：
Heap回落。
Container Memory也稳定。
说明更健康。
如果每轮压测结束以后：
内存基线都继续上涨，
那才更值得怀疑泄漏。
十五、这种OOM排查，Plus和Pro怎么判断？
如果你平时只是偶尔让 ChatGPT、Codex：
分析一次Pod Event。
看看Deployment资源配置。
对比Heap和Container Memory。
辅助读一下GC日志。
这种任务范围比较集中，Plus通常已经够用。
最重要的是把Evidence提供完整：
Pod资源配置。
Container状态。
OOM时间。
内存监控。
JVM参数。
线程数。
GC日志。
这些比单纯提高AI使用量更重要。
如果你的日常工作已经变成：
持续排查Kubernetes和JVM性能问题。
一次事故需要同时分析：
Pod Event。
Prometheus。
GC Log。
Heap Dump。
Thread Dump。
Native Memory。
应用代码。
还要让Codex修改代码、跑压测、做多轮验证，
这种高频、长时间工程任务已经成为常态，
那Pro会更适合。
所以Plus还是Pro，不看：
“OOM问题难不难。”
而是看：
ChatGPT、Codex每天是不是长期参与完整的工程排障链路。
偶发排查、短任务：
Plus通常够用。
持续性能治理、多轮分析和验证：
再考虑Pro。
最后
Pod内存明明才60%，为什么还是突然OOMKilled？
真正最容易犯的错误是：
把一个Dashboard百分比，当成了容器真实内存边界。
你首先应该搞清楚：
这个60%是什么。
分母是什么。
真正Limit是多少。
被杀的是哪个Container。
OOM那一瞬间到底发生了什么。
然后再去区分：
Heap。
Native。
Thread。
Direct Buffer。
Page Cache。
瞬时峰值。
只有这些层级拆开以后，
“监控只有60%，Pod却OOMKilled”
才不会再显得矛盾。
真正的问题通常不是：
Kubernetes为什么乱杀进程。
而是：
我们一直在看一个和OOM判定不完全相同的内存指标。
把口径对齐以后，很多看起来诡异的OOM问题，反而会变得非常具体。
持续分享 Codex、大模型开发与 AI 编程实战内容。
长期深度使用各类代码大模型，也整理了稳定的Plus/Pro会员订阅渠道，有需要可自取。
