jvm判断对象是否可回收的核心是可达性分析算法：从gc roots（如虚拟机栈局部变量、静态字段、常量池引用、jni引用、被锁对象等）出发沿引用链标记可达对象，未被标记的即为可回收垃圾，该过程基于引用关系而非内存区域顺序。
JVM 判断对象是否可回收，核心在于“哪些对象还活着”，而不是按内存区域顺序逐个扫描。所谓“引用回收顺序”，实际是指 JVM 依据 可达性分析算法，从一组固定的根对象（GC Roots）出发，沿着引用链向下遍历，最终标记出所有可达对象；未被标记的即为可回收对象。这个过程不按堆中 Eden、Survivor、Old 的物理位置顺序执行，而是以引用关系图的逻辑路径为依据。
GC Roots 是起点，不是终点
回收判定的第一步永远是定位 GC Roots，它们是绝对可信的“活对象锚点”。JVM 不会先查年轻代再查老年代，而是直接从以下几类对象开始追踪：
- 虚拟机栈中每个线程的栈帧里的局部变量、方法参数（例如正在执行的方法中 new 出来的对象引用）
- 方法区中类的静态字段所引用的对象（如
public static List<string> cache = new ArrayList();</string>中的 ArrayList 实例） - 方法区中常量池引用的对象（如字符串字面量
"hello"对应的 String 对象） - 本地方法栈中 JNI 引用的对象（比如通过
System.loadLibrary()加载的 native 资源） - 被 synchronized 锁住的 Java 对象（即处于 Monitor 状态的对象）
引用链决定可达性，与区域无关
一旦确定了 GC Roots，JVM 就递归遍历所有直接或间接被其引用的对象。这个过程完全基于引用关系，和对象在堆中的物理位置（Eden 还是 Old）无关。例如：
- 一个老年代对象 A 可能被栈中某个局部变量直接引用 → A 是存活的
- 一个新生代 Eden 中的对象 B 被老年代对象 C 引用 → B 因此可达，不会被 Minor GC 回收
- 两个 Survivor 区中的对象 D 和 E 彼此引用，但无任何 GC Root 指向它们 → 它们不可达，会被回收（可达性分析能解决循环引用问题）
分代收集影响的是回收时机和范围，不是判定顺序
虽然堆被划分为年轻代（Eden + S0/S1）和老年代，但“分代”只决定 什么时候触发哪一类 GC，不改变对象存活判定逻辑：
- Minor GC：只清理年轻代，但仍需扫描从 GC Roots 到年轻代的全部引用链（包括老年代→年轻代的跨代引用，这类引用由记忆集 Remembered Set 记录）
- Full GC：通常扫描整个堆 + 方法区，但判定方式仍是同一套可达性分析，不是“先扫 Eden，再扫 Survivor，最后扫 Old”
- 跨代引用是关键细节：老年代对象可能持有对年轻代对象的引用，JVM 通过卡表（Card Table）或记忆集机制快速识别这些引用，避免每次 Minor GC 都扫描整个老年代
四种引用类型影响的是回收优先级，不是回收顺序
强、软、弱、虚引用的区别体现在 GC 决策阶段，而非遍历顺序：
- 强引用：只要可达，永不回收
- 软引用：仅在内存不足、即将 OOM 前才考虑回收（用于缓存）
- 弱引用：GC 时只要不可达强/软引用链，就会被回收（如 WeakHashMap 的 key）
- 虚引用：仅用于跟踪对象被回收的时间点，不影响是否回收的判定
这些引用类型的处理，是在可达性分析完成、标记出“本该回收”的对象之后，再根据引用强度做二次筛选，属于回收策略层，不是基础判定流程的一部分。
