Java采用可达性分析算法判定对象可回收：从GC Roots（如栈中局部变量、静态变量、常量池引用、JNI引用）出发，沿强引用链搜索，不可达对象即被标记为可回收；回收分标记、清除/整理、更新引用三阶段，不立即回收，且finalize已废弃。
Java 垃圾回收（GC）机制自动识别并回收不再被任何活动线程可达的对象，核心在于“可达性分析”，而非简单判断对象是否“无用”。
哪些对象会被判定为可回收？
Java 采用根可达性（GC Roots）分析法：从一组称为 GC Roots 的对象出发，沿着引用链向下搜索。所有无法从 GC Roots 到达的对象，即被视为“不可达”，标记为可回收。
常见的 GC Roots 包括：
- 虚拟机栈（栈帧中的局部变量表）中引用的对象
- 方法区中类静态属性引用的对象
- 方法区中常量引用的对象（如字符串常量池中的引用）
- 本地方法栈中 JNI（Native 方法）引用的对象
回收过程分几步？
现代主流 GC（如 G1、ZGC）通常按三阶段进行，但基本逻辑一致：
立即学习“Java免费学习笔记（深入）”；
- 标记（Mark）：遍历 GC Roots，标记所有可达对象；未被标记的即为待回收对象
- 清除或整理（Sweep / Compact）：根据算法不同处理内存——CMS 仅清除；Serial、Parallel 会压缩整理；G1 和 ZGC 则按区域回收+复制
- 更新引用（Relocate & Update）：若发生对象移动（如压缩或复制），需修正所有指向该对象的引用（由 JVM 自动完成，对 Java 代码透明）
对象真的“立刻”被回收了吗？
不是。即使对象不可达，也可能经历多次 GC 才真正释放内存：
- 首次标记后，若对象重写了 finalize() 方法（已废弃，不推荐使用），JVM 会将其放入 F-Queue 队列，由低优先级 Finalizer 线程尝试执行一次 finalize；之后再判断是否仍不可达
- 绝大多数对象在第一次 Minor GC 就被回收（尤其新生代中的短生命周期对象）
- 老年代对象回收频率低、耗时长，依赖具体 GC 算法策略（如 G1 的混合回收、ZGC 的并发标记与回收）
开发者能做什么？
你不能强制立即回收，但可以协助 GC 更高效工作：
- 及时将不再使用的引用设为 null（对长生命周期容器或静态集合尤其重要）
- 避免静态集合（如 static Map）无限制添加对象，导致内存泄漏
- 合理使用 WeakReference、SoftReference 处理缓存等场景，让 GC 在需要时自主回收
- 减少大对象直接进入老年代（如超过 -XX:PretenureSizeThreshold 的数组），避免触发 Full GC
