为何Rust的std::io::write_all()在libsystem_kernel.dylib`close上耗时过长？

代码实现 #

fn write_append(&self, path: PathBuf, data: &[u8]) -> Result<(), ShError> {
    let file = OpenOptions::new().write(true).append(true).create(true).open(path)?;

    let mut new_line = data.to_vec();
    new_line.push(10);// \n character

    let mut writer = BufWriter::new(file);

    match writer.write_all(&new_line) {
        Ok(_) => Ok(()),
        Err(_) => Err(ShError::new(ShErrorKind::Internal, "Error writing entity file")),
    }
}

核心疑问 #

使用cargo flamegraph分析时，发现libsystem_kernel.dylib close的CPU耗时远超文件打开与写入操作，疑惑原因及是否解读错误（设备为MacBook Pro M1）。

为什么close耗时高？ #

你没有解读错火焰图，这种情况在macOS（尤其是M1系列）上很常见，核心原因如下：

• 缓冲区刷新与磁盘同步：BufWriter在被销毁时会自动调用flush，而文件句柄销毁时的close操作会强制将页缓存中未持久化的数据同步到磁盘。由于你每次调用write_append仅写入少量数据，BufWriter的缓冲区大概率没被填满，flush会触发小批量磁盘写入；同时close还要同步更新文件元数据（大小、修改时间等），这部分操作在APFS文件系统上的开销会比单次打开/写入更显著。
• APFS文件系统特性：APFS为保证数据一致性，在文件关闭时会执行额外的元数据日志、inode更新操作。即使M1搭载NVMe存储，这类同步操作的开销依然会被频繁调用放大。
• 频繁打开关闭的累积：如果write_append被高频调用（比如每秒数十次以上），每次都重复打开-写入-关闭的流程，close的同步开销会被持续累积，最终在火焰图中占比远超单次打开或写入操作。

优化方向 #

• 复用文件句柄：如果是向同一文件频繁追加数据，不要每次调用都重新打开文件，而是保持句柄持久化，多次写入后再统一关闭，这能彻底消除频繁close的开销。
• 调整缓冲区大小：手动指定BufWriter的缓冲区容量（比如BufWriter::with_capacity(4096, file)），减少触发flush的次数，降低close时的同步压力。
• 异步IO（按需使用）：如果业务场景允许，改用异步文件操作（如Tokio生态），将同步close的开销分散到后台，但对小批量写入的收益有限。
• 谨慎关闭同步保证：若可接受一定的数据丢失风险，打开文件时可以去掉强制同步相关的默认行为，但此操作会降低数据安全性，仅适合非核心数据场景。

内容的提问来源于stack exchange，提问作者rems