BufferedInputStream 通过8KB默认缓冲区减少I/O调用，首次read触发fill填充，后续优先读缓冲区，耗尽再fill；mark/reset依赖缓冲保留数据；缓冲区过小增大开销，过大浪费内存；skip、available等操作需注意绕过缓冲的影响。
BufferedInputStream 通过在内存中维护一块固定大小的缓冲区，减少底层 I/O 调用次数，从而提升读取效率。它不是每次 read() 都直接访问文件或网络，而是先从底层流批量读入缓冲区，后续读取优先从缓冲区取数据。
缓冲区如何被填充和使用
创建 BufferedInputStream 时，默认分配 8192 字节（8KB）缓冲区。首次调用 read() 时，它会一次性从底层 InputStream 中读取最多缓冲区容量的数据到内部 byte[] 中；之后的 read() 操作优先从这个数组中逐字节或批量拷贝，直到缓冲区耗尽，再触发下一次底层填充。
- 单字节 read()：从缓冲区当前位置取一个字节，指针后移；缓冲区空了才重新 fill()
- read(byte[] b, int off, int len)：优先从缓冲区拷贝 min(len, 剩余可用字节数)，不够再 fill() 补充
- mark() 和 reset() 依赖缓冲区保留已读但未消费的数据，所以 markSupported() 返回 true
缓冲区大小怎么影响性能
缓冲区太小（如 128 字节），频繁 fill() 导致系统调用开销大；太大（如 1MB）可能浪费内存，且对多数场景收益递减。8KB 是平衡点，适合大多数磁盘/网络读取场景。
- 可显式指定大小：new BufferedInputStream(in, 16 * 1024) 使用 16KB 缓冲区
- 若底层流支持 mark/reset 且预期回溯距离大，适当增大缓冲区避免提前丢弃
- 小文件或短数据流，缓冲优势不明显；大文件顺序读取时加速效果显著
什么时候缓冲失效或需注意
缓冲只优化“读取”行为，不改变语义。某些操作会绕过或清空缓冲区，导致额外开销或逻辑异常。
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
立即学习“Java免费学习笔记（深入）”；
- 调用 skip(n)：若 n 小于当前缓冲区剩余字节数，直接移动内部指针；否则先清空缓冲区再委托底层 skip
- 调用 available()：返回缓冲区中尚未读取的字节数，不是底层流的真实可读量
- 底层流本身已缓冲（如 ByteArrayInputStream），再套 BufferedInputStream 意义不大
- close() 会释放缓冲区，但不自动 close 底层流——需自行管理资源
实际读取时的典型流程示例
假设缓冲区大小为 8KB，读取一个 20KB 的文件：
- 第 1 次 read() → 触发 fill()，从文件读 8KB 到缓冲区，返回首字节
- 接下来约 8191 次 read() → 全部从内存缓冲区取，无 I/O
- 第 8193 次 read() → 缓冲区空，再次 fill() 读入下一个 8KB
- 再读约 8191 字节 → 再次命中缓冲区
- 最后不足 8KB 的部分 → fill() 读剩余数据（比如 3616 字节），后续 read() 逐步返回
总共仅 3 次底层 read 系统调用，而非 20480 次。
