Java垃圾回收（GC）是JVM自动运行的内存管理机制，核心区域为堆和元空间；主流算法包括标记-清除（老年代，产生碎片）、标记-复制（年轻代，无碎片但空间减半）、标记-整理（解决碎片，移动开销大），并基于分代假说采用分代收集策略；常用收集器有Serial、Parallel、G1（JDK9+默认）、ZGC/Shenandoah（超低延迟）。
Java 垃圾回收（GC）不是“怎么用”的 API，而是 JVM 自动运行的内存管理机制。你无法像调用方法一样主动“使用”某个算法或收集器，但可以通过 JVM 启动参数选择合适的垃圾收集器，并结合代码习惯影响其行为效果。核心在于理解算法原理、分代特点和收集器适用场景，再做合理配置。
先搞清：哪些区域真正需要 GC？
程序计数器、虚拟机栈、本地方法栈随线程生灭，内存分配确定，不参与 GC。真正需要动态回收的是：
- 堆（Heap）：存放所有对象实例，是 GC 主战场；
- 方法区（Metaspace，JDK 8+）：主要回收废弃的类、常量池中无用的字符串等，频率远低于堆。
所以日常关注的“GC 算法”和“收集器”，基本都围绕堆展开。
主流垃圾回收算法怎么起作用？
算法本身由 JVM 内部实现，你不需要写代码调用，但得知道它如何影响你的应用：
立即学习“Java免费学习笔记（深入）”；
- 标记-清除（Mark-Sweep）：先标记所有存活对象，再清除未标记的。优点是节省空间；缺点是产生内存碎片，且需 Stop-the-World（STW）。老年代常用此逻辑（如 Serial Old、CMS 的初始标记/清除阶段）。
- 标记-复制（Mark-Copy）：把内存分成两块，只用其中一块，回收时把存活对象复制到另一块并清空原区域。无碎片、效率高，但浪费一半空间。年轻代 Eden + Survivor 区正是基于此设计（比例通常 8:1:1）。
- 标记-整理（Mark-Compact）：标记后，把所有存活对象往一端移动，再清理边界外内存。解决碎片问题，但移动成本比复制高。G1 和 ZGC 的部分阶段、Serial Old 默认行为都含整理逻辑。
- 分代收集（Generational Collection）：不是独立算法，而是策略——根据对象生命周期分代管理。年轻代（短命）用复制算法高频回收（Minor GC），老年代（长命）用标记-清除或标记-整理低频回收（Major/Full GC）。这是现代 JVM 的默认范式。
常见垃圾收集器怎么选？
收集器是算法的具体实现，通过 JVM 参数启用。不同版本支持不同组合，以 JDK 17~21 为主流参考：
-
Serial（单线程）：年轻代用复制，老年代用标记-整理。适合单核、小内存客户端场景（如嵌入式）。启动参数：
-XX:+UseSerialGC。 -
Parallel（吞吐量优先）：多线程并行回收，年轻代复制，老年代标记-整理。适合后台批处理、科学计算等追求高吞吐的应用。参数：
-XX:+UseParallelGC（默认 JDK 8~13），老年代自动配 Parallel Old。 - CMS（已弃用）：老年代尝试并发标记清除（减少 STW），但易发生 Concurrent Mode Failure 导致 Full GC。JDK 9 起弃用，JDK 14 彻底移除，不要在新项目中使用。
-
G1（通用均衡）：将堆划分为多个 Region，可预测停顿时间（
-XX:MaxGCPauseMillis=200）。兼顾吞吐与延迟，适合大堆（4GB+）、响应敏感型服务。JDK 9+ 默认，参数：-XX:+UseG1GC。 -
ZGC / Shenandoah（超低延迟）：并发标记、并发移动、几乎全程不 STW（ZGC 最大停顿通常 -XX:+UseZGC 或
-XX:+UseShenandoahGC。
实际配置建议
不用从零手写 GC 参数，按场景走推荐路径：
- 开发/测试环境：用默认 G1 即可，无需额外配置；
- 微服务（堆 ≤ 4GB）：保持 G1，默认参数往往足够；
- 大数据分析/批处理（高吞吐）：用 Parallel GC，加
-XX:MaxGCPauseMillis适当放宽停顿目标； - 实时风控、游戏服务器（亚秒级延迟）：评估 ZGC，注意需 JDK 15+ 且 OS 支持（Linux 4.14+）；
- 观察效果：务必加日志，如
-Xlog:gc*:file=gc.log:time,tags（JDK 10+），用 GCViewer 或 GCEasy 分析停顿、频率、晋升情况。
记住：没有“最好”的收集器，只有“更适合当前负载和 SLA”的选择。算法决定能力边界，参数调优只是微调杠杆，真正的 GC 效果，70% 取决于代码是否避免大对象、过早晋升、内存泄漏等人为因素。
