linux文件写操作默认是异步行为：write()立即返回，数据仅入页缓存；确保落盘须显式调用fsync（数据+元数据）或fdatasync（仅数据），二者均阻塞至物理写完成，而sync则全局非阻塞触发脏页回写。
Linux 文件写操作默认是同步语义但异步行为——write() 立即返回，不等数据落盘。真正决定“是否同步到磁盘”的，不是 write 调用本身，而是后续是否显式调用 fsync()、fdatasync() 或依赖内核脏页回写机制。所谓“异步写”在 Linux 文件系统中并非更快的写入方式，而是一种绕过页缓存、直写设备的特殊路径，它反而常带来性能下降。
同步写：靠缓存 + 延迟刷盘，兼顾速度与可靠性
绝大多数应用走的是这条路径：
- 调用
write()→ 数据拷贝进内核页缓存（page cache），标记为脏页，函数立即返回； - 内核后台线程（如
pdflush或writeback）按策略（时间/内存压力/脏页比例）将脏页写入磁盘； - 若需确保数据已落盘（如数据库事务提交），必须显式调用
fsync()或fdatasync()，此时进程会阻塞直到物理写完成。
这是最常用也最平衡的方式：用户获得低延迟响应，内核负责合并、排序、批量刷盘，提升吞吐。但断电或崩溃时，未刷盘的脏页数据会丢失。
异步写（native AIO）：不走缓存，直通设备，但代价高
Linux 内核级异步 I/O（如 io_submit() + O_DIRECT）要求：
- 用户缓冲区地址对齐（通常 512B 或 4KB）；
- 文件打开时指定
O_DIRECT，绕过页缓存； - 写请求由内核直接提交给块设备层，不经过缓存合并。
这意味着每次写都触发真实 I/O，无法利用缓存带来的批处理和延迟写优势。10 万次小写，在同步路径下可能只产生几千次实际磁盘操作；在异步直写路径下，就是 10 万次 DMA 请求 —— 吞吐下降、CPU 和 I/O 负载飙升。这也是为什么 Nginx 等高性能服务仅在读场景谨慎启用 AIO，基本不用它做写。
何时该强制同步？关键看数据持久性要求
不是所有写都需要立刻落盘，但以下场景必须干预：
-
日志类写入：如 syslog、数据库 WAL，每条记录都代表状态变更，必须
fsync()后才可认为提交成功； -
元数据敏感操作：创建文件后立即
fsync()目录，防止目录项丢失；重命名前确保源文件已刷盘； -
配置文件更新：写完新配置后
fdatasync()，避免重启时加载旧内容； -
临时文件安全删除：先
fsync()再unlink()，防止 unlink 后数据仍残留于缓存中被误恢复。
实用建议：别迷信“异步 = 更快”，优先用好 page cache
除非你明确需要规避缓存（例如用户自己管理缓存一致性，或对接裸设备），否则：
- 保持默认
write()+fsync()组合，是最稳妥通用的选择； - 避免滥用
O_DIRECT，它不会加速普通文件写，反而增加复杂性和开销； - 可通过
/proc/sys/vm/dirty_*参数调优脏页回写行为（如缩短延迟、提高触发阈值），比改写模型更有效； - 现代替代方案如
io_uring提供了更高效的异步接口，但仍建议优先用于高并发读或大块写，而非高频小写。
文件写操作的权衡核心不在“同步 vs 异步”的标签，而在何时让数据真正离开内核缓存、落到持久介质上。理解 page cache 的角色，比纠结 AIO 接口更重要。
