ZGC通过并发增量压缩与多视图映射实现低碎片内存管理，将堆划分为小/中/大Region，仅需极短STW即可并发转移存活对象，空闲空间可预测调度而不阻碍分配。

ZGC 的内存压缩机制和空闲空间管理，不是靠“填满”或“消灭所有空闲”来实现的，而是通过并发、增量、视图切换的方式，让堆内存始终处于高可用、低碎片、可快速分配的状态。它不追求零空闲，而是让空闲空间可预测、可调度、不阻碍并发分配。

内存压缩：增量式整理，不暂停应用

ZGC 的压缩不是一次性搬完所有存活对象，而是把整个堆划分为多个大小统一的区域（Region），每次只选部分区域做并发转移（Relocation）。关键点在于： - 压缩过程与应用线程并行执行，仅需极短的初始转移停顿（STW），通常 例如：一个 256GB 堆中，ZGC 可能在某次 GC 周期只迁移 5% 的区域（约 12GB），耗时分散在毫秒级子任务中，应用全程响应不受影响。

空闲空间管理：按需预留，不预占、不合并

ZGC 不维护传统意义的“空闲链表”或“伙伴系统”，它的空闲空间由以下机制协同保障： - 区域化分配：每个 Region 固定大小（如 2MB/4MB/32MB，取决于堆总大小），分配时直接取整块，避免内部碎片； - 视图隔离空闲：Marked0/Marked1/Remapped 三个虚拟视图中，只有当前活跃视图（如 Remapped）用于新对象分配；其他视图中的“空闲”其实是待回收或已回收的物理页，操作系统可随时复用； - 延迟归还物理内存：ZGC 默认不主动将未用物理内存交还给 OS（除非启用 -XX:+ZUncommit），但会标记为“可回收”，后续 GC 可直接复用，避免频繁 mmap/munmap 开销。

这意味着：ZGC 堆里总有“空闲”虚拟地址，但这些地址背后可能尚未分配物理页（按需提交），也可能刚被回收、等待下次分配——它管理的是“可用性”，而非“绝对占用率”。

为什么不需要“零空闲”？

- 强制填满会破坏并发性：为凑出大块连续空间而阻塞分配，违背低延迟目标； - 空闲空间是压缩与转移的缓冲区：保留适量空闲区域，能让 ZGC 快速选择目标进行对象迁移，避免卡在找空间环节； - 操作系统级内存管理更高效：ZGC 依赖 Linux 的 mmap 和 page fault 机制，让“虚拟空闲”和“物理闲置”解耦，实际内存使用率由工作负载决定，而非 GC 算法强行拉高。

简言之，ZGC 把“压缩”变成后台流水线，“空闲”变成弹性资源池——不拼利用率，而保响应确定性。