容器里跑的服务半夜自己重启，日志只剩一句 Killed，只把内存上限调大能解决吗？

容器里跑的服务半夜自己重启，日志只留一句 Killed，多数情况是容器内存超限被内核 OOM killer 终止，而不是代码抛了异常。但先别急着把内存上限调大：按 2026 年的项目交付经验，真正因为业务量涨上来撑不住的占比不高，更多是容器上限、应用堆上限、运行时额外开销、系统开销这四笔账没对齐。先把四层核对清楚，再决定是调参数还是查泄漏，返工成本差别很大。

被 Killed 和报错崩溃，现场长得不一样

应用自己内存不够时，运行时会先给你留证据：堆栈、内存溢出异常、堆转储文件，甚至能写一条错误日志。容器被内核 OOM killer 挑中时，内核直接发 SIGKILL，进程没有机会执行任何收尾逻辑，所以现场往往是干净的——日志停在几条正常请求上，进程消失，随后被编排系统按重启策略拉起来。

这也是排查容易走偏的原因：只翻应用日志的人会得出“什么都没报错”的结论，而证据其实在容器层和内核层。判断顺序建议从外往内：先确认容器终止原因，再看进程内存构成，最后才回到业务代码里找增长点。

• 看现象：重启时间点集中、每次重启前内存曲线陡增，比随机崩溃更像内存问题。
• 看证据：有堆转储文件多半是应用内堆耗尽；只有被终止记录、没有任何转储，多半出在容器层。
• 看时间：低峰期也重启，说明不是并发量的问题，而是常驻内存本身在涨。

四层内存核对法：先看账对不对，再看有没有漏

容器内存是一个由 cgroup 划定的总盘子，应用只能用其中一部分，中间还夹着几层不写在业务代码里的开销。之所以按四层划分，是因为这四层出问题后的处理方式完全不同：前两层属于配置问题，改一次就见效；后两层要么是容量问题，要么是真泄漏，改动代价高得多。

1. 容器或实例内存上限：由部署配置决定，是总盘子。核对时注意同一 Pod 里的边车容器、日志采集进程也在吃这个盘子。
2. 应用堆或主内存上限：例如 JVM 的 -Xmx 一类参数。经验区间是设成容器上限的 50%~75%，留出余量给堆外。
3. 运行时额外开销：元空间、线程栈、直接内存、垃圾回收辅助结构、本地库缓存。这部分不占堆，但占容器内存。
4. 系统与相邻进程开销：页缓存、临时文件、同机其他进程。批量导出、大文件解压这类场景容易把这一层顶起来。

每层的注意点不同：第 2 层不是越小越保险，堆压得太小会回收频繁、接口耗时上升；第 3 层最容易漏，尤其是用了直接内存或线程数较多的服务；第 4 层要靠实现方式控制，比如导出接口不要一次性把结果全读进内存。做到什么算合格：四层的量加起来能对上容器上限，而不是“堆上限小于容器上限”就以为万事大吉。

怎么从现场证据确认是内存超限，而不是别的重启原因

服务重启的原因至少有四类：内存超限被终止、健康检查连续失败被重建、节点资源不足被驱逐、节点本身故障。它们的处理方式完全不同，所以第一步不是优化，而是把“谁在什么时刻被谁杀掉”这条链拿全。

• 容器终止原因：容器层会记录上次终止的原因和退出码，被 SIGKILL 终止的退出码常见是 137，内存超限通常伴随对应的原因标记。
• 内核日志：内存超限发生时内核侧会留下记录，能看出被挑中的进程和被终止的原因。
• 驱逐标记：如果是节点资源紧张被驱逐，事件里会体现，跟单纯的内存超限不是一回事。
• 健康检查：探针连续失败导致的重启，日志里往往有探针超时或端口不通的痕迹，内存曲线反而平稳。

合格口径是：能指出被终止的时间和原因类别，而不是只看到“重启过”。如果这几条都拿不到，先补监控和事件采集，否则后面所有优化都是猜。需要依据时可按官方文档与交付验收清单逐项核对，不要凭印象下结论。

