zgc不管理物理内存或交换空间，仅作用于jvm堆内虚拟地址空间；其堆内存由操作系统mmap映射，物理页分配依赖访问触发的缺页中断；swap会间接导致gc延迟和应用停顿，破坏zgc亚毫秒级暂停目标。
ZGC本身不直接管理物理内存或交换空间，它的作用范围严格限定在JVM堆内——即由操作系统分配给Java进程的一段虚拟地址空间。ZGC的运行依赖于底层操作系统的内存管理机制，但不会主动触发页面换入换出，也不感知swap是否启用。
ZGC如何使用物理内存
ZGC申请的堆内存（如-Xmx12t）在启动时由操作系统通过mmap映射为虚拟内存区域。这些虚拟页是否真正绑定到物理内存（RAM），取决于实际访问行为：
- 首次写入对象时触发缺页中断，内核为其分配物理页框；
- 若此时物理内存紧张，内核可能回收其他进程的页（如文件缓存）或触发swap——但这与ZGC无关，是Linux内存子系统统一决策；
- ZGC并发转移阶段会分配新页面，同样走标准页分配路径，受
/proc/sys/vm/swappiness、zone_reclaim_mode等内核参数影响。
交换空间对ZGC的影响是间接且负面的
当系统整体内存压力大，ZGC正在运行的JVM进程也可能被换出部分页。这会导致：
- GC过程中访问已换出的旧对象页，引发磁盘I/O等待，显著拖慢并发标记或转移速度；
- 应用线程读取被swap出去的堆数据时发生major page fault，造成毫秒级甚至百毫秒级停顿，破坏ZGC亚毫秒级暂停承诺；
- 频繁swap会加剧IO负载，间接抬高整个系统的延迟基线，使ZGC的“
关键配置建议
为保障ZGC低延迟特性，应从系统层规避swap干扰：
- 生产环境建议关闭swap：
sudo swapoff -a，并注释/etc/fstab中swap行； - 若必须保留swap（如防止OOM kill），将
swappiness设为1（而非默认60）：echo 1 | sudo tee /proc/sys/vm/swappiness； - 确保JVM堆大小不超过可用物理内存的70%～80%，预留空间给元空间、直接内存、内核缓存等；
- 启用
Transparent Huge Pages (THP)可减少TLB miss，提升大堆访问效率，但需禁用always模式，改用madvise由JVM显式提示。
ZGC的设计哲学是“信任硬件”，它假设堆内存驻留在快速RAM中。一旦落到磁盘交换，就脱离了其性能模型的边界。所以与其研究ZGC如何与swap交互，不如确保swap不被ZGC进程触及。
