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