G1通过Region机制规避外部碎片：每个Region为独立分配单元，无需物理连续空间；回收以Region为粒度采用复制算法，仅Humongous对象需连续空间，碎片风险被限制在可控范围内。
G1 通过 Region 划分机制，从设计根源上绕开了传统分代 GC 对“连续内存空间”的强依赖，从而规避了因空间不连续导致的分配失败和外部碎片问题。
Region 是独立分配单元，不依赖物理连续性
传统 CMS 或 Serial GC 要求 Eden、老年代等区域在堆中是物理连续的一整块内存；一旦长期运行后空闲空间被切割成小块（如 [Live][Free][Live][Free]），即使总空闲量足够，也无法分配一个中等大小的对象——这就是典型的外部碎片。
G1 不同：每个 Region（1–32MB）是独立的分配单位。只要堆里有足够数量的空闲 Region（哪怕彼此离散），JVM 就能从中挑出一个来分配新对象。分配逻辑只看“有没有可用 Region”，而不是“有没有连续 N MB 空间”。
- 新对象优先尝试放入 Eden 类型的 Region；若 Eden 不足，G1 会从空闲 Region 列表中取一个，动态标记为 Eden
- 大对象（＞Region size 的 50%）才需要连续多个 Region（Humongous），这是特例，不是常态分配路径
- 普通对象无论大小，都只占单个 Region 内部空间，Region 内部使用指针碰撞或空闲链表管理，与跨 Region 连续性无关
回收以 Region 为粒度，天然支持非连续整理
G1 的 Young GC 和 Mixed GC 都采用复制算法：把存活对象从一组源 Region 搬到另一组目标 Region。这个过程本身就在“重排”内存布局——搬完后，源 Region 整块清空，可直接复用；目标 Region 被紧凑填充，内部无碎片。
关键点在于：目标 Region 不必紧邻源 Region，也不必在某个固定代里。G1 只需确保目标 Region 有足够连续空间容纳要复制的对象（即 Region 内部连续），而不要求多个 Region 在地址空间上连续。
- 例如：把 3 个 Eden Region 中的存活对象，分别复制到 2 个空闲 Region + 1 个 Survivor Region 中，完全合法
- 每次回收后，空闲 Region 是整块释放的，不会留下“半空 Region”卡在中间
- Remembered Set（RSet）维护跨 Region 引用，让这种松散布局仍能准确追踪对象关系
碎片风险只集中在 Humongous 区域，且可监控可调优
真正可能暴露“连续空间不足”的场景，仅限于 Humongous 对象分配：当对象超过单 Region 一半大小时，G1 会尝试分配连续的若干 Region；若此时堆中空闲 Region 虽多，但无法拼出连续段，就会触发 to-space exhausted 日志，甚至 Full GC。
但这属于可控边界，不是普遍碎片：
- 可通过 -Xlog:gc+heap=debug 观察 Humongous 分配行为
- 调大 -XX:G1HeapRegionSize（如设为 4M 或 8M），减少中等大对象落入 Humongous 类别
- 用 jcmd
VM.native_memory summary 或 GC.class_stats 查看大对象分布，针对性优化业务代码 - 设置 -XX:G1ReservePercent 预留一部分 Region 专供大对象，避免临界时无缓冲
所以 G1 并非“完全消灭碎片”，而是把碎片问题从整个堆降维到 Humongous 子集，并通过 Region 粒度的分配与回收机制，让绝大多数对象分配彻底摆脱对连续地址空间的依赖。
