直接write(std::vector.data(), size)拖慢磁盘写入，因data()返回地址通常仅8/16字节对齐，不满足o_direct要求的4096字节页对齐，导致内核fallback至缓存io并触发bounce buffer拷贝。
为什么直接 write(std::vector.data(), size) 会拖慢磁盘写入
因为 std::vector::data() 返回的内存地址几乎肯定不是页对齐的（通常为 8/16 字节对齐），而现代 SSD 和内核 IO 路径（尤其是 O_DIRECT）要求用户缓冲区地址和长度都按 4096 字节（或更大，如 64K）对齐。不满足时，write() 会自动 fallback 到缓存 IO，绕过 page cache 的零拷贝优势，还可能触发内核内部的 bounce buffer 拷贝 —— 这就是性能断崖的根源。
用 posix_memalign + O_DIRECT 手动分配对齐缓冲区
核心是绕过 std::vector 的默认堆分配，改用系统级对齐分配，并配合无缓存直写模式。注意：这要求你完全掌控生命周期，不能依赖 vector 自动析构。
-
posix_memalign()分配 4096 字节对齐内存，大小向上取整到页边界（size_t aligned_size = ((size + 4095) / 4096) * 4096;） - 打开文件时必须加
O_DIRECT标志（Linux），且 fd 需用open(..., O_WRONLY | O_DIRECT)；macOS 不支持 O_DIRECT，需换用fcntl(fd, F_NOCACHE, 1)+mmap替代 -
write()前确保 offset 也页对齐（例如从文件起始写就天然满足；若追加，offset 必须是 4096 的倍数） - 写完后用
free()释放posix_memalign分配的内存，别用delete[]
void* buf;
size_t aligned_size = ((vec.size() * sizeof(T)) + 4095) & ~4095;
if (posix_memalign(&buf, 4096, aligned_size)) {
throw std::runtime_error("posix_memalign failed");
}
memcpy(buf, vec.data(), vec.size() * sizeof(T));
ssize_t ret = write(fd, buf, aligned_size);
free(buf); // 注意不是 delete[]
std::vector 本身能否页对齐？可以但不推荐
理论上能通过自定义 allocator 实现（如继承 std::allocator 并重载 allocate() 为调用 posix_memalign），但实际踩坑极多：
- 所有使用该 vector 的代码（包括 STL 算法、push_back、resize）都必须兼容对齐约束，稍有不慎就触发未定义行为
- vector 内部可能做多次小规模 realloc，每次都要对齐，碎片和开销反而上升
- 移动语义、异常安全、与第三方库交互（如 Eigen、Boost）容易出问题
- 真正需要极致 IO 的场景，数据往往已知尺寸且只写一次 —— 直接预分配对齐 buffer 更可控
别忘了 fsync 和 writev 的协同优化
单次大块写入虽快，但若需持久化保证，fsync() 是瓶颈。更优做法是：
- 用
writev()批量提交多个对齐 buffer（避免多次 syscall），每个iovec成员的iov_base必须页对齐、iov_len是页整数倍 - 写完后调用
fsync()，但可考虑用fcntl(fd, F_SETFL, O_DSYNC)让每次write同步元数据（权衡 durability 与吞吐） - 若写入超大文件（>1GB），分批次
writev+fsync，避免内核 dirty page 回收压力突增
对齐不是万能银弹 —— 如果数据本身小于一页，强行补零对齐反而浪费带宽；如果磁盘是机械盘，O_DIRECT 可能比缓存 IO 更慢。实测永远比理论重要。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
