Java对象回收的核心是可达性分析，即从GC Roots出发遍历引用链判定对象是否可达；GC Roots包括虚拟机栈局部变量、静态字段、常量、JNI引用等；遍历方式（DFS/BFS）仅为实现细节，不影响可达性判定结果。
1. 可达性分析中对象图的遍历方式并不固定为 DFS 或 BFS
JVM 从 GC Roots（如线程栈帧中的局部变量、静态字段、JNI 引用等）出发，标记所有可达对象。这个过程本质是遍历一个有向图（对象引用关系图），但：
- JVM 实现不规定必须用栈（DFS）或队列（BFS）——实际由具体 GC 算法和底层优化决定；
- 现代 JVM（如 HotSpot）在标记阶段多采用**三色标记 + 并发/并行扫描**，强调吞吐与低延迟，而非遍历顺序的人为控制；
- 即使单线程标记，也更倾向使用迭代+栈模拟（类似 DFS）以避免递归爆栈，但这只是工程实现细节，不是算法设计原则。
2. 某些 GC 算法的“行为特征”被类比为 DFS/BFS，但属误用
有人把某些现象通俗类比，容易引发混淆：
- “深度优先”错觉：比如 CMS 或 G1 在并发标记时，对某个对象链（A→B→C→D）连续追踪，看起来“一路深入”，实则是引用链自然展开，并非主动选择 DFS 策略；
- “广度优先”错觉：ZGC 或 Shenandoah 的并发标记会分块处理堆内存，按 Region 或 Page 扫描，看似“一层层推进”，其实是并行任务调度，与 BFS 的层级遍历逻辑无关；
- 真正 BFS 需要显式维护队列、按距离分层访问（如“离 GC Root 距离为 1 的所有对象 → 距离为 2 的……”），GC 中既无此需求，也不这样做。
3. 真正影响回收的关键不是遍历顺序，而是可达性定义与标记精度
决定一个对象是否被回收的，只有两点：
- 该对象能否从任意 GC Root 出发，通过引用链到达（即是否“可达”）；
- 标记-清除/标记-整理/复制等后续阶段如何处理不可达对象。
DFS/BFS 对可达性判定结果**完全等价**——只要遍历完整、无遗漏，最终标记出的存活对象集合是一样的。顺序只影响标记过程的局部缓存友好性或并发粒度，不改变语义。
立即学习“Java免费学习笔记（深入）”；
4. 开发者无需关注遍历方式，但需理解 GC Roots 和引用类型
如果你在排查内存泄漏或调优 GC，重点应放在：
- 哪些对象被意外持有（如静态 Map 缓存、ThreadLocal、未关闭的监听器）；
- 软/弱/虚引用的行为差异；
- 不同 GC 器（Serial、Parallel、CMS、G1、ZGC）的触发条件与暂停特点。
纠结“JVM 是用 DFS 还是 BFS 回收对象”，就像问“汽车发动机是按螺旋还是锯齿方式燃烧汽油”——它描述的是底层物理过程，但对驾驶和维修毫无指导意义。
