jvm垃圾回收机制通过分代假设、可达性分析和特定算法自动管理对象生命周期。堆分为新生代（eden/survivor）和老年代，按对象存活时间差异化回收；以gc roots为起点标记不可达对象；引用类型决定回收时机；回收器从serial/parallel到zgc/shenandoah演进，适配不同延迟与吞吐需求；调优需结合参数设置、日志分析与内存行为观察。
JVM 垃圾回收机制的核心，是用自动化方式解决“对象何时该释放”这个根本问题。它不靠程序员手动干预，而是依托分代假设、可达性分析和特定回收算法，在堆内存中动态识别并清理不可达对象——既避免了内存泄漏，也绕开了野指针风险。
分代设计：按对象寿命差异化管理
JVM 把堆划分为新生代（Young）和老年代（Old），本质是利用“绝大多数对象朝生夕死”这一经验规律。
- 新对象默认分配在 Eden 区；Minor GC 触发时，存活对象被复制到 Survivor 区（S0/S1），经历多次幸存后晋升至老年代
- 老年代存放长期存活对象，GC 频率低但耗时长，通常采用标记-清除或标记-整理算法
- JDK 8 起永久代被元空间（Metaspace）取代，类元数据使用本地内存，可通过 -XX:MaxMetaspaceSize 限制大小，防止无节制增长
对象生死判定：以 GC Roots 为起点的可达性分析
引用计数法因无法处理循环引用已被淘汰。当前主流采用可达性分析——从 GC Roots 出发遍历引用链，不可达即视为可回收。
- GC Roots 包括：虚拟机栈中的局部变量、类的静态字段、常量池引用、本地方法栈引用等
- 四种引用类型影响回收时机：强引用永不回收；软引用在内存不足时回收（适合缓存）；弱引用在下次 GC 必回收（如 ThreadLocal）；虚引用仅用于回收通知
回收器演进：从吞吐优先到低延迟与大内存支持
不同回收器针对不同场景做了取舍：
- Serial / Parallel：单线程/多线程，吞吐量优先，适合批处理或资源受限环境
- CMS：并发标记清除，低停顿但已废弃（JDK 14+ 移除），易产生碎片且浮动垃圾难处理
- G1：分区式回收，兼顾吞吐与延迟，通过预测模型控制停顿时间，适合 4–64GB 堆场景
- ZGC / Shenandoah：基于读屏障的并发回收器，GC 停顿稳定控制在 10ms 内，支持 TB 级堆，是超低延迟系统的首选
调优关键点：参数、日志与行为观察缺一不可
调优不是调参游戏，而是结合应用特征持续验证的过程：
- 合理设置堆边界：-Xms 与 -Xmx 设为相等可避免动态扩容开销；-XX:NewRatio 或 -Xmn 控制新生代占比
- 选择匹配业务特性的回收器：Web API 服务倾向 G1 或 ZGC；后台计算任务可用 Parallel GC
- 开启 GC 日志（如 -Xlog:gc*,gc+heap=debug），关注停顿时间、晋升速率、元空间增长趋势
- 警惕隐性泄漏：静态集合缓存未清理、监听器未注销、线程局部变量未 remove，都可能拖慢 GC 效率
