8KB缓冲区是权衡系统调用开销、内存占用与文件系统块对齐后的最优解：减少内核切换、避免内存浪费、适配4KB文件系统块；字节流缓存8192字节，字符流缓存8192字符；可自定义但不宜盲目调大。
缓冲流内部默认构建的8KB数组，本质是为了解决“频繁小粒度I/O操作效率低”这个根本问题。它不是凭空设定的 magic number，而是综合硬件特性、内存开销与常见读写模式后权衡出的实用值。
为什么是8KB？不是1KB或64KB？
8KB（即8192字节）这个大小在多数场景下能较好平衡三方面：
- 减少系统调用次数：一次read()或write()触发一次内核态切换，开销不小。8KB足以覆盖大量单字节或小批量读写（比如逐行解析、逐字符处理），把上百次系统调用压缩成几次；
- 避免内存浪费：比1KB缓冲区提升明显，又远小于64KB——后者在大量并发流场景下容易造成堆内存压力，尤其在服务端应用中；
- 对齐文件系统块大小：主流文件系统（如ext4、NTFS）默认簇/块大小常为4KB，8KB是其整数倍，有利于底层IO调度与预读优化。
字节流与字符流的缓冲区区别
虽然都叫“8KB”，但实际含义不同：
- BufferedInputStream / BufferedOutputStream：真正分配一个 byte[8192] 数组，每个元素占1字节，总容量固定为8192字节；
- BufferedReader / BufferedWriter：默认分配的是 char[8192] 数组，即最多缓存8192个字符。由于字符可能经编码转换（如UTF-8中一个中文占3字节），其底层实际占用的字节数不固定，但数组长度仍是8192。
缓冲区怎么被实际使用的？
以 BufferedInputStream 为例，核心逻辑围绕 fill() 方法展开：
- 首次调用 read() 时，发现缓冲区为空 → 触发 fill() → 底层 FileInputStream 一次性读满8192字节到内部 byte[] 中；
- 后续 read() 先从该数组按需取数据（比如只取1个字节），不触发磁盘访问；
- 直到数组读完（pos == count），才再次调用 fill() 加载下一批；
- 即使你用 read(byte[] b, int off, int len) 读大块数据，只要 len ≤ 剩余缓冲数据量，仍不触发系统调用。
可以改，但别盲目调大
构造时支持自定义大小，例如：new BufferedInputStream(in, 32 * 1024)
- 适合已知数据块极大、且内存充足（如视频分片读取）的场景；
- 但若设置过大（如1MB），可能导致GC压力上升、缓存局部性变差，甚至因长时间未消费而阻塞fill；
- 一般建议保持默认值，仅在压测发现瓶颈且确认是缓冲区过小导致时再调整。
