Java使用可达性分析判定对象存活，因其能准确高效识别真正不再被使用的对象并解决循环引用问题；该算法从GC Roots出发沿引用链搜索，可达对象存活，不可达者回收；GC Roots包括虚拟机栈、本地方法栈、方法区静态变量与常量、同步锁对象；相比引用计数法，它避免了循环引用内存泄漏和高开销；现代JVM用三色标记法优化，并通过写屏障等机制保障并发准确性。
Java 使用可达性分析（Reachability Analysis）来判定对象是否存活，根本原因是它能准确、高效地识别出真正“不再被使用”的对象，从而安全回收内存。相比早期的引用计数法，可达性分析能彻底解决循环引用导致的内存泄漏问题，也更契合 Java 的运行时结构（如栈帧、静态变量、本地方法栈等根节点的天然存在）。
什么是可达性分析
可达性分析是一种从一组称为“GC Roots”的对象出发，沿着引用链向下搜索的算法。所有能被 GC Roots 直接或间接引用到的对象都被视为“可达”（即存活），其余对象则被标记为“不可达”，在后续阶段被回收。
简单说：不是看对象有没有被引用，而是看它能不能从程序“活的起点”被找到。
哪些对象可以作为 GC Roots
GC Roots 是分析的起点，必须是 JVM 明确认为“肯定还活着”的对象。主要包括：
立即学习“Java免费学习笔记（深入）”；
- 虚拟机栈（栈帧中的局部变量表）中引用的对象：比如方法里 new 出来的对象，只要还在方法执行中且变量没失效，就属于 GC Roots。
- 本地方法栈中 JNI（Native 方法）引用的对象：Java 调用 C/C++ 代码时，C 层可能持有 Java 对象引用。
-
方法区中类静态属性（static 字段）引用的对象：例如 public static List
cache = new ArrayList(); 中的 ArrayList 实例。 - 方法区中常量引用的对象：比如字符串常量池里的字符串字面量（String s = "hello"; 中的 "hello"）。
- 正在被同步锁（synchronized）持有的对象：该对象至少被一个线程锁定，说明仍在被活跃使用。
为什么不用引用计数法
引用计数法为每个对象维护一个计数器，每次新增引用 +1，引用失效 -1；计数为 0 就回收。看似简单，但它有致命缺陷：
- 无法处理循环引用：A 引用 B，B 又引用 A，两者计数都不为 0，但外部已没有任何变量指向它们——内存实际已泄露。
- 计数操作开销大：每次赋值、传参、出作用域都要更新计数，在多线程下还需加锁保证原子性，性能差。
- 与 JVM 运行模型不匹配：JVM 天然拥有明确的“活动上下文”（如栈帧、静态区），更适合基于上下文做整体扫描，而非逐对象维护状态。
可达性分析的实际执行细节
现代 JVM（如 HotSpot）采用“三色标记法”优化可达性分析过程，避免 STW（Stop-The-World）时间过长：
- 白色：初始全白，表示“尚未扫描、默认不可达”。
- 灰色：已入队待扫描，但其引用的其他对象还没处理完。
- 黑色：已扫描完毕，且它引用的所有对象也都被标记为非白（灰或黑）。
标记过程从 GC Roots 开始，将它们涂灰并入队；每次取一个灰色对象，将其引用的对象涂灰（若为白），自身涂黑；直到灰色队列为空。最终仍为白色的对象即可回收。
注意：并发标记阶段可能发生对象引用变更（如用户线程修改引用），JVM 通过写屏障（Write Barrier）+ SATB（Snapshot-At-The-Beginning）等机制保障准确性，防止漏标。
基本上就这些。可达性分析不是玄学，它本质是把“对象是否还在业务逻辑中起作用”这个语义问题，转化成了“能否从程序运行现场反向追踪到它”的图遍历问题——清晰、可靠、可工程化实现。
