G1与ZGC为何弃用连续内存？Region机制解析

G1与ZGC放弃连续内存而采用Region分段管理，并非技术炫技，而是直面大内存、多核、低延迟场景下传统GC的根本困境：它通过将堆划分为可独立处理的Region，实现了停顿时间与堆大小解耦、NUMA架构下的内存本地化访问、细粒度并发回收的安全保障，以及对真实业务中对象生命周期高度异构性的动态适配——让垃圾回收从“不可控的大手术”转变为“精准可控的微创操作”，为现代云原生与高实时性系统提供了坚实的内存管理底座。

放弃连续物理内存、改用 Region（分段）管理堆，不是为了“炫技”，而是为了解决传统分代堆在大内存、多核、低延迟场景下暴露的根本矛盾。

应对大堆带来的停顿不可控问题

传统CMS或Parallel GC依赖整块连续的老年代空间，当堆扩大到几十GB甚至上百GB时，一次Full GC的标记、清理、整理耗时呈非线性增长。G1和ZGC把堆切成多个Region，让GC操作变成“小批量、可预测、可调度”的任务。G1按垃圾密度优先回收（Garbage-First），ZGC则并发扫描和转移单个Region——停顿时间不再随堆大小放大，而是取决于单个Region的处理开销。

适配现代硬件的NUMA架构与内存带宽瓶颈

服务器普遍采用NUMA设计，CPU访问本地内存比跨节点快2–3倍。连续大堆迫使GC线程频繁跨节点访问内存，加剧总线争抢与延迟抖动。Region机制天然支持本地化分配与回收：G1可按NUMA节点组织Region集合；ZGC自JDK 15起明确实现NUMA-aware分配，优先在当前CPU绑定的内存节点上分配和回收Region，减少远程访问开销。

支撑并发与增量式回收的工程前提

STW（Stop-The-World）越短，系统响应越平滑。但并发回收要求GC能安全地“边运行边干活”——这需要精确跟踪跨Region引用、隔离回收动作、避免对象状态错乱。Region配合RSet（Remember Set）、Card Table（G1）或彩色指针+读屏障（ZGC），实现了细粒度的引用关系快照与原子状态切换。没有Region的边界切分，就无法做到“只暂停根扫描几毫秒，其余全部并发”。

灵活应对对象生命周期异构性

真实业务中，对象存活时间差异极大：微服务请求对象活几毫秒，缓存对象活几小时，配置元数据可能永生。固定比例的Eden/Survivor/Old物理划分僵化低效。Region允许动态角色分配：一个Region此刻是Eden，下次回收后变成Survivor或Old；ZGC分代模式（JDK 21+）更进一步，按对象年龄自动聚类为Small/Medium/Large Region，小对象高频分配回收，大对象直入Large Region避免复制——资源调度完全由行为驱动，而非预设结构。

文中关于的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《G1与ZGC为何弃用连续内存？Region机制解析》文章吧，也可关注golang学习网公众号了解相关技术文章。