zgc 的三地址映射是 jvm 在虚拟地址空间内通过页表控制实现的逻辑多视图机制，不直接调用 mmap 或 ftruncate；它仅用 mmap(map_anonymous) 申请虚拟空间，依赖内核虚拟内存基础设施，与文件映射无关。
ZGC 本身不直接调用 Linux 的 mmap 或 ftruncate，也不依赖它们完成“三地址映射”。所谓 ZGC 的 三视图映射（Marked0 / Marked1 / Remapped） 是 JVM 自身在虚拟地址空间内构造的逻辑多视图机制，底层依托的是操作系统提供的 虚拟内存管理能力（如页表、TLB、MMU），而非显式调用 mmap 或文件操作。
它和 mmap、ftruncate 没有协作关系，二者属于不同抽象层级：
-
mmap+ftruncate是用户态程序对普通文件做内存映射的标准 POSIX 流程（用于高效 IO 或进程间共享内存）； - ZGC 的三视图是 JVM 在启动时向操作系统申请大块虚拟地址空间（如
[0,4TB)、[4TB,8TB)等），然后通过修改页表项（PTE）和地址翻译逻辑，让同一物理内存页在不同时间被不同虚拟地址范围访问 —— 这个过程由 JVM 内部的内存管理器控制，不涉及文件映射，也不需要ftruncate。
具体来说：
- ZGC 启动时会通过
mmap(MAP_ANONYMOUS | MAP_NORESERVE)向内核申请连续的虚拟地址段（如 4TB 范围），但不分配物理内存，也不关联任何文件； - 它利用 Linux 的
mmap的MAP_ANONYMOUS标志申请纯虚拟空间，后续按需通过缺页中断分配物理页； -
ftruncate完全不参与：ZGC 不操作文件，不映射文件，不扩展/截断任何文件大小； - “三地址映射”本质是：JVM 控制页表，将同一组物理页帧，分别映射到三个不同虚拟地址区间（如 Marked0 视图用
[4TB,8TB)访问，Remapped 视图用[16TB,20TB)访问），并通过原子更新页表项实现视图切换； - 所有这些映射变更都发生在用户态页表管理与内核 MMU 协同下，无需
msync、munmap或文件 I/O 类接口。
所以常见误解需要厘清：
- ❌ ZGC 不用
mmap(fd, ...)映射文件 - ❌ ZGC 不调用
ftruncate（没有 fd，不操作文件） - ❌ ZGC 的三视图不是靠多次
mmap实现的，而是靠单次大块虚拟空间预留 + 动态页表重映射 - ✅ 它确实依赖 Linux 提供的虚拟内存基础设施（如
mmap(MAP_ANONYMOUS)分配虚拟地址、页错误处理、TLB 刷新等），但这是隐式基础能力，不是主动“配合”mmap/ftruncate流程。
简言之：ZGC 的三地址映射是 JVM 层的地址空间编排策略，Linux 内核只提供虚拟内存框架支持；而 mmap+ftruncate 是应用层文件映射套路，两者目标不同、路径独立、无调用链路。
