BufferedInputStream 通过减少系统调用次数提升整体读取效率，而非加快单次读取速度；它内部维护缓冲区（默认8KB），批量读取填充，后续从内存返回数据，需配合read(byte[])批量消费才能发挥效果。
BufferedInputStream 本身不加速读取，它通过减少系统调用次数来降低开销，从而让整体读取更高效。 真正的“加速”来自避免每次 read() 都触发底层 I/O 操作，而不是提升单次读取速度。
缓冲区减少了系统调用频次
未包装的 InputStream（如 FileInputStream）每次调用 read()，都可能触发一次系统调用（比如 read(2)），而系统调用开销较大。BufferedInputStream 在内部维护一个字节数组（默认 8192 字节），首次读取时一次性从底层流填充整个缓冲区，后续 read() 直接从内存中返回数据，直到缓冲区耗尽才再次触发系统调用。
- 读 1000 个字节，若每次只读 1 字节：约 1000 次系统调用 → 慢
- 用 BufferedInputStream（8KB 缓冲）：通常只需 1 次系统调用 → 快
合理设置缓冲区大小更关键
默认 8KB 对多数场景够用，但并非越大越好。过大的缓冲区会占用更多堆内存，且对小文件或网络流可能增加延迟；过小则起不到充分缓冲作用。可根据实际场景调整：
- 读大文件（>10MB）：可设为 64KB 或 128KB（如
new BufferedInputStream(in, 65536)） - 读网络流（如 HTTP 响应体）：参考远端 MTU 或服务器分块大小，32KB 较稳妥
- 内存受限环境（如嵌入式）：可降到 2KB 或 4KB，需实测权衡
配合批量读取才能发挥最大效果
如果仍用 while ((b = bis.read()) != -1) 逐字节读，缓冲区几乎无意义——因为每次 read() 都会先查缓冲区、再返回 1 字节，逻辑开销反而略增。必须使用带数组的重载方法：
立即学习“Java免费学习笔记（深入）”；
- ✅ 推荐：
bis.read(buffer)或bis.read(buffer, off, len) - ❌ 避免：
bis.read()单字节循环（除非业务强要求） - 示例：用
byte[] buf = new byte[8192]; int n; while ((n = bis.read(buf)) != -1) { /* 处理 buf[0..n-1] */ }
注意它不改变底层流行为
BufferedInputStream 是装饰器，不加速磁盘寻道、不压缩数据、不优化网络往返。它的收益完全取决于「底层流是否支持高效批量读」以及「上层是否配合批量消费」：
- 对慢速设备（如串口、某些 USB 设备），缓冲能明显掩盖延迟
- 对已高度优化的流（如 NIO 的
FileChannel+ 内存映射），额外加 Buffer 可能无收益甚至略拖慢 - 若底层是
ByteArrayInputStream，加 Buffer 属于冗余，纯内存拷贝反而多一次复制
