jvm垃圾回收机制核心目标是自动释放内存、防止耗尽、平衡吞吐与延迟；对象回收判定依赖可达性分析（从gc roots出发，不可达即待回收），弃用引用计数因其无法解决循环引用且开销大；实际回收按分代进行——新生代用复制算法（快、无碎片），老年代用标记-整理/清除，minor gc频发停顿短，full gc代价高需避免。
回答 JVM 垃圾回收机制类面试题，关键不是堆砌术语，而是分层讲清逻辑：先说清楚“为什么这么设计”，再说明“怎么判断对象该回收”，最后落到“实际怎么收、收哪里、代价是什么”。面试官真正想听的是你理解背后的权衡，而不是背诵教科书。
从目标切入，别一上来就讲算法
开头可以简明点出 GC 的三个核心目标：
- 自动释放内存，避免手动管理导致的泄漏或崩溃（对比 C/C++）
- 防止内存耗尽——对象只创建不清理，堆迟早撑爆
- 在吞吐量（程序运行时间占比）和延迟（GC停顿时间）之间做取舍，没有银弹
这样比直接说“GC是垃圾收集”更有信息量，也自然引出后续问题：那怎么知道哪些该收？收的时候怎么尽量少卡住业务？
对象判定：重点讲清可达性分析，顺带解释为什么不用引用计数
Java 判定对象是否可回收，用的是可达性分析，不是引用计数。原因很实在：
- 引用计数解决不了循环引用：A 引用 B、B 又引用 A，计数都不为 0，但外部已没人用它们——这种对象就成了“活死人”，内存永远不释放
- 维护计数器要频繁读写，影响性能；而可达性分析虽需 STW，但可批量处理，整体更高效
GC Roots 就是那些“绝对不能被回收”的起点，包括：
- 虚拟机栈中正在使用的局部变量
- 方法区里的静态变量、常量池中的常量
- 本地方法栈中 JNI 调用所引用的对象
只要从这些根出发，顺着引用链能走到某个对象，它就算存活；走不到，就是待回收对象。
回收策略：分代是主线，算法是工具
JVM 不是统一扫全堆，而是按对象“年龄”分区处理——这是基于“弱代假说”：大多数对象朝生暮死，少数活得久。
- 新生代（Eden + Survivor）：对象刚创建时放这里，存活一次 GC 就挪到 Survivor，熬过几次（默认15次）就进老年代；回收用复制算法——快、无碎片，适合大量短命对象
- 老年代：长期存活对象集中地，空间大、对象多、存活率高；回收用标记-整理或标记-清除，避免复制成本过高
- 元空间（JDK8+）：存类元数据，基本不参与常规 GC，除非出现大量动态类加载（如热部署、Groovy脚本）
Minor GC 针对新生代，频率高、停顿短；Full GC 扫全堆（含老年代+元空间），代价大，应尽量避免。
收集器选型：结合场景说差异，别只列名字
不同收集器解决不同痛点：
- ParNew + Parallel Old：追求吞吐量，适合后台批处理任务
- CMS（已废弃）：曾主打低延迟，但并发失败会触发 Serial Old 全局 STW，稳定性差
- G1：兼顾吞吐与延迟，把堆拆成 Region，可预测停顿时间，适合大堆（4G+）
- ZGC / Shenandoah：超低延迟（
如果被问“线上服务该选哪个”，可以补一句：“交易类系统优先 ZGC/G1；定时任务用 Parallel 更稳；老项目没升级 JDK 就得看 CMS 是否还在用。”
不复杂但容易忽略：真正让回答出彩的，往往是一句落地细节——比如“我们压测发现 G1 Mixed GC 在老年代占用超 45% 时开始频繁触发，所以把 InitiatingOccupancyPercent 调到了 35”。
