关键在选对缓冲区大小：顺序读写大文件用32KB–64KB，随机读小文件用4KB–16KB，高并发多流服务单流8KB–16KB，内存受限环境控制在2KB–8KB，须显式传参构造并结合吞吐、sys CPU、RSS内存三指标调优。
关键在选对缓冲区大小——不是越大越快，也不是越小越省，而是按数据特征和运行环境动态匹配。
先搞清不同场景的推荐范围
缓冲区大小直接影响系统调用次数、内存驻留量和内核预读效率。照搬默认 8KB 往往不是最优解：
- 顺序读写大文件（如日志归档、视频切片、备份包）：用 32KB–64KB（32768–65536 字节），对齐常见文件系统块大小，显著减少 read/write 系统调用次数，吞吐提升可达 2–4 倍
- 随机读取小文件（如 JSON 配置、YAML 元数据、图标资源）：选 4KB–16KB，避免一次加载远超实际所需的数据，减少内存浪费和缓存污染
- 高并发多流服务（如网关批量导出、微服务间文件中转）：单流压到 8KB–16KB，防止 100 个 BufferedInputStream 吃掉数百 MB 堆外内存，诱发频繁 GC 或 OOM
- 内存受限环境（如 Serverless 函数、嵌入式 Java 应用）：控制在 2KB–8KB，用多次小拷贝换稳定内存 footprint，避免 swap 或启动失败
代码里怎么设才真正生效
必须显式传参构造，不能只靠默认值。BufferedInputStream 和 BufferedOutputStream 都支持自定义大小：
✅ 正确写法（指定 32KB 缓冲区）：
立即学习“Java免费学习笔记（深入）”；
int bufferSize = 32 * 1024;
BufferedInputStream bis = new BufferedInputStream(
new FileInputStream("data.bin"),
bufferSize
);
BufferedOutputStream bos = new BufferedOutputStream(
new FileOutputStream("output.dat"),
bufferSize
);❌ 常见误区：
- 直接 new FileInputStream 写 while((b = fis.read()) != -1)，没套缓冲流 → 每次 read() 都触发系统调用，性能极低
- 用了 BufferedInputStream 却不传 size 参数 → 落回默认 8KB，错失调优机会
- 为所有流统一设 1MB → 单流吃掉 1MB 堆外内存，10 个流就 10MB，GC 压力陡增
别只看吞吐，还要盯住三个真实指标
调优不是拍脑袋，得结合压测观察拐点：
- I/O 吞吐（MB/s）：用 dd 或 JMH 测 raw vs buffered 对比，看增幅是否收敛
- CPU sys 时间占比：top -H 或 async-profiler 查看内核态时间，过高说明系统调用仍太频繁
- RSS 内存增长量：jstat -gc 或 Native Memory Tracking 观察堆外内存是否异常膨胀
当吞吐提升幅度跌到 30% 以下，往往就是收益衰减点 —— 再加大 buffer，性价比急剧下降。
写操作额外注意 flush 时机
大缓冲区会延迟数据落盘，影响一致性与崩溃恢复能力：
- 不要依赖 close() 自动 flush —— 异常提前退出时可能丢数据
- 关键节点（如每写满 1MB、每处理完一个逻辑单元）主动调用 bos.flush()
- 对实时性要求高的场景（如审计日志），可适当缩小 buffer（如 4KB），换更可控的落盘节奏
