BufferedWriter 本身非线程安全，需用 ReentrantLock 控制 write 和 flush 的临界区，避免缓冲区错乱；构造和 close 不应加锁，flush 应按批次而非每行触发，高并发下可采用队列或异步日志框架替代。
BufferedWriter 本身不是线程安全的，多线程直接共用同一个实例会导致缓冲区错乱、内容覆盖或丢失。要保证写缓冲区完整性，关键不是“让 BufferedWriter 变成线程安全”，而是**控制对它的访问顺序和临界区边界**——ReentrantLock 正是用来干这件事的。
明确锁保护的范围：只锁 write + flush，不锁构造或 close
BufferedWriter 的 write()、newLine()、flush() 等操作会修改内部 char[] 缓冲区和计数器，这些必须被原子化。但构造 BufferedWriter（含底层 FileWriter）和最终 close() 通常只需执行一次，不应放在锁内反复竞争。
- ✅ 正确做法：每次调用 write 相关方法前加 lock，操作完立即 unlock（推荐 try-finally 或 try-with-resources 配合手动 unlock）
- ❌ 错误做法：把 new BufferedWriter(...) 放在锁块里 —— 每次都新建流，失去缓冲意义，还引发文件句柄泄漏
- ⚠️ 注意：close() 一般由单一线程负责（如程序退出时），若需多线程可协调后统一关闭，避免重复 close 导致 IOException
避免 flush 频繁导致性能下降
BufferedWriter 的价值在于批量写入。如果每写一行就 flush 一次，等于退化为无缓冲；但如果完全不 flush，又可能因异常或程序终止导致缓冲区内容丢失。
- 建议采用“按批次 flush”策略：例如累计写入 1000 行或达到 64KB 后主动 flush，而不是每行都 flush
- 可在 lock 保护下维护一个计数器或字节数统计，在满足条件时触发 flush()
- 若业务要求强实时落盘（如日志），可用 PrintWriter(..., true) 自动 flush，但注意它仍非线程安全，仍需 ReentrantLock 包裹 write 调用
典型安全写法示例
以下是一个轻量但可靠的模式：
立即学习“Java免费学习笔记（深入）”；
private final BufferedWriter writer;
private final ReentrantLock lock = new ReentrantLock();
public FileWriterService(String filePath) throws IOException {
this.writer = new BufferedWriter(new FileWriter(filePath, true)); // 追加模式
}
public void appendLine(String line) {
lock.lock();
try {
writer.write(line);
writer.newLine();
// 可选：每 N 条 flush 一次，或根据业务节奏控制
if (shouldFlush()) {
writer.flush();
}
} catch (IOException e) {
throw new RuntimeException("Write failed", e);
} finally {
lock.unlock();
}
}
这个结构确保：同一时刻只有一个线程能往缓冲区写数据、换行、判断是否刷新，缓冲区状态不会被并发篡改。
进阶考虑：读写分离或无锁替代
当写入压力极大（如每秒万级日志），单纯靠 ReentrantLock 串行化可能成为瓶颈。此时可考虑：
- 用 BlockingQueue + 单消费者线程：所有写请求入队，由一个专用 I/O 线程顺序消费并刷盘 —— 把并发控制交给队列，BufferedWriter 完全脱离多线程环境
- 切换到 Log4j2 / SLF4J 异步 Appender：底层基于 Disruptor 无锁队列，自动处理缓冲、批写、落盘，比手写更健壮高效
- 若必须自研高性能写入，可配合 FileChannel + ByteBuffer + MappedByteBuffer，但复杂度显著上升，一般场景不推荐
