Java对象存活由可达性分析决定，即从GC Roots出发沿引用链可达则存活，否则可回收；GC Roots包括虚拟机栈、本地方法栈、方法区静态属性与常量、同步锁对象；finalize()已废弃，应使用Cleaner或PhantomReference；强、软、弱、虚引用强度递减；循环引用不影响回收。
Java对象的存活状态不是由“是否被引用”简单决定的，而是由可达性分析算法从一组称为GC Roots的根对象出发，沿着引用链追踪——**能被到达的对象视为存活，否则判定为可回收**。关键不在“有没有引用”，而在“能否从GC Roots出发、不中断地抵达”。
哪些对象可以作为GC Roots？
GC Roots是可达性分析的起点，必须是确定存活、不会被回收的引用源。主要包括：
- 虚拟机栈（栈帧中的局部变量表）中引用的对象
- 本地方法栈中JNI（即Native方法）引用的对象
- 方法区中类静态属性引用的对象（如public static Object instance）
- 方法区中常量引用的对象（如public static final String CONST = "hello"）
- 正在被同步锁（synchronized）持有的对象（JVM实现相关，HotSpot中会将锁对象纳入）
引用链中断 ≠ 对象立即死亡
即使某个对象暂时无法从GC Roots到达，它也未必立刻被回收。如果该对象覆盖了finalize()方法（已废弃，仅作原理说明），且尚未执行过该方法，JVM会在回收前将其放入F-Queue队列，由低优先级Finalizer线程尝试执行finalize()。若执行过程中重新与GC Roots建立有效引用（如把自己赋值给某个静态变量），该对象就会“复活”——但这是一次性机会，且不推荐依赖。
现代实践应使用Cleaner或PhantomReference替代finalize()，实现更可控的资源清理。
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
立即学习“Java免费学习笔记（深入）”；
四类引用强度影响可达性判定
Java中引用分为强、软、弱、虚四种，它们在可达性分析中的“抵抗力”不同：
- 强引用（Strong Reference）：最常见形式（如Object obj = new Object()）。只要强引用存在，对象就不可被回收，无论内存是否紧张
- 软引用（SoftReference）：仅当JVM即将发生OOM前，才会尝试回收软引用指向的对象。适合做内存敏感的缓存
- 弱引用（WeakReference）：下一次GC时，无论内存是否充足，都会被回收。常用于构建WeakHashMap等非强制持有场景
- 虚引用（PhantomReference）：无法通过它获取对象实例，唯一作用是关联ReferenceQueue，在对象被GC后收到通知，用于精确控制资源释放时机
注意循环引用并不妨碍回收
Java不采用引用计数法，因此两个互相引用但无外部GC Roots可达的对象（如A → B且B → A，但无任何栈/静态变量指向A或B），会被准确识别为不可达并回收。这是可达性分析相比引用计数的核心优势。
