BufferedWriter.flush() 仅将数据从Java缓冲区刷入操作系统内核缓冲区，不保证落盘；真正落盘需调用FileOutputStream.getFD().sync()或getChannel().force(true)，且close()不会自动执行sync。
BufferedWriter.flush() 不保证磁盘落盘
flush() 只是把 Java 缓冲区内容推到操作系统内核缓冲区（page cache），不触发 fsync() 系统调用，因此断电或进程崩溃时仍可能丢失数据。这是最常被误解的一点——很多人以为调用 flush() 就“安全了”，其实只是完成了用户态到内核态的移交。
实际场景中，比如写日志、生成关键配置文件、保存交易凭证，都需要真正落盘。这时必须配合底层 FileOutputStream 的 getChannel().force(true) 或直接调用 FileOutputStream.getFD().sync()。
如何在 BufferedWriter 后强制同步到磁盘
因为 BufferedWriter 是装饰器模式封装 Writer，它本身不暴露底层 FileDescriptor 或 FileChannel，所以必须从原始 FileOutputStream 入手。典型做法是：先用 FileOutputStream 构造 OutputStreamWriter，再套 BufferedWriter，保留对 FileOutputStream 的引用。
- 不要用
new FileWriter(...)—— 它隐藏了底层流，无法获取FileDescriptor - 显式创建
FileOutputStream，传给OutputStreamWriter，再包装成BufferedWriter - 写完后依次调用：
bufferedWriter.flush()→fileOutputStream.getFD().sync() -
sync()会阻塞直到数据真正写入磁盘（或对应存储设备报告完成），注意性能开销
示例：
FileOutputStream fos = new FileOutputStream("data.txt");
BufferedWriter bw = new BufferedWriter(new OutputStreamWriter(fos, StandardCharsets.UTF_8));
bw.write("important data");
bw.flush();
fos.getFD().sync(); // 这一步才真正落盘
Windows 和 Linux 下 sync 行为差异
FileDescriptor.sync() 在不同系统底层调用不同：Linux 调用 fsync()，Windows 调用 FlushFileBuffers()，语义基本一致。但要注意两点：
- 某些 SSD 或虚拟化环境（如 Docker volume、网络文件系统 NFS）可能忽略
sync()请求，返回成功但实际未落盘 - 如果文件是以
FileChannel.open(..., StandardOpenOption.SYNC)方式打开的，则每次write()都等效于带sync，此时不需要额外flush()+sync，但会严重拖慢写入速度 -
StandardOpenOption.DSYNC只同步数据不同步元数据（如修改时间），适合高频小写场景，但 Java 的FileDescriptor.sync()是全量同步
常见错误：close() 会自动 flush + sync 吗？
不会。BufferedWriter.close() 会调用 flush()，但仅限于刷新 Java 缓冲区；FileOutputStream.close() 在大多数 JDK 实现里**不会**调用 sync()，除非你显式使用 StandardOpenOption.SYNC 打开文件。
这意味着以下代码依然危险：
try (BufferedWriter bw = Files.newBufferedWriter(Paths.get("x.txt"))) {
bw.write("data");
} // close() 触发 flush()，但不保证落盘
如果你依赖 try-with-resources，就必须自己在 close() 前补上 sync()，或者改用带 SYNC 选项的 FileChannel。
真正需要落盘的场景，别省那几行代码——flush() 和 sync() 是两件事，漏掉后者，就等于没做。
