8KB缓冲区通过批量读取减少系统调用次数，提升小量频繁读取性能；其大小是兼顾I/O效率、内存占用与延迟的历史权衡，非普适最优解。
缓冲区本质是减少系统调用次数
每次 read() 或 write() 调用底层文件或网络设备，都会触发一次系统调用——这涉及用户态到内核态的切换、参数校验、上下文保存与恢复，开销远高于纯内存操作。8KB 缓冲区的作用，就是在用户空间预分配一块固定大小的内存（byte[8192]），让 BufferedInputStream 在首次读取时就从磁盘/网络批量拉取最多 8KB 数据进来；后续多次 read() 都直接从这块内存取，直到耗尽才再次发起系统调用填充。
为什么是 8KB 而不是 1KB 或 64KB
这个值是历史权衡结果，不是绝对最优：
- 太小（如 1KB）：频繁填缓冲，系统调用次数仍高，CPU 花在上下文切换上的时间占比上升
- 太大（如 64KB）：单次读取等待时间变长，尤其在网络流中可能增加首字节延迟；高并发下每个连接独占一份缓冲，内存压力陡增
- 8KB 接近多数文件系统默认块大小（如 ext4、NTFS 的簇/块常为 4KB–8KB），对齐后能减少物理 I/O 次数
实际性能提升取决于你的读取模式
缓冲区只在「频繁小量读取」时效果显著。比如：
- 用
read()单字节循环读一个 10MB 文件 → 默认 8KB 缓冲可将系统调用从约 10M 次降到 ~1.2K 次 - 用
read(byte[])每次读 8KB 或更大 → 缓冲流几乎不带来额外收益，甚至因多一层封装略慢 - 读取网络流（如 HTTP 响应体）→ 若服务端分块发送且每块很小，8KB 缓冲能合并多个小包，降低
recv()调用频次
别忽略 fill() 方法的阻塞行为
BufferedInputStream.fill() 是真正发起系统调用的地方，它会阻塞直到至少读到 1 字节（或 EOF/异常）。这意味着：
- 即使你只调用
read()读 1 字节，背后也可能触发一次最多 8KB 的批量读取 - 如果数据源响应慢（如慢速网络、高延迟存储），
fill()可能卡住线程，此时增大缓冲区不会缓解延迟，反而可能让线程更久地等在那 - 某些场景下（如实时日志 tail），你可能需要更小缓冲（如 1KB）来降低感知延迟，而不是盲目追求吞吐
perf 或 JVM profiler 看清瓶颈到底在系统调用频次，还是在 CPU、内存或网络本身。 
