gc算法是多类策略的统称，非单一算法；java依据对象生命周期等组合使用复制、标记-清除或标记-整理；可达性分析是回收判断唯一依据，引用计数因循环引用缺陷被弃用；分代收集是内存分区策略，按对象年龄划分年轻代与老年代以优化效率。
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免费学习笔记（深入）”；
分代收集不是算法，而是组织内存的“分区策略”
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 算法本身是透明的，真正要调的从来不是“选哪个算法”，而是对象怎么写、引用怎么管、参数怎么配——算法只是执行者，你才是调度员。
