Java对象存活判断靠可达性分析，即从GC Roots（如线程栈帧局部变量、静态属性、常量池对象等）出发遍历引用链，不可达的对象即被回收；引用计数法因无法处理循环引用未被JVM采用。
Java对象存活判断靠什么？不是引用计数法，是可达性分析
Java虚拟机实际只用可达性分析算法判断对象是否存活，引用计数法在JVM中根本没被采用——它解决不了循环引用问题，而这是日常编码里太常见的事。
比如两个对象a和b互相持有对方的引用，但外部再无任何变量指向它们。引用计数法会认为它们的计数都大于0，误判为“还活着”；而可达性分析从GC Roots出发遍历，发现它们都不可达，立刻回收。
哪些对象能当GC Roots？别把普通局部变量当根
GC Roots不是所有变量都能算，必须是“确定不会被回收”的起点。常见合法Root包括：
-
正在执行的Java线程的栈帧中的局部变量表（注意：仅限当前活跃方法里的强引用变量） 本地方法栈中JNI引用的对象-
方法区中类静态属性引用的对象（如public static List<string> cache</string>） -
方法区中常量引用的对象（如字符串常量池里的"hello"） -
Java虚拟机内部的引用（如基本类型对应的Class对象）
容易踩的坑：把刚new出来、还没赋值给任何字段或局部变量的对象当成Root——它连入栈都没完成，根本不在GC Roots集合里。
立即学习“Java免费学习笔记（深入）”；
WeakReference/PhantomReference怎么影响存活判定？
引用类型不改变可达性分析的基本逻辑，但决定“什么时候算真正不可达”。关键看引用强度：
-
StrongReference：只要链路上全是强引用，对象就不可回收 -
WeakReference：GC时一旦发现只有弱引用指向该对象，立即回收（不管内存是否紧张） -
PhantomReference：无法通过它获取对象实例，仅用于收到“对象即将被回收”的通知；对象进入F-Queue后才被真正回收
注意：SoftReference的行为依赖JVM实现和堆内存压力，不是标准回收时机依据，不能用来判断“是否存活”，只能辅助缓存策略。
System.gc()能强制触发可达性分析吗？
不能。System.gc()只是建议JVM“考虑”执行一次GC，是否执行、何时执行、用哪个收集器，全由JVM决定。尤其在Server模式或G1/ZGC等现代收集器下，它大概率被忽略。
更关键的是：即使GC真的运行了，可达性分析也只发生在STW（Stop-The-World）阶段，且分析结果受当时线程栈状态、引用关系快照影响——你代码里刚把引用设为null，不代表GC线程一定看到这个变更。
所以，不要靠System.gc()来验证对象是否存活。真要调试，用jmap -histo或VisualVM看堆快照，或者加-XX:+PrintGCDetails观察日志里的“GC Root”路径。
最常被忽略的一点：对象是否“存活”，从来不是某个瞬间的布尔值，而是取决于GC发生时刻的引用图快照——而这个快照本身，就藏在并发标记、SATB记录、TAMS指针这些底层机制里，写业务代码时几乎感知不到。
