每日面试题12：JVM垃圾回收机制
上一题我们谈论到什么是JVM，今天趁热打铁，来了解一下JVM的垃圾回收机制。
JVM垃圾回收机制详解：从原理到实践
引言
在Java程序运行过程中，对象的创建与销毁是常态。若依赖开发者手动管理内存（如C/C++的malloc/free），不仅容易引发内存泄漏（对象不再使用但未被释放）或内存溢出（内存耗尽），还会大幅增加开发复杂度。为此，JVM（Java虚拟机）内置了自动垃圾回收机制（Garbage Collection, GC），通过智能识别并回收不再使用的对象，释放内存空间，让开发者专注于业务逻辑。
本文将从垃圾回收的核心原理出发，深入解析JVM主流垃圾回收器的工作机制、适用场景及选择策略。
一、垃圾回收的核心原理：可达性分析
垃圾回收的本质是识别并回收“无用对象”。JVM采用可达性分析算法（Reachability Analysis）作为核心判定依据，其逻辑如下：
1.1 什么是“可达对象”？
JVM会从一组称为GC Roots的根对象出发，通过引用链（Reference Chain）遍历所有能被访问到的对象。这些被遍历到的对象被标记为“存活对象”，反之则被视为“垃圾对象”，等待回收。
1.2 GC Roots包含哪些对象？
GC Roots是JVM认定的“活对象起点”，具体包括：
- 虚拟机栈（栈帧中的本地变量表）：方法执行时栈帧中引用的对象（如方法参数、局部变量）。
- 方法区（元空间）中的静态属性：类的静态变量（
static修饰的对象）。 - 本地方法栈（JNI）：Native方法（如C/C++实现的接口）中引用的对象。
- JVM内部引用：如基本类型对应的
Class对象、常驻的异常对象（NullPointerException）、系统类加载器等。 - 其他临时引用：如JVM内部调试、JMX监控等场景产生的临时引用。
1.3 可达性分析的挑战：并发标记与浮动垃圾
直接对所有对象进行全量遍历会带来较高的性能开销。因此，现代GC算法通常采用并发标记（与应用线程同时执行）优化，但需解决两个问题：
- 三色标记法：用白（未访问）、灰（已访问但子对象未访问）、黑（已访问且子对象已访问）三种颜色标记对象。并发标记时，若应用线程修改了对象引用（如将白色对象指向黑色对象），可能导致漏标（本应回收的对象未被标记）。为此，CMS和G1等回收器引入增量更新（Incremental Update）或原始快照（Snapshot At The Beginning, SATB）机制，记录引用变更，后续重新扫描修正。
- 浮动垃圾（Floating Garbage）：并发清理阶段，应用线程可能产生新的垃圾对象（未被本次回收处理），需留待下一次GC回收。
二、主流垃圾回收器详解
JVM提供了多种垃圾回收器，适用于不同场景（如单核/多核、低延迟/高吞吐、小内存/大内存）。理解它们的差异是调优的关键。
2.1 串行回收器（Serial GC）
核心特点：单线程执行GC，回收时暂停所有应用线程（STW, Stop The World）。
工作流程
- 新生代使用Serial Copying（复制算法）：将存活对象复制到Survivor区，清空Eden区。
- 老年代使用Serial Mark-Sweep-Compact（标记-清除-整理算法）：标记存活对象，清除未标记对象，整理内存碎片。
适用场景
- 单核CPU或内存资源有限的场景（如早期的客户端程序、小型Java应用）。
- 对停顿时间不敏感（因STW时间与堆大小正相关，大内存下停顿明显）。
启用参数
-XX:+UseSerialGC # 启用Serial+Serial Old组合2.2 并行回收器（Parallel GC，又称吞吐量优先回收器）
核心特点：多线程并行执行GC，通过增加线程数缩短回收时间；回收时仍需STW，但停顿时间比串行回收器更短。
工作流程
- 新生代使用ParNew（多线程版Serial Copying）。
- 老年代使用Parallel Old（多线程版Mark-Sweep-Compact，JDK7及之前）或直接复用G1（JDK9+）。
核心目标
最大化吞吐量（单位时间内处理的任务量），适合计算密集型应用（如后台数据处理、批量任务）。
关键参数
-XX:+UseParallelGC # 启用ParNew+Parallel Old组合（JDK7及前）
-XX:MaxGCPauseMillis=200 # 目标最大停顿时间（毫秒，默认200ms）
-XX:GCTimeRatio=19 # 吞吐量目标（GC时间与应用时间比为1:19，默认99）2.3 CMS并发回收器（Concurrent Mark-Sweep GC）
核心特点：以低停顿时间为目标，通过“并发标记+并发清除”减少STW时间，但存在内存碎片问题。
工作流程（四阶段）
- 初始标记（STW）：仅标记GC Roots直接关联的对象（耗时极短）。
- 并发标记：与应用线程并行遍历GC Roots的引用链（耗时较长，但不停顿）。
- 重新标记（STW）：修正并发标记阶段因应用线程修改引用导致的漏标对象（耗时比初始标记长，但远短于串行标记）。
- 并发清除：与应用线程并行清除未标记的垃圾对象（无STW）。
局限性
- 内存碎片：采用标记-清除算法，回收后内存空间不连续，可能导致大对象无法分配（触发Full GC）。
- 浮动垃圾：并发清除阶段产生的新垃圾需等待下次GC处理。
适用场景
- 对停顿时间敏感的中、小内存应用（如Web服务器、API网关）。
启用参数（JDK8及前）
-XX:+UseConcMarkSweepGC # 启用ParNew+CMS+Serial Old组合
-XX:+UseCMSInitiatingOccupancyOnly # 基于老年代占用率触发GC（避免频繁GC）
-XX:CMSInitiatingOccupancyFraction=70 # 老年代占用70%时触发CMS（默认92%）注意：JDK9起CMS被标记为废弃（
@Deprecated），JDK14正式移除。
2.4 G1回收器（Garbage-First GC）
核心特点：面向服务端应用，通过分区回收和停顿预测平衡吞吐量与延迟，是JDK9+的默认回收器。
核心设计
- 堆内存分区：将堆划分为多个大小相等的Region（默认2048个，每个Region 1~32MB），每个Region可以是Eden、Survivor或Old区（动态调整）。
- 停顿预测模型：跟踪每个Region的回收收益（回收空间大小）和所需时间，选择“收益最大且耗时最短”的Region集合进行回收（每次停顿时间不超过
MaxGCPauseMillis）。 - 混合回收（Mixed GC）：不仅回收新生代，还会选择性回收老年代的Region，避免Full GC。
工作流程
- 年轻代回收（Young GC）：回收Eden区和部分Survivor区，存活对象晋升到Survivor或老年代。
- 全局并发标记：标记所有存活对象（与应用线程并发执行），生成Region回收优先级列表。
- 混合回收（Mixed GC）：根据优先级列表，回收部分老年代Region，直到达到停顿时间目标。
优势
- 低延迟（默认停顿≤200ms）与高吞吐量的平衡。
- 避免内存碎片（采用复制算法回收Region）。
适用场景
- 大内存（堆内存≥4GB）、对停顿时间有明确要求的服务端应用（如微服务、中间件）。
启用参数
-XX:+UseG1GC # 启用G1回收器
-XX:MaxGCPauseMillis=200 # 目标最大停顿时间（默认200ms）
-XX:G1HeapRegionSize=4m # Region大小（1~32MB，默认自动计算）2.5 ZGC回收器（Z Garbage Collector）
核心特点：JDK11引入，JDK15成为生产可用，目标是极低停顿（≤10ms）和超大堆支持（TB级），适用于实时性要求极高的场景。
核心技术
- 染色指针（Colored Pointers）：将对象地址的高4位（称为“颜色位”）标记为四种状态（已标记、已转移、已重映射、未标记），避免传统标记-清除算法的内存扫描开销。
- 读屏障（Load Barrier）：在对象访问时插入轻量级指令，动态修复指针状态，保证并发操作的准确性。
- 并发处理：标记、转移、重映射阶段均与应用线程并发执行，仅保留极短的STW阶段。
优势
- 停顿时间与堆大小无关（即使堆为16TB，停顿仍≤10ms）。
- 支持超大堆内存（理论上无上限）。
适用场景
- 低延迟、高吞吐的超大内存应用（如实时数据处理、大数据平台、云原生中间件）。
启用参数
-XX:+UseZGC # 启用ZGC回收器（JDK11+）
-XX:ZCollectionInterval=100 # 强制GC间隔（毫秒，默认自适应）三、垃圾回收器对比与选择建议
| 回收器 | 线程数 | 停顿时间 | 内存占用 | 适用场景 | JDK版本支持 |
|---|---|---|---|---|---|
| Serial | 单线程 | 长 | 低 | 单核客户端、小内存 | 所有版本 |
| Parallel | 多线程 | 中 | 低 | 吞吐量优先的多核应用 | 所有版本 |
| CMS | 多线程 | 短 | 高 | 低延迟的中、小内存应用 | JDK4~JDK14（废弃） |
| G1 | 多线程 | 中短 | 中 | 大内存、低延迟服务端应用 | JDK9+（默认） |
| ZGC | 多线程 | 极短 | 高 | 超大内存、极低延迟场景 | JDK11+（生产可用） |
选择策略
- 单核/小内存/客户端应用：选Serial GC（简单高效）。
- 多核/吞吐量优先/后台计算：选Parallel GC（最大化任务处理量）。
- 多核/低延迟/中、小内存：选CMS GC（JDK8及前）或G1 GC（JDK9+）。
- 超大内存/极低延迟：选ZGC GC（JDK11+，需评估硬件资源）。
四、实践建议
- 开启GC日志：通过参数
-Xlog:gc*:gc.log:time,level,tags记录GC行为，便于分析。 - 监控工具：使用
jstat（查看GC统计）、jconsole/VisualVM（图形化监控）、GCEasy（在线分析日志）等工具定位问题。 - 调优方向：根据应用类型（吞吐量/延迟）选择回收器，调整堆大小（
-Xms/-Xmx）、Region大小（G1/ZGC）等参数。 - 避免过度优化：优先保证功能正确性，再通过监控数据针对性调优。
总结
JVM垃圾回收机制是Java高效运行的基石，理解不同回收器的原理与适用场景，能帮助开发者根据业务需求选择最优配置，平衡性能与资源消耗。随着JVM技术的演进（如ZGC的普及），未来的GC将更智能、更高效，持续赋能高并发、低延迟的现代应用。