BufferedOutputStream默认8KB缓冲区的核心作用是合并多次小写操作，减少系统调用次数；它在内存中维护8192字节数组，write()先填数组，满或flush/close时才批量交由内核处理，从而将高频小写压缩为低频大写。
BufferedOutputStream 的默认 8KB 缓冲区，核心作用是把多次小写操作“攒起来”，等凑够一整块再交给内核，从而显著减少系统调用次数。
为什么 8KB 能大幅降低系统调用频率
每次调用 FileOutputStream.write() 写入几个字节，都会触发一次用户态到内核态的切换——这个过程开销不小。而 BufferedOutputStream 在内存里维护一个 8192 字节的数组，所有 write() 都先往这个数组里填，只有填满、显式 flush() 或 close() 时，才一次性把整块数据交出去。比如连续写 100 条日志（每条平均 50 字节），没缓冲就是约 100 次系统调用；有 8KB 缓冲，通常只需 1–2 次真正落盘请求。
8KB 不是固定最优值，而是权衡结果
这个大小不是随便定的：
- 比 1KB 大得多，能有效压缩上百次小写为几次调用
- 又远小于 64KB，避免在高并发场景下堆内存压力过大
- 对齐主流文件系统块大小（如 ext4/NTFS 默认 4KB），利于底层 IO 调度和预读
缓冲区大小与系统调用次数的关系不是线性的
增大缓冲区确实能进一步减少调用次数，但收益会递减：
- 从 8KB 增到 32KB，可能让调用次数再降 30%～40%，但内存占用翻四倍
- 超过 64KB 后，单次写入变大，可能增加延迟，还容易触发 JVM GC 压力
- 真正决定调用频次的，不只是缓冲区大小，还包括写入节奏、是否及时 flush、以及操作系统页缓存行为
别忘了 flush 和 close 的时机影响实际效果
缓冲区再大，如果频繁手动 flush，等于主动拆散合并机会，系统调用次数立刻回升：
- 关键日志后 flush 是必要的，但非关键场景可依赖自动 flush（如缓冲满或 close）
- close() 会隐式调用 flush()，所以务必确保流被正确关闭
- 不 close 只是不 flush，缓冲区里的数据就卡在内存里，进程崩溃就全丢
