java内存泄漏是对象被不当强引用导致无法回收，表现为老年代长期超90%、gc overhead异常、重启后快速满堆；需用jstat观察、jmap快照、idea/mat追踪引用链定位根因。
Java内存泄漏不是“突然爆炸”，而是悄悄吃掉堆内存，直到OOM才暴露。定位元凶的关键，不在于堆多大，而在于谁在不该持有引用时一直攥着对象不放。工具只是放大镜，用对了才能看清那条错误的引用链。
先快速确认是不是内存泄漏
别急着dump，先看现象：
-
jstat -gcutil <pid> 1000</pid>持续观察，如果老年代（O列）长期 >90%，且Full GC后几乎不下降 → 高概率泄漏 - 日志频繁出现
GC overhead limit exceeded→ GC拼命干活却收效甚微，典型泄漏信号 - 重启后几小时内存又快速打满 → 排除一次性加载类问题，指向持续性泄漏
用 jmap 把“现场”拓印下来
jmap 是第一步也是最稳的抓手，它不依赖图形界面，生产环境随时可用：
- 先找进程ID：
jps -l或ps -ef | grep java - 生成堆快照（推荐在内存使用率70%~85%时执行，避免卡死）：
jmap -dump:format=b,file=/tmp/heap.hprof <pid></pid> - 快速扫描可疑对象（不用打开大文件）：
jmap -histo:live <pid> | head -20</pid>
关注排在前几的类：比如byte[]、char[]、HashMap$Node、自定义的Order或CacheEntry—— 实例数异常高、总字节数巨大，就是重点怀疑对象
用 IDEA Memory Viewer 直观揪出引用链
把 .hprof 文件拖进最新版 IntelliJ IDEA（2023.3+），它内置的 Memory Viewer 能直接解析：
- 打开后自动显示“Top Classes by Retained Size”（按保留内存排序）
- 点击可疑类 → 右键 “Show Retained Objects” → 再点 “Find Path to GC Roots”
- 你会看到一条从 GC Root（如 static 字段、线程栈）到该对象的完整强引用路径
例如：MyService.cache（static HashMap）→CacheEntry.value→byte[]
这条路径就是泄漏根源：静态缓存没清理，导致 value 和它的 byte 数组永远无法回收
JProfiler 或 MAT 做深度验证（可选但有力）
- JProfiler 12 加载 dump 后，“Leak Suspects” 页面会自动标红高风险对象，并给出支配树（Dominators Tree）
- Eclipse MAT 中打开后，用 “Histogram” + “Merge Shortest Paths to GC Roots”（排除弱/软引用），能清晰看到哪个线程或静态变量是根因
真正卡住人的，往往不是工具不会用，而是没分清泄漏和溢出：
- 泄漏是“该扔的没扔”，表现为内存缓慢爬升、Full GC 无效；
- 溢出可能是“一次加载太多”，比如读GB级文件进 ArrayList，这种改代码逻辑就行，不涉及引用链。
定位到具体类和引用路径后，回代码里查三点：
- 它是不是被 static、单例、缓存容器长期持有？
- 它的生命周期是否远超实际使用时间（比如监听器注册后忘了 remove）？
- 它内部是否持有外部类、大数组、未关闭流等“拖油瓶”？
工具组合的本质，是用 jmap 锁定“谁在占内存”，再用分析器逆向追踪“谁在拽着它不放”。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
