BufferedOutputStream通过内存缓冲区（默认8KB）合并多次小写操作，减少系统调用次数，使日志吞吐提升5–10倍；但需手动flush确保关键日志不丢失，且应根据日志量调整缓冲区大小。
BufferedOutputStream 为什么能提升日志写入吞吐
直接调用 FileOutputStream.write() 写小块数据（比如每条日志几十字节）时，每次都会触发一次系统调用，陷入内核，开销极大。而 BufferedOutputStream 在用户态维护一个内存缓冲区（默认 8192 字节），只有缓冲区满、调用 flush() 或 close() 时才真正落盘。这大幅减少了系统调用次数，尤其在高频小写场景下，吞吐可提升 5–10 倍。
但要注意：它不改变最终磁盘 I/O 总量，只是合并写请求；且缓冲会引入延迟——未 flush 的日志在进程崩溃时会丢失。
如何正确包装 FileOutputStream 并控制 flush 时机
别用默认缓冲区大小处理日志。大批量日志通常单条较短（
- 使用
new BufferedOutputStream(new FileOutputStream(file, true), 65536)开启追加模式 + 大缓冲 - 每写入 1000 条日志后调用一次
bufferedOut.flush()，平衡延迟与吞吐 - 避免在循环内对每条日志都
flush()——这完全抵消了缓冲价值 - 务必在 finally 块或 try-with-resources 中调用
close()，否则最后一批缓冲数据可能丢失
和 PrintStream / PrintWriter 混用时的陷阱
很多日志代码习惯用 PrintStream.println() 包裹 BufferedOutputStream，但 PrintStream 自带缓冲（默认启用 auto-flush 仅对 println() 生效），容易造成双重缓冲或意外 flush：
- 如果用
new PrintStream(new BufferedOutputStream(fos))，且未禁用 auto-flush，则每次println()都会触发BufferedOutputStream.flush()，缓冲失效 - 更稳妥做法是：直接用
BufferedOutputStream+String.getBytes(StandardCharsets.UTF_8)写入，自己控制换行和编码 - 若必须用
PrintWriter，构造时传false关闭 auto-flush：new PrintWriter(bufferedOut, false)
缓冲区大小与 GC 压力的权衡
设太大（如 1MB）虽减少 flush 次数，但会占用堆内存，且单次 write 调用耗时变长，可能阻塞日志线程；设太小（如 1KB）则频繁 flush，失去缓冲意义。实测在日均 GB 级日志场景下：
- 64KB–256KB 是较优区间，兼顾吞吐、延迟和内存占用
- 注意 JVM 堆配置：缓冲区对象在 Eden 区分配，高频创建/销毁
BufferedOutputStream（如每次写日志都 new）会加剧 Minor GC - 推荐复用同一个
BufferedOutputStream实例（线程安全需同步或 ThreadLocal），而非反复 new/close
缓冲不是银弹——它把“写慢”转成了“内存占多”和“崩溃丢日志”，关键参数和生命周期管理稍有偏差，效果就大打折扣。
