Java垃圾回收机制与GC原理全解析

Java垃圾回收并非依赖单一算法，而是根据对象生命周期、内存区域和停顿目标等动态组合运用复制、标记-清除、标记-整理等多种策略；其核心判断依据是可达性分析（从GC Roots出发追踪引用链），彻底摒弃了存在循环引用缺陷的引用计数法；分代收集作为关键内存组织策略，将堆划分为年轻代与老年代，分别适配高效率的复制算法和低频次的整理或清除算法，以匹配“大部分对象短命”的真实场景；真正影响GC效果的不是算法选择本身，而是代码中对象创建方式、引用管理习惯及JVM参数配置，因此读懂GC日志、识别晋升异常、定位内存泄漏源头，远比追求“最优算法”更为重要。

GC算法不是“一种算法”，而是几类策略的统称

Java里没有唯一的GC算法，而是根据对象生命周期、内存区域、停顿目标等，组合使用多种基础算法。你写的代码触发的其实是JVM自动选择的回收逻辑——它背后可能是复制、标记-清除或标记-整理中的一种，甚至混用。比如 new Object() 分配在 Eden 区，YGC 时大概率走复制算法；而老年代对象存活久，CMS 或 G1 回收时更倾向标记-清除或标记-整理。

为什么可达性分析是判断“该不该回收”的唯一依据

引用计数法看着简单，但只要出现 objA.ref = objB; objB.ref = objA; 这种循环引用，计数器就卡在非零值，对象永远无法回收——JVM 实测会直接忽略这种对象（如你贴的 ReferenceCountingGC 示例），证明它根本没用引用计数。

真正起作用的是可达性分析：从 GC Roots 出发，沿着引用链能走到的对象才算“活着”。这些 Roots 包括：
虚拟机栈中的局部变量
方法区的静态字段（如 public static final String MSG）
常量池里的字符串字面量
本地方法栈的 JNI 引用

注意：方法区本身不被 GC 管理，但它里面存的引用可以当 Roots——这是很多排查内存泄漏时容易漏掉的关键点。

分代收集不是算法，而是组织内存的“分区策略”

Java 堆按对象年龄划成年轻代（Eden + S0/S1）和老年代，不是为了炫技，而是因为统计表明：98% 的对象朝生暮死。所以：
- 年轻代用复制算法（快、无碎片），每次 YGC 只扫 Eden 和一个 Survivor
- 老年代对象活得久，用标记-整理（G1/ZGC 除外），避免频繁移动大对象
- 元空间（Metaspace）不参与堆 GC，类卸载需满足三个硬条件：所有实例已回收、ClassLoader 已被回收、Class 对象无任何强引用

别指望加个 -XX:+UseSerialGC 就能解决 OOM——如果对象不断晋升到老年代（比如缓存没设上限、Stream.toList() 拿了超大数据集），再好的算法也扛不住。

别迷信“最优算法”，先看 GC 日志里真实发生了什么

用 -Xlog:gc*:file=gc.log:time,uptime,pid,tags,level（JDK 9+）或旧版 -XX:+PrintGCDetails -XX:+PrintGCTimeStamps 抓日志，重点盯三件事：
- 是 GC pause (G1 Evacuation Pause)（年轻代）还是 Full GC（全局停顿）？
- 每次回收后老年代占用是否持续上涨？说明有内存泄漏或晋升过快
- Allocation Failure 频繁出现？大概率是 Eden 太小或对象创建速率过高

比如看到日志里反复出现 GC(78) Pause Young (Normal) (G1 Evacuation Pause) 245M->22M(512M)，说明年轻代回收高效；但若某次变成 GC(102) Pause Full (G1 Evacuation Pause) 480M->479M(512M)，基本就是老年代快满了，得查谁在疯狂 new 大对象或缓存没清理。

GC 算法本身是透明的，真正要调的从来不是“选哪个算法”，而是对象怎么写、引用怎么管、参数怎么配——算法只是执行者，你才是调度员。

到这里，我们也就讲完了《Java垃圾回收机制与GC原理全解析》的内容了。个人认为，基础知识的学习和巩固，是为了更好的将其运用到项目中，欢迎关注golang学习网公众号，带你了解更多关于的知识点！