# 

服务跑几天内存就上去，重启能好一阵，然后继续涨。重启掩盖了问题，也把线索清掉了。要定位，第一步不是找泄漏对象，而是先弄清涨的到底是哪一块。

## 堆没满，进程为什么还会被杀？

因为容器和虚拟机的内存账本不是同一本。内存限制管的是整个容器，涵盖堆、类元数据、代码缓存、线程栈、直接内存和页缓存，堆只是其中一项。

最典型的困惑就在这里：堆曲线很正常，进程却被杀掉——内核按容器整体占用判定，不看堆里剩多少。

想确认堆外的哪一项在涨，最直接的办法是原生内存追踪。

```bash
# 必须在启动时开启，运行中无法打开
-XX:NativeMemoryTracking=summary

jcmd <pid> VM.native_memory baseline
jcmd <pid> VM.native_memory summary.diff
```

官方标注的开销是 5% 到 10%。它不跟踪第三方本地代码的分配，是指向性工具而非万能账本。

## OOM 分几种，判据为什么完全不同？

异常消息冒号后面那段文字，就是内存区域的第一手线索。

| 报错关键字 | 区域 | 判据 | 处置方向 |
| --- | --- | --- | --- |
| Java heap space | 堆 | 多次回收后谷底仍持续抬升 | 抓转储找支配对象 |
| Metaspace | 类元数据 | 类加载数持续涨、回收不掉 | 查类加载器数量 |
| Direct buffer memory | 堆外直接内存 | 堆正常但进程占用高 | 查缓冲区引用计数与上限 |
| unable to create native thread | 线程栈与系统资源 | 与堆无关 | 查线程数、栈大小与系统上限 |

还有一条容易误判：**GC overhead limit exceeded** 在默认收集器上长期少见，原因是这个检查很长时间没在该收集器上实现，同样的堆状态通常直接表现为 Java heap space，较新版本才补齐。所以这条报错少，不代表堆没问题。

## jmap 和 jcmd，哪个会触发 Full GC？

两个都可能触发，换成哪个都不等于安全。

转储命令默认只导出存活对象，而这需要先做一次完整回收；显式加上导出全部对象的参数才能跳过。类直方图同理，带存活标记会触发。

官方文档把转储操作的影响级别标为高，并且明确建议改用新命令。

```bash
jcmd <pid> GC.heap_dump -all filename=/path/dump.hprof
jcmd <pid> GC.class_histogram -all
```

老命令还在，但官方定性为实验性且不受支持，并注明未来版本可能移除。新脚本直接用新命令即可。

## 怎么确认是真泄漏还是堆配小了？

看多次完整回收**之后**的谷底占用，而不是看峰值。

```bash
jstat -gcutil <pid> 1000
```

输出里 **O 列**是老年代使用率，**FGC** 是完整回收次数。每个谷底都在往上抬，是对象不可回收的强信号；谷底平稳但紧贴上限，则只是工作集装不下。



```bash
# 堆参数、监控口径、转储路径，改一次留一档
# 这份环境记录我用墨衍同步到团队文档，换人接手时不用重新问
```

## 哪些写法在池化线程下必然泄漏？

线程本地变量在机制上必然泄漏：键是弱引用、值是强引用，外部引用一消失键被回收变成空键，但值仍被线程对象强引用。

线程池里的核心线程长期存活不销毁，这条回收链就永远不会断，而内部清理只在读写时启发式触发，既不及时也不彻底。根治方式只有一个：用完在 finally 里显式移除。更隐蔽的后果是线程复用时可能读到上个任务留下的值，表现为数据串号。

其他几类各有特征：静态集合和无上限本地缓存，内存随时间单调增长；监听器和回调忘注销，事件源长期存活；连接和流忘记关闭，句柄数一起涨；直接缓冲区泄漏表现为堆正常、转储看不出问题，只能靠原生内存追踪。

## 容器退出码 137 和 JVM 的 OOM 怎么区分？

JVM 的 OOM 由虚拟机内部抛出，日志里有完整异常栈、通常还能生成转储，退出码一般是 1。137 等于 128 加 9，是内核发的强制终止信号，进程来不及做任何处理，通常一行异常都不会有。

确认方式是看编排平台给出的终止原因，或看系统日志里的终止记录。注意 137 不等于一定是内存击杀，宽限期结束时没退出也会发同样的信号，必须以终止原因为准。

定位顺序可以固定下来：先看进程整体占用，再看堆，再看原生内存分项，最后才抓转储找对象。跳过前几步直接抓转储，很可能在一个本来就正常的堆里找一整天。


服务跑几天内存就上去，重启能好一阵，然后继续涨。重启掩盖了问题，也把线索清掉了。要定位，第一步不是找泄漏对象，而是先弄清涨的到底是哪一块。

Java 服务内存一直涨，重启只是把问题往后推

编程语言

后端

运维

服务运行多日后内存持续上涨，重启仅临时缓解。核心是定位内存增长区域：堆外（Native Memory Tracking）、Metaspace、直接缓冲区或线程栈均可能。区分真泄漏与堆配置过小需观察Full GC后老年代谷底趋势。jcmd转储建议加-all避免触发Full GC。线程池ThreadLocal必泄漏，需显式移除。退出码137由内核强制终止，非JVM OOM。

代码解释

虚拟机

容器

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

服务运行多日后内存持续上涨，重启仅临时缓解。核心是定位内存增长区域：堆外（Native Memory Tracking）、Metaspace、直接缓冲区或线程栈均可能。区分真泄漏与堆配置过小需观察Full GC后老年代谷底趋势。jcmd转储建议加-all避免触发Full GC。线程池ThreadLocal必泄漏，需显式...

Java 服务内存一直涨，重启只是把问题往后推-腾讯云开发者社区-腾讯云

Java 服务内存一直涨，重启只是把问题往后推

Java 服务内存一直涨，重启只是把问题往后推

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