调上限、改批量、还是查泄漏：三条路的取舍

确认是内存问题之后，常见的分歧是“先把上限调大顶一下”还是“直接查泄漏”。按 2026 年的交付经验，这两条路并不对立，关键看内存曲线的形状。下面这组对比可以拿来核对：

• 台阶型（随流量上去、峰值后回落）：属于容量问题。先上调上限并留 20%~30% 余量，同时配合限流或扩容观察一到两周。
• 缓坡型（低峰期也不回落、斜率稳定）：疑似泄漏。调上限只是把重启时间往后推，常见做法是取两次间隔数小时的内存快照做对比，定位持续增长的对象。定位常见需要一到三天，修复排期视迭代节奏。
• 脉冲型（集中在某类操作之后）：先改实现。大文件解析、批量导出、全量预热这类操作，改成分批或流式处理，通常比加内存便宜，常见改动量是半天到两天。
• 账没对齐型（容器上限与堆上限挨太近）：先对账再谈优化，把堆上限压到容器上限的 50%~75%，给堆外留出空间。调参本身通常半天内可完成，但观察期建议一到两周。

一条容易被忽略的边界：上限调大并不总是安全动作。机器物理内存有限，上限一旦超过节点可分配量，容器可能起不来或被调度系统拒绝，反而变成发布事故。

在项目里常见的一种约束是：甲方只给一台固定规格的机器、交付期只剩一周、又不接受架构改动。这时候通常的做法是先按四层对账，把堆上限按容器上限的常见区间五到七成设定，再把批量导出改成流式写文件，同时把日志级别从调试降回常规。结果是交付观察期内的夜间重启不再出现，代价是导出接口耗时从十几秒拉到几十秒，需要前端补一个进度提示，这块改稿常见要占半天到一天。犀跃公司在类似交付里也走过同样的顺序：先对齐内存账，再动业务实现，最后才谈扩容。

适用场景与边界

这套排查适合跑在容器或托管环境里、出现过无异常日志的重启、并且已经有基础内存监控的服务。如果进程崩溃时留下了完整堆栈和堆转储，那属于应用级异常，先按代码问题处理更直接；如果只是单机跑的内部小工具、一周重启一次且不影响业务，投入内存画像的性价比不高。

• 适合：多实例对外服务、夜间集中重启、内存曲线有明显形状、能查到容器事件。
• 不必上：本地开发环境、一次性脚本、崩溃时有完整应用日志、还没有任何内存监控的阶段。
• 先做别的：如果重启同时伴随接口大量超时和慢查询，先处理慢查询，内存超标可能只是被拖累的表象。

常见问题

容器内存上限直接设成机器物理内存行不行？

不建议。单容器占满物理内存会让系统进程和相邻容器没有余量，常见做法是留出 20%~30% 给系统和同机其他进程。

退出码 137 一定是内存超限吗？

不一定。137 表示进程被 SIGKILL 终止，内存超限是常见原因，手动终止、节点驱逐也可能出现，要结合内核记录一起判断。

Java 服务已经设了堆上限，还会因为内存被杀吗？

会。线程栈、元空间、直接内存都不在堆里，容器统计的是进程总内存，堆上限和容器上限挨得太近就容易被终止。

内存缓慢上涨，一定要马上处理吗？

看斜率。低峰期不回落、每天稳定上涨的，常见做法是排进迭代计划；涨到上限要几周且已有告警的，可以先观察再定档期。

先加内存顶一阵，会有什么代价？

它只买时间。如果增长斜率没变，通常只是把重启往后推，同时掩盖真实增长点，后续定位反而更麻烦。

下一步建议按三步走：先确认容器终止原因和内核记录，再用四层核对法把容器上限、堆上限、堆外开销与系统开销对平，最后按内存曲线的形状选调参、改实现还是查泄漏。这套方法适用于有监控、能拿到容器事件的线上服务；如果只影响内部工具、又缺少观测手段，先补监控比先改代码更划算，边界就在这里。