Java GC 核心原理拆解：从分代回收到 ZGC，读懂垃圾回收的进化与实践-优快云博客

在Java的世界里，垃圾回收（Garbage Collection，简称GC）是支撑“一次编写，到处运行”的核心基石之一。它像一位沉默的“内存管家”，自动清理不再使用的对象，避免内存泄漏与溢出，让开发者无需直面复杂的内存管理难题。但从JDK 1.0的简单回收机制，到如今ZGC实现毫秒级停顿，GC的进化之路充满了技术迭代与权衡。本文将沿着GC的发展轨迹，拆解核心原理，剖析各代回收器的设计思路，最终落脚于现代GC的实践要点。

一、GC的本质：解决什么问题？核心指标是什么？

在深入技术细节前，我们首先要明确GC的核心目标。Java程序运行时，对象被创建在堆内存中，当对象失去引用（即“垃圾”）后，若不及时清理，堆内存会逐渐被耗尽，导致程序崩溃。GC的本质就是自动识别垃圾、回收内存空间、并整理内存碎片的过程。

评价一款GC回收器的优劣，核心看三个指标，这也是GC技术不断进化的核心驱动力：

吞吐量：单位时间内GC占用CPU的比例，即“程序运行时间/(程序运行时间+GC时间)”。高吞吐量意味着程序的业务处理效率更高，适合后台计算、数据分析等批处理场景。
停顿时间：GC执行过程中，程序暂停运行的时间。停顿时间过久会影响用户体验，比如Web应用的响应延迟、游戏的卡顿，因此低停顿是交互式场景的核心诉求。
内存占用：GC机制本身所需的内存开销。回收器的元数据、线程栈等都会占用额外内存，需要在功能与开销间平衡。

这三个指标往往相互制约，比如为了降低停顿时间，可能需要牺牲部分吞吐量或增加内存占用。GC的进化史，本质就是不断优化这三者平衡的历史。

二、分代回收：GC的“黄金假设”与经典实现

早期GC回收器面临的核心问题是：对整个堆内存进行扫描和回收，会导致过长的停顿时间。而分代回收机制的出现，基于一个“黄金假设”——对象的生命周期具有明显的两极分化特征：

大部分对象（约90%）创建后很快就会变成垃圾，比如方法内的局部变量。
少数对象能长期存活，甚至伴随程序的整个生命周期，比如静态变量、缓存对象。

基于此，JVM将堆内存划分为不同的区域（代），针对不同区域的对象特征，采用不同的回收策略，实现“按需回收”，从而优化性能。

2.1 经典分代内存模型

经典的分代模型将堆分为年轻代（Young Generation）、老年代（Old Generation）和永久代（Permanent Generation，JDK 8后被元空间Metaspace替代）：

年轻代：存放刚创建的对象，分为Eden区和两个大小相等的Survivor区（From和To）。Eden区占比最大（通常是年轻代的80%），对象优先在Eden区创建；Survivor区用于存放Eden区回收后存活的对象。
老年代：存放从年轻代存活下来的“长寿对象”（通常经过多次回收仍存活的对象会被晋升到老年代）。老年代的对象生命周期长，回收频率低于年轻代。
元空间：存放类元数据、常量池等信息，与永久代不同，元空间直接使用本地内存，避免了永久代内存溢出的问题。

2.2 分代回收的核心流程：Minor GC与Full GC

分代模型下，GC分为两种类型，执行逻辑截然不同：

（1）Minor GC：年轻代的“轻量级回收”

当Eden区满时，触发Minor GC，仅回收年轻代的垃圾。由于年轻代对象大多是“短命鬼”，Minor GC的回收效率极高，停顿时间很短。核心流程如下：

标记Eden区和From Survivor区中存活的对象。
将存活对象复制到To Survivor区，并给对象的“年龄计数器”加1（记录经历的GC次数）。
清空Eden区和From Survivor区，此时From和To Survivor区的角色互换（下次GC时，当前的To区变为From区）。
若对象年龄达到阈值（默认15），或To Survivor区空间不足，将对象晋升到老年代。

（2）Full GC：全堆的“重量级回收”

当老年代满、元空间不足，或调用System.gc()时，会触发Full GC（又称Major GC）。Full GC会同时回收年轻代、老年代和元空间的垃圾，由于扫描范围大、回收逻辑复杂，会导致较长的程序停顿，是性能优化的重点规避对象。

