在JVM内存体系中，堆内存的“分代结构”与“对象流转规则”是通用基础，但垃圾回收器（GC）是决定堆内存实际表现的核心变量——不同GC为实现“低延迟”“高吞吐量”等目标，会对堆的划分方式、对象管理逻辑、参数配置规则进行定制化改造。

本文作为JVM内存结构系列的第四篇，将以“堆内存”为纽带，系统拆解经典分代GC、G1
GC、非分代GC与堆的适配差异，帮你理解“堆的理论模型”如何在实际GC中落地，避免在调优时混淆“通用堆参数”与“GC专属逻辑”，同时为后续实战篇（GC问题排查）铺垫核心认知。

一、核心认知：GC与堆的适配本质——“目标决定结构”

在分析具体GC前，需先明确一个核心逻辑：GC对堆的改造，本质是为了匹配自身的设计目标。不同GC的目标差异，直接导致了堆内存管理方式的分化：

追求“高吞吐量”的GC（如Parallel Scavenge）：会尽量简化堆管理逻辑，减少GC线程与用户线程的交互开销；
追求“低延迟”的GC（如CMS、ZGC）：会通过复杂的堆划分（如Region、Page）和并发回收机制，缩短用户线程暂停（STW）时间；
平衡“延迟与吞吐量”的GC（如G1）：会采用动态化的堆管理策略，在两者间找到最优解。

后续所有GC与堆的适配细节，都围绕这个逻辑展开。

二、经典分代GC：严格遵循堆分代模型，适配中小堆内存

经典分代GC是JVM早期的主流选择，其核心特点是完全遵循“年轻代+老年代”的物理分代模型，仅在“回收线程数”“老年代算法”上存在差异，适合堆内存≤4GB的场景（如单体应用、小型微服务）。

代表GC组合：SerialGC（Serial+Serial Old）、ParNew+CMS、Parallel Scavenge+Parallel Old。

2.1 与堆的适配共性：年轻代管理逻辑统一

所有经典分代GC的年轻代管理逻辑完全一致，均基于“复制算法”实现高效回收，具体适配细节如下：

堆划分规则：年轻代严格按“Eden:Survivor=8:1:1”划分（可通过-XX:SurvivorRatio调整），老年代占堆总大小的2/3，物理上与年轻代连续；
对象分配与晋升：
1. 新对象（非大对象）优先分配到Eden区，大对象（超过-XX:PretenureSizeThreshold）直接进入老年代；
2. Minor GC时，Eden区存活对象复制到To Survivor，From Survivor存活对象按“年龄计数器”判断：未达阈值（默认15，-XX:MaxTenuringThreshold）则复制到To Survivor，达标则晋升到老年代；
3. 支持“动态年龄判断”（-XX:TargetSurvivorRatio），Survivor区同年龄对象占比超阈值时，该年龄及以上对象提前晋升。
回收线程特性：差异仅体现在“回收线程数”——SerialGC用单线程回收年轻代，ParNew和Parallel Scavenge用多线程回收（ParNew线程数与CPU核心数绑定，Parallel Scavenge可通过-XX:ParallelGCThreads调整）。

2.2 与堆的适配差异：老年代算法决定堆特性

经典分代GC的核心差异集中在老年代回收算法上，而算法选择直接决定了老年代的“内存碎片情况”“大对象分配安全性”和“Full GC耗时”，最终影响堆的整体表现：

老年代GC组合	核心算法	堆内存特性（老年代）	适配场景	关键堆参数差异
Serial+Serial Old	标记-整理（Mark-Compact）	内存连续，无碎片；大对象分配安全；但Full GC单线程执行，耗时久（百毫秒~秒级）	堆内存小（≤2GB）、低并发场景（如本地测试、轻量工具）	无特殊参数，依赖`-Xms/-Xmx`控制堆大小
ParNew+CMS	CMS：标记-清除（Mark-Sweep） Serial Old：标记-整理（备用）	内存有碎片（标记-清除算法导致）；大对象可能因无连续空间触发Full GC；CMS并发回收，Full GC（CMS失败时触发）耗时久	堆内存中等（2GB~4GB）、低延迟优先场景（如Web服务）	`-XX:CMSFullGCsBeforeCompaction`：设置多少次CMS后执行整理（默认0，即每次CMS后整理，减少碎片）
Parallel Scavenge+Parallel Old	Parallel Old：标记-整理（Mark-Compact）	内存连续，无碎片；大对象分配安全；多线程回收老年代，Full GC耗时比Serial Old短	堆内存中等（2GB~4GB）、高吞吐量优先场景（如数据处理、批量任务）	`-XX:MaxGCPauseMillis`：动态调整年轻代大小（缩小年轻代减少Minor GC耗时）；`-XX:GCTimeRatio`：控制GC时间占比（默认99，即GC时间≤1%）

2.3 经典分代GC的堆适配局限

随着堆内存增大（超过4GB），经典分代GC的局限逐渐凸显：

