JVM 垃圾回收怎么判断对象可以回收？GC Roots 和可达性分析是什么？

知识点详解：先画引用，再决定谁还活着

“可达”不是“离得近”，而是有引用路径

假设活动线程正在处理一个请求，线程使用请求对象，请求对象引用用户资料。

我们可以从这条线程相关的根引用找到请求，再找到用户资料。用户资料虽然不是直接被根指向，仍然通过中间对象可达。

这也是为什么分析时不能只看某一个变量。变量被清空了，另一个集合、回调或者缓存可能仍然引用同一对象。

下面先用普通强引用讲主线；特殊引用的处理稍后再补。

为什么引用环不一定是问题？

假设 A 引用 B，B 又引用 A，但程序已经没有任何根路径能到达它们。

如果只计算引用次数，两者看起来仍然互相“养着”。但从根开始遍历，找不到 A，也找不到 B，这个闭环没有让自己重新连接到正在运行的程序。

反过来，如果缓存引用 A，A 再引用 B，那么两个对象都仍然可达。让它们保留下来的不是环，而是缓存到根之间的那条路径。

HotSpot 的回收说明把对象是否仍可被运行中的程序到达，作为理解回收的基础。

缓存泄漏，不一定需要“断不掉”的循环

假设应用把每次请求结果都放进一个长期存在的 Map，从不删除。

Map 仍然可达，里面的结果也就仍然可达。GC 没有读懂“这些结果已经没用了”，它看到的是应用继续保留引用。

因此，内存泄漏可以很普通：数据已经不需要，但程序还保存着。缓存没有容量、监听器没有移除、线程上下文没有清理，都可能形成这种保留。

修复时应该处理不必要的引用和生命周期，而不是不停调用 System.gc。

弱引用能不能让所有问题自动消失？

不能。WeakReference 引用的对象有特定可达性处理规则，并不代表包装这个引用的其他对象，或者旁边保存的值，也都自动成为弱引用。

例如 ThreadLocalMap 的键是弱引用，但值通常仍被强引用。要分析完整路径，不能看到其中一个“弱”字就停止检查。

软引用也不是可靠的缓存容量管理方案。什么时候清理、能不能接受重新加载，以及缓存命中成本，仍要明确设计。

可回收与资源关闭，也要分开

一个对象已经不再被使用，不保证 GC 立即运行；System.gc 也不是确定的及时回收命令。

如果对象关联文件句柄、网络连接等资源，程序应在明确的使用范围结束时关闭资源。不能把“对象迟早会被回收”当成连接及时释放的承诺。

同样，不需要把所有收集器名字背一遍，才能答清对象存活。先讲可达性，再在追问中讨论标记、移动或具体收集器。

面试官继续追问

static 字段引用的对象一定永远不回收吗？

不应说“永远”。它是否保留，还要看所属类及类加载器等生命周期。但长期存活的类持有静态集合，确实容易形成长保留路径。

堆转储里对象很多，就说明泄漏了吗？

不一定。可能是短时间积压，也可能是正常缓存。需要比较持续增长、负载变化和回收后的保留情况，再查看引用路径。数量只是线索，不是结论。

没有任何引用，就能承诺下一秒被回收吗？

不能。成为可回收对象和实际回收时机不是一回事。也不要在测试里用一次 GC 请求，证明所有环境都会马上释放。

面试速记卡

• 判断主线：从 GC Roots 出发看引用可达性。
• 引用环：整体与根断开，环本身不阻止回收。
• 泄漏：业务不需要，但仍存在不必要的保留路径。
• 特殊引用：分析完整关系，不只看“弱引用”三个字。
• 可回收：不承诺立即回收，更不替代外部资源关闭。