2.3 经典分代回收器：SerialGC与ParallelGC

基于分代模型，JDK提供了多款经典回收器，其中SerialGC和ParallelGC最为常用：

SerialGC（串行回收器）：最基础的回收器，采用单线程执行GC操作。Minor GC时暂停所有用户线程（“Stop The World”，简称STW），用复制算法回收年轻代；Full GC时用标记-清除-整理算法回收老年代。优点是实现简单、内存占用低，适合单CPU环境或嵌入式设备；缺点是STW时间长，无法满足高并发场景。
ParallelGC（并行回收器）：JDK 8的默认回收器，核心优化是采用多线程执行GC操作，提高回收效率。Minor GC和Full GC均由多个线程并行处理，在多核CPU环境下，能显著缩短STW时间。ParallelGC以“吞吐量优先”为设计目标，可通过参数（如-XX:MaxGCPauseMillis）调整停顿时间和吞吐量的平衡。适合后台计算、大数据分析等对吞吐量要求高的场景，但在高并发Web应用中，仍可能因Full GC导致明显停顿。

三、突破分代局限：G1回收器的“区域化”革命

随着应用内存规模扩大（从GB级到数十GB），经典分代回收器的弊端逐渐凸显：Full GC对全堆的扫描和整理会导致分钟级的停顿，完全无法满足金融、电商等核心业务的高可用需求。为解决这一问题，JDK 7引入了G1（Garbage-First）回收器，并在JDK 9中成为默认回收器，它的核心创新是“区域化分代式”模型，打破了年轻代与老年代的物理界限。

3.1 G1的核心设计：以区域为单位的内存管理

G1将堆内存划分为多个大小相等的独立区域（Region），每个Region的大小可通过参数设置（1MB~32MB，通常为堆内存的1/2000）。每个Region都可以动态扮演Eden区、Survivor区或老年代区的角色，无需物理连续。这种设计的优势在于：

GC可精准选择“垃圾比例最高”的Region优先回收（即“Garbage-First”的由来），提高回收效率。
避免对全堆的扫描，将STW时间控制在可预测的范围内（通过-XX:MaxGCPauseMillis设置目标停顿时间）。

3.2 G1的核心流程：四个阶段实现低停顿

G1的回收过程分为四个核心阶段，其中仅初始标记和最终标记阶段会产生短暂STW，其余阶段可与用户线程并行执行：

初始标记（Initial Mark）：STW操作，标记出与GC Roots直接关联的对象，时间极短。
并发标记（Concurrent Mark）：与用户线程并行，从初始标记的对象出发，遍历整个对象引用链，标记所有存活对象。此阶段耗时最长，但不影响程序运行。
最终标记（Final Mark）：短暂STW，处理并发标记阶段因用户线程操作而产生的“漏标”对象，通过“SATB（Snapshot-At-The-Beginning）”机制保证标记准确性。
筛选回收（Live Data Counting and Evacuation）：STW操作，根据各Region的垃圾比例排序，优先回收垃圾多的Region，将存活对象复制到空Region中，同时完成内存整理。此阶段可通过设置目标停顿时间，动态调整回收的Region数量，从而控制STW时间。

3.3 G1的适用场景与局限

G1的设计目标是“低延迟、大内存”，适合堆内存规模在4GB以上的应用，尤其是金融交易、电商支付等对延迟敏感的场景。但G1也存在局限：当堆内存超过100GB时，并发标记阶段的耗时会显著增加，且筛选回收阶段的STW时间难以控制在毫秒级，这为新一代回收器的出现留下了空间。

四、现代GC的巅峰：ZGC的毫秒级停顿革命

为解决超大内存（TB级）场景下的低延迟问题，Oracle在JDK 11中正式引入ZGC（Z Garbage Collector），并在JDK 17中成为长期支持版的默认回收器之一。ZGC的核心目标是“无论堆内存多大，STW时间都控制在10毫秒以内”，它通过一系列突破性技术，实现了吞吐量与延迟的完美平衡。

4.1 ZGC的核心创新：着色指针与读屏障