物理分代导致的回收范围固定：Minor GC仅回收年轻代，Full GC回收全堆，堆越大Full GC耗时越长，无法灵活选择回收区域；
碎片问题（CMS）：标记-清除算法导致老年代碎片累积，需频繁执行整理操作（增加STW时间）；
参数依赖强：需手动调整年轻代比例、晋升阈值等参数，堆越大调优难度越高。

三、G1 GC：打破物理分代，堆内存的“Region化”改造

为解决经典分代GC在大堆内存（≥8GB）下的局限，G1 GC（Garbage-First GC）采用了Region化堆布局，通过“动态分代”和“优先回收垃圾多的区域”实现“低延迟+高吞吐量”的平衡，适合大型微服务、电商核心服务等场景。

3.1 堆布局革命：从“物理分代”到“Region动态角色”

G1 GC彻底打破了“年轻代与老年代物理连续”的传统结构，将堆内存划分为2048个大小相等的Region（每个Region大小1MB~32MB，通过-XX:G1HeapRegionSize设置，需为2的幂次方），每个Region动态扮演不同角色：

年轻代Region：包括Eden Region和Survivor Region，逻辑上属于年轻代，物理上分散在堆中；
老年代Region：存放从年轻代晋升的对象，物理上与年轻代Region混杂；
大对象Region（Humongous Region）：专门存储“大对象”（大小超过Region的50%），由连续多个Region组成，逻辑上属于老年代。

这种布局的核心优势：GC可灵活选择部分Region回收（而非全堆），大幅缩短STW时间。

3.2 与堆的适配细节：动态化的对象管理逻辑

G1 GC对堆的管理逻辑完全围绕“Region”展开，与经典分代GC差异显著：

3.2.1 年轻代管理：逻辑保留，物理动态

年轻代Region的动态调整：G1没有固定的年轻代大小（经典分代GC年轻代占堆1/3），而是根据“最大暂停时间目标”（-XX:MaxGCPauseMillis，默认200ms）动态调整年轻代Region数量——若Minor GC耗时超过目标，会减少年轻代Region；若年轻代过小导致晋升频繁，会增加年轻代Region。
Minor GC流程：仅回收所有年轻代Region（Eden+Survivor），存活对象复制到新的Survivor Region或直接晋升到老年代Region，回收后清空原年轻代Region（无碎片）。

3.2.2 老年代管理：优先回收“垃圾多的Region”

G1的“Garbage-First”得名于其回收策略：每次GC优先选择“垃圾占比高的Region”（老年代Region为主），具体逻辑：

Mixed GC（混合回收）：当老年代Region占比超过“阈值”（-XX:InitiatingHeapOccupancyPercent，默认45%），触发Mixed GC——同时回收所有年轻代Region和部分“垃圾占比高的老年代Region”，避免Full GC（G1尽量避免Full GC，Full GC时会退化为Serial Old算法，耗时极长）。
老年代Region的晋升规则：无固定“年龄阈值”（经典分代GC默认15），G1通过“Region的存活对象占比”判断——若Survivor Region的存活对象占比低，直接晋升为老年代Region；若占比高，则继续作为Survivor Region保留。

3.2.3 大对象处理：Humongous Region的特殊逻辑

分配规则：对象大小超过Region的50%时，直接分配到连续的Humongous Region，避免在普通Region中频繁复制；
回收时机：Humongous Region的回收与老年代Region同步（仅在Mixed GC或Full GC时回收），需注意：频繁创建大对象会导致Humongous Region堆积，快速触发Mixed GC，甚至Full GC（如频繁创建100MB对象，Region大小设为32MB，则每个大对象占用4个Humongous Region）。

3.3 G1 GC的核心堆参数（与经典分代GC的差异）

G1 GC的参数设计更聚焦“目标控制”（如暂停时间），而非“分代比例”，核心堆相关参数如下：

参数名	默认值	核心作用（与堆适配相关）	调优场景示例
`-XX:G1HeapRegionSize`	自动计算（堆≤4GB时1MB，堆≤8GB时2MB，以此类推）	设置单个Region大小，决定大对象阈值（Region大小的50%）	若应用频繁创建大对象（如50MB），可设为`-XX:G1HeapRegionSize=32M`（大对象阈值16MB，50MB对象需2个Region，减少Region数量）
`-XX:MaxGCPauseMillis`	200ms	控制GC最大暂停时间，G1会动态调整年轻代Region数量适配该目标	低延迟场景（如支付服务）设为`-XX:MaxGCPauseMillis=100`，减少单次GC耗时
`-XX:InitiatingHeapOccupancyPercent`	45%	触发Mixed GC的老年代Region占比阈值	若堆内存大（如32GB），可提高至`-XX:InitiatingHeapOccupancyPercent=60`，减少Mixed GC频率
`-XX:G1MixedGCCountTarget`	8	控制Mixed GC回收老年代Region的次数（默认8次内回收完符合条件的老年代Region）	若老年代Region堆积快，可降低至`-XX:G1MixedGCCountTarget=4`，加快老年代回收

四、非分代GC：彻底抛弃分代模型，堆内存的“统一管理”

