mmap + aligned_alloc 是最直接的页对齐写入路径，因其使内存布局严格对齐4KB页边界，避免内核额外拷贝与缺页中断，但需注意 aligned_alloc 在部分环境（如启用tcmalloc）可能失效，推荐 posix_memalign 替代。
为什么 mmap + aligned_alloc 是最直接的页对齐写入路径
因为操作系统对磁盘 I/O 的最小调度单位是页（通常是 4KB），非对齐缓冲区会导致内核额外分配临时页、触发 copy-on-write 或降级为慢速 buffered write。用 mmap 配合 aligned_alloc 能让数据内存布局与页边界严格对齐，绕过 stdlib 的 malloc 碎片化问题，且后续 write() 或 msync() 可直通 page cache。
实操要点：
-
aligned_alloc(4096, vec.size() * sizeof(T))分配内存，注意 size 必须是页大小整数倍——若vec.size() * sizeof(T)不整除 4096，需向上取整：((n + 4095) & ~4095) - 拷贝前用
memcpy把vec.data()写入对齐内存，别用std::copy（可能触发未对齐访问优化） - 分配后建议调用
memset(ptr, 0, size)预触内存页，避免首次write时缺页中断阻塞
用 posix_memalign 替代 aligned_alloc 避免 C++17 依赖和 malloc_hook 冲突
某些嵌入式或旧版 libc（如 musl）不支持 aligned_alloc；更关键的是，若项目启用了 jemalloc/tcmalloc，aligned_alloc 可能被 hook 掉并返回非页对齐地址——而 posix_memalign 是 POSIX 标准接口，绕过 malloc 实现，结果可预期。
典型错误现象：aligned_alloc(4096, N) 返回地址 % 4096 != 0，但 posix_memalign(&ptr, 4096, N) 保证满足。
使用场景：
- 交叉编译到 ARM/aarch64 设备时，优先选
posix_memalign - 链接了 tcmalloc 且观察到
write延迟毛刺，换用posix_memalign后毛刺消失 - 分配后务必检查返回值：
if (ret != 0) { /* ENOMEM or EINVAL */ }
fdopen + setvbuf 设置 _IOFBF 缓冲区对齐失败的真相
有人试图用 fdopen(fd, "w") + setvbuf(fp, aligned_buf, _IOFBF, size) 让 FILE* 使用自定义对齐缓冲区，但实际无效：glibc 在 flush 时仍会把数据 memcpy 到内部临时 buffer，该 buffer 由 malloc 分配，无法保证页对齐。
性能影响明显：实测在 NVMe 上，同样 128MB 数据，对齐 write() 耗时 83ms，而 fwrite() 即使传入对齐 buffer 也耗时 142ms。
所以：
- 彻底放弃
FILE*接口做高性能页对齐写入 - 必须用裸
write(int fd, const void *buf, size_t count)，且buf地址和count均需满足页对齐约束 - 若必须用流式接口，改用
io_uring的IORING_OP_WRITE，它允许直接提交用户对齐 buffer
std::vector::data() 永远不能直接用于页对齐写入
这是最容易踩的坑。std::vector 的内存由其 allocator 分配，默认是 std::allocator，底层调用 malloc——而 malloc 只保证 8/16 字节对齐，不保证 4096 字节。即使 vector 容量很大，vec.data() 地址 % 4096 几乎总是非零。
验证方法很简单：
std::vector<int> v(1000000); std::cout <p>正确做法只有两个：</p> <ul> <li>分配新对齐内存 → <code>memcpy</code> 复制 → <code>write()</code> </li> <li>用 <code>std::pmr::polymorphic_allocator</code> 配合自定义对齐 memory resource（但复杂度高，适合长期维护项目）</li> </ul> <p>页对齐不是“开了个开关就生效”的功能，它是从内存分配、数据搬运、系统调用三者咬合的链条；漏掉任一环，前面所有优化都归零。</p></int>
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
