Java垃圾回收机制演进是围绕吞吐量、延迟、内存规模三者平衡的持续优化：从分代回收（新生代复制+老年代标记整理）、并行/并发GC（Parallel/CMS），到区域化G1及低延迟ZGC/Shenandoah，逐步实现更精细灵活的回收策略。
Java 垃圾回收机制的演进，本质是一场围绕“吞吐量、延迟、内存规模”三者平衡的持续优化。它不是简单替换，而是根据硬件发展（多核普及、内存增大）、应用需求（高并发、实时响应）和 JVM 实践反馈，逐步构建出更精细、更灵活的回收策略体系。
分代回收：从经验直觉到工程落地
早期 JVM（JDK 1.0–1.4）采用统一堆+标记-清除，效率低且易碎片化。开发者观察到一个关键现象：绝大多数对象“朝生暮死”，少数存活对象则长期驻留。基于此，分代假设被正式引入——堆被划分为新生代（Eden + Survivor）与老年代。新生代用复制算法（快、无碎片），老年代用标记-整理或标记-清除（节省空间）。这成为后续所有主流 GC 的基础结构，至今未变。
并行与并发：从单线程停顿到多线程协作
Serial GC 单线程回收，STW 时间随堆增大而飙升，无法适应服务器场景。Parallel GC（吞吐量优先）通过多线程加速 Minor GC 和 Full GC，显著缩短总暂停时间；CMS 则首次将“并发”引入老年代回收——在应用运行时并发标记、并发预清理，只在初始标记和重新标记阶段短暂 STW，大幅降低延迟。但 CMS 因浮动垃圾和并发模式失败导致 Full GC 而逐渐被淘汰。
区域化与增量式：从整堆扫描到按需处理
G1 是重要转折点：它放弃固定代边界，将堆划分为多个大小相等的 Region，按“垃圾优先”策略选择回收集，并支持并发标记+混合回收。它首次实现可预测的停顿模型（用户可设目标停顿时间），兼顾吞吐与延迟。ZGC 和 Shenandoah 进一步突破：它们采用着色指针（ZGC）或读屏障（Shenandoah），让绝大部分 GC 工作（标记、转移、重映射）都与应用线程并发执行，将 STW 控制在毫秒级（通常
立即学习“Java免费学习笔记（深入）”；
自适应与智能化：从静态配置到动态决策
现代 GC（如 ZGC、Shenandoah，以及 G1 的最新优化）不再依赖人工调参决定何时回收、回收多少。它们持续监控堆使用率、分配速率、暂停历史等指标，自动触发回收、动态调整回收集大小、甚至切换回收策略。JVM 本身也在演化：JDK 17 后默认启用 G1，JDK 21 正式发布 ZGC 为生产就绪，JDK 22 引入 Elastic Metaspace 自动调节元空间，体现的是整个内存管理正走向更自主、更轻量、更贴近应用节奏的方向。