对于超大堆内存（≥64GB，如大数据、AI服务），“分代模型”已无法满足“极致低延迟”（GC暂停≤10ms）的需求——非分代GC（ZGC、Shenandoah）彻底抛弃分代逻辑，采用“全堆统一管理+并发回收”，实现TB级堆内存的高效管理。

4.1 堆布局：无分代，仅按“内存单元”划分

非分代GC的堆布局极度简化，无“年轻代/老年代”概念，仅按固定大小的“内存单元”划分：

ZGC（Z Garbage Collector）：将堆分为Page（页面），Page大小分三类：小页面（2MB，存小对象）、中页面（32MB，存中对象）、大页面（≥2GB，存大对象），大页面无需连续，直接映射物理内存；
Shenandoah GC：与G1类似，将堆分为Region（默认1MB），无动态分代角色，所有Region地位平等，大对象直接存放在连续Region中。

这种布局的核心优势：GC可并发回收全堆（无需区分年轻代/老年代），STW时间仅与“对象引用遍历”相关，与堆大小无关（ZGC堆从8GB扩容到1TB，STW时间仍保持在10ms内）。

4.2 与堆的适配细节：并发回收与无碎片管理

非分代GC的堆管理逻辑围绕“并发”和“无碎片”设计，彻底解决了大堆内存下的延迟问题：

4.2.1 ZGC：基于“着色指针”的并发回收

核心技术：着色指针：ZGC通过“指针编码”（在64位指针中嵌入3位标记位）标记对象状态（如“可回收”“正在迁移”），无需暂停用户线程即可完成对象标记；
堆内存特性：
1. 无碎片：采用“标记-复制”算法，回收时将存活对象复制到新Page，原Page清空后复用，堆内存始终连续；
2. 大对象友好：大页面（≥2GB）直接映射物理内存，无需复制（仅标记回收），支持TB级大对象；
3. 无分代参数：无需配置“年轻代比例”“晋升阈值”，仅需通过-XX:ZHeapSize设置堆大小（初始=最大，避免扩容）。

4.2.2 Shenandoah GC：基于“读屏障”的并发整理

核心技术：读屏障：Shenandoah在用户线程读取对象引用时插入“屏障”，记录引用访问，实现并发标记和并发整理；
堆内存特性：
1. 无碎片：采用“标记-整理”算法（并发整理，无需复制对象），直接在原Region中移动对象，整理后内存连续；
2. 回收效率高：全堆并发回收，STW时间仅用于“初始标记”和“最终标记”（各约1ms）；
3. 堆参数简单：通过-XX:ShenandoahHeapRegionSize设置Region大小（默认1MB），-XX:ShenandoahGCHeuristics选择回收策略（如“低延迟优先”“吞吐量优先”）。

4.3 非分代GC的堆适配优势与局限

优势	局限
1. 堆大小无关性：STW时间不随堆增大而增加，支持TB级堆； 2. 无碎片：无需担心大对象分配失败； 3. 参数简单：无需手动调整分代参数，调优成本低； 4. 极致低延迟：GC暂停≤10ms，适合对延迟敏感的超大堆场景（如AI训练、实时数据分析）。	1. 线程开销高：着色指针（ZGC）和读屏障（Shenandoah）会增加用户线程开销（约5%~10%）； 2. JDK版本依赖：ZGC在JDK11正式发布，Shenandoah在JDK12正式发布，需升级JDK版本； 3. 工具支持：部分监控工具（如早期JVisualVM）对非分代GC的指标展示不完善。

五、实战选型：根据堆内存特性匹配GC

掌握GC与堆的适配关系后，核心目标是“根据堆内存大小、应用目标（延迟/吞吐量）选择合适的GC”，以下是实战选型指南：

堆内存规模	核心目标	推荐GC	堆适配关键注意事项
≤4GB	低并发、简单场景	SerialGC	无需复杂参数，堆大小设为`-Xms2G -Xmx2G`即可，避免频繁扩容
4GB~8GB	高吞吐量（如批量任务）	Parallel Scavenge+Parallel Old	依赖`-XX:MaxGCPauseMillis`动态调整年轻代，避免手动设置`-XX:MaxNewSize`
4GB~8GB	低延迟（如Web服务）	ParNew+CMS	需配置`-XX:CMSFullGCsBeforeCompaction=3`（3次CMS后整理碎片），避免大对象堆积
8GB~64GB	低延迟+高吞吐量（如电商核心服务）	G1 GC	1. 设`-XX:G1HeapRegionSize=16M`（堆32GB时）； 2. 控制`-XX:MaxGCPauseMillis=100`； 3. 避免频繁创建超过Region 50%的大对象
≥64GB	极致低延迟（如AI训练、实时数据）	ZGC/Shenandoah	1. ZGC设`-XX:ZHeapSize=64G`（初始=最大）； 2. Shenandoah设`-XX:ShenandoahGCHeuristics=latency`（低延迟优先）； 3. 确保JDK版本≥11（ZGC）/12（Shenandoah）