java对象存活判定核心是可达性分析算法，即从gc roots（如虚拟机栈局部变量、静态字段、常量池引用、jni引用等）出发沿强引用链搜索，未被任何引用链可达的对象才被视为可回收；该方法天然解决循环引用问题，并通过两次标记机制（含finalize筛选）确保回收准确性。
Java对象存活分析，核心是判断一个对象是否还被GC Roots可达、是否真的“无用但未回收”。这不是单纯看对象还在不在堆里，而是看它是否处于“业务上已废弃，却因引用链未断而被迫续命”的状态。整个流程围绕“谁在持有着它”展开，目标是揪出那条不该存在的引用链。
第一步：确认对象确实没被回收
先排除GC还没来得及处理的假象。关键看老年代使用率（O列）和Full GC效果：
- 用 jstat -gcutil
1000 10 观察：O持续缓慢上涨（比如5分钟内从40%→65%），且每次FGC后只回落1~2%，基本就是“卡住”了 - 如果FGC频繁但老年代几乎不降，说明大量对象跨代晋升后“赖着不走”，GC Roots链大概率没断
- 注意区分：Minor GC后Eden区正常清空 ≠ 没泄漏；真正要看的是老年代是否“只进不出”
第二步：抓取堆快照，锁定可疑对象
不是随便 dump，要选时机和方式：
- 推荐在一次Full GC刚结束时执行：jmap -dump:live,format=b,file=leak.hprof
，这样快照里全是“活”对象，干扰少 - 避免用
-dump不加live，否则会包含大量待回收垃圾，分析噪音大 - 文件大小≈当前老年代已用内存，确保磁盘有足够空间（通常几百MB到几GB）
第三步：用MAT分析引用链
打开hprof后，不靠猜，靠三把工具刀：
-
Histogram：按类排序，找实例数异常多、总保留大小（Retained Heap）特别高的业务类（比如你的
Order、UserSession） - Dominator Tree：直接看到哪些对象“挡路”——它们自己占内存多，又阻止下游一堆对象被回收
-
Path to GC Roots（排除弱/虚引用）：右键可疑对象 → “Exclude weak/soft references”，看剩下哪条路径连到GC Roots。常见罪魁：
static final Map、线程局部变量ThreadLocal、未注销的监听器、静态内部类持有的外部类实例
第四步：回溯代码，验证引用合理性
找到引用链后，问两个问题：
- 这条引用是业务必需的吗？比如缓存中的订单对象，是否设置了过期策略或容量上限？
- 持有方生命周期是否远长于被持有方？比如Servlet实例（常驻）持有了临时请求对象，就属于典型错配
- 资源类（
FileInputStream、Connection）是否漏了close()？虽然对象本身小，但底层资源可能拖住大片内存
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
