Java使用可达性分析判定对象存活，因其能准确高效识别真正不再被使用的对象并解决循环引用问题；该算法从GC Roots出发沿引用链搜索，可达对象存活，不可达者回收；GC Roots包括虚拟机栈、本地方法栈、方法区静态变量与常量、同步锁对象；相比引用计数法，它避免了循环引用内存泄漏和高开销；现代JVM用三色标记法优化，并通过写屏障等机制保障并发准确性。
Java 使用可达性分析（Reachability Analysis）来判定对象是否存活，根本原因是它能准确、高效地识别出真正“不再被使用”的对象，从而安全回收内存。相比早期的引用计数法，可达性分析能彻底解决循环引用导致的内存泄漏问题，也更契合 Java 的运行时结构（如栈帧、静态变量、本地方法栈等根节点的天然存在）。
什么是可达性分析
可达性分析是一种从一组称为“GC Roots”的对象出发，沿着引用链向下搜索的算法。所有能被 GC Roots 直接或间接引用到的对象都被视为“可达”（即存活），其余对象则被标记为“不可达”，在后续阶段被回收。
简单说：不是看对象有没有被引用，而是看它能不能从程序“活的起点”被找到。
哪些对象可以作为 GC Roots
GC Roots 是分析的起点，必须是 JVM 明确认为“肯定还活着”的对象。主要包括：
立即学习“Java免费学习笔记（深入）”；
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
- 虚拟机栈（栈帧中的局部变量表）中引用的对象：比如方法里 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）等机制保障准确性，防止漏标。
基本上就这些。可达性分析不是玄学，它本质是把“对象是否还在业务逻辑中起作用”这个语义问题，转化成了“能否从程序运行现场反向追踪到它”的图遍历问题——清晰、可靠、可工程化实现。