ZGC打破了传统GC的“标记-复制-整理”逻辑，其核心技术是着色指针（Colored Pointers）和读屏障（Read Barrier），这两项技术依赖于64位操作系统的地址空间优势（仅使用低42位存储对象地址，高22位用于标记信息）。

着色指针：在对象指针中嵌入标记信息（如“已标记”“待移动”“已移动”），无需单独维护标记位图，实现了“指针即状态”。这种设计让ZGC在并发标记和并发移动对象时，无需暂停用户线程。
读屏障：在用户线程读取对象指针时插入一段极短的逻辑，用于处理指针的状态（如当指针指向“待移动”的对象时，触发对象移动并更新指针）。读屏障的开销极小（通常在纳秒级），几乎不影响程序吞吐量。

4.2 ZGC的内存模型与回收流程

ZGC的内存模型基于Region，与G1类似，但Region的划分更灵活，支持大页（Large Page）优化，减少TLB（Translation Lookaside Buffer）缓存失效。ZGC的Region分为小型区（Small Region，2MB，存小对象）、中型区（Medium Region，32MB，存中对象）和大型区（Large Region，2MB的整数倍，存大对象）。

ZGC的回收流程分为三个核心阶段，仅初始标记和最终标记有极短STW，其余阶段完全与用户线程并行：

初始标记（Initial Mark）：STW，标记GC Roots直接关联的对象，时间通常在1毫秒以内。
并发标记（Concurrent Mark）：与用户线程并行，通过着色指针遍历对象引用链，标记存活对象，耗时与堆内存大小相关，但不影响程序运行。
并发重定位（Concurrent Relocate）：与用户线程并行，选择垃圾比例高的Region，将存活对象移动到新Region，同时通过读屏障更新用户线程的指针引用。此阶段无需STW，彻底解决了大内存场景下的停顿问题。

4.3 ZGC的优势与适用场景

ZGC的核心优势体现在三个方面：超低延迟（STW时间稳定在10毫秒内）、超大内存支持（最高支持16TB堆内存）、高吞吐量（读屏障开销极小，吞吐量接近ParallelGC）。

适合场景包括：TB级内存的分布式系统、高并发Web服务、实时数据分析平台等对延迟和吞吐量均有高要求的场景。JDK 17后，ZGC的稳定性和性能进一步优化，成为现代Java应用的首选回收器。

五、GC实践：如何选择与优化回收器？

GC的选择没有“最优解”，只有“最适合”。结合业务场景和JDK版本，合理选择回收器并优化参数，才能发挥GC的最佳性能。以下是核心实践建议：

5.1 回收器选择指南

JDK版本	场景特征	推荐回收器	核心参数示例
JDK 8	堆内存<4GB，吞吐量优先（如后台计算）	ParallelGC（默认）	-XX:+UseParallelGC -XX:MaxGCPauseMillis=100
JDK 8/9	堆内存4GB~100GB，低延迟需求（如Web应用）	G1	-XX:+UseG1GC -XX:MaxGCPauseMillis=200
JDK 11+	堆内存>10GB，超低延迟（如金融交易）	ZGC	-XX:+UseZGC -Xmx100G -XX:MaxGCPauseMillis=10
所有版本	嵌入式设备、单CPU环境	SerialGC	-XX:+UseSerialGC

5.2 核心优化思路

避免Full GC：Full GC是性能杀手，核心优化方向包括：控制对象创建速度（避免大对象频繁创建）、调整年轻代与老年代比例（如G1中通过-XX:NewRatio设置）、优化对象晋升阈值（-XX:MaxTenuringThreshold），减少年轻代对象过早晋升。
合理设置堆内存：堆内存并非越大越好，过大的堆会增加GC扫描时间。应根据业务峰值内存使用情况，设置-Xmx（最大堆）和-Xms（初始堆），建议两者值相等，避免堆内存动态扩容的开销。
监控与调优结合：通过JVM工具（jstat、jmap、jvisualvm）监控GC状态，重点关注GC次数、STW时间、堆内存使用趋势。例如，若Minor GC频繁，可能是Eden区过小；若Full GC频繁，可能是老年代内存泄漏。
利用现代GC特性：ZGC支持的大页优化（-XX:+UseLargePages）、并发线程数调整（-XX:ZGCThreads）等，可根据硬件配置进一步优化性能。