确认内存泄漏需观察老年代使用率“只涨不跌”、FGC频次激增且回收无效、OOM频繁复现、特定类实例持续增长；jmap加live可导出纯净堆快照；MAT中通过Path to GC Roots查强引用链，Dominator Tree定位真正内存支配者。
怎么确认真有内存泄漏，而不是GC波动？
别急着 jmap，先看现象是否符合泄漏本质：老年代内存「只涨不跌」。比如 jstat -gcutil <pid> 1000 5</pid> 连续采样，发现 O（Old space 使用率）从 70% → 85% → 92% → 96% → 98%，且每次 FGC 后几乎没回落，这就不是正常业务高峰，是泄漏信号。
- Full GC 频次越来越高（比如从每小时 1 次变成每分钟 2 次），单次耗时超 1s，同时
FGCT累计值快速上升 - 应用日志里反复出现
java.lang.OutOfMemoryError: Java heap space，重启后几小时内复现 - 用
jmap -histo:live <pid></pid>隔 5 分钟跑两次，对比发现某类实例数（如com.example.UserCacheEntry）持续增长、不减
用 jmap 导出 dump 时，为什么加 live 很关键？
jmap -dump:format=b,file=heap.hprof <pid></pid> 会触发一次全局 Stop-The-World，导出所有对象（包括已标记待回收但还没清理的）。而生产环境更推荐 jmap -dump:live,format=b,file=heap.hprof <pid></pid> —— 它强制先做一次 Full GC，再 dump 剩下的「活对象」，数据更干净，避免把临时对象噪音带进分析。
- 不加
live：dump 文件大、MAT 分析慢、容易被短生命周期对象干扰判断 - 加
live：文件小 30%~50%，Leak Suspects报告更准，但会短暂卡顿（STW 时间取决于老年代大小） - 线上慎用：若服务敏感，优先依赖启动参数
-XX:+HeapDumpOnOutOfMemoryError自动捕获，而非手动触发
MAT 中怎么看懂「Path to GC Roots」里的引用链？
打开 dump 后点 Leak Suspects Report，它标出的嫌疑对象只是起点；真正要动手改代码，得点进去看 Path to GC Roots —— 这里显示的是「谁在强持有这个对象，让它没法被回收」。
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
- 看到
static字段（如com.example.CacheManager.cache）→ 典型静态集合泄漏，检查是否漏清理或没设过期 - 看到
java.lang.Thread持有 → 查线程栈，可能是线程池任务中缓存了大对象或未关闭ThreadLocal - 看到
org.springframework.context.support.AbstractApplicationContext→ Spring Bean 生命周期异常，比如监听器注册后没注销 - 注意过滤：勾选
exclude all phantom/weak/soft references，只看强引用链，否则会看到大量无意义路径
为什么用 Dominator Tree 比 Histogram 更快定位根因？
Histogram 只告诉你「哪个类实例最多」，比如 byte[] 占内存第一——但这没用，因为几乎所有大对象底层都是 byte[]。Dominator Tree 才是关键：它按「支配关系」排序，排第一的，是那些「自己占内存多 + 它活着就拖着一堆其他对象也活不了」的对象。
立即学习“Java免费学习笔记（深入）”；
- 找
Retained Heap最大的几行，比如com.example.OrderService实例占 1.2GB → 直接去查这个类的静态字段或单例状态 - 右键 →
Path to GC Roots→ 看是不是被某个static Map或未 shutdown 的ScheduledExecutorService持有 - 如果
Dominator Tree顶部全是第三方库类（如io.netty.buffer.PooledByteBuf），别急着改自己代码，先查 Netty 是否漏调release()
真正难的不是找到那个大对象，而是看懂它为什么不该活那么久——引用链里每个箭头，都对应一行可能漏掉的 remove()、close() 或 shutdown()。
