用字节数组缓冲可提升FileInputStream读取效率，推荐8KB（8192字节）起始大小，需检查read()返回的实际字节数，避免频繁新建数组或忽略返回值。
用字节数组作缓冲区能显著提升 FileInputStream 的读取效率，核心在于减少系统调用次数和 JVM 堆内存分配开销。默认单字节读取（read()）每字节触发一次 native 调用，而批量读取（read(byte[])）将多次 I/O 合并为一次，是更贴近底层硬件行为的用法。
选择合适大小的缓冲区数组
缓冲区太小（如 16 或 64 字节）起不到明显优化效果；太大（如几 MB）可能浪费堆内存或引发 GC 压力。实际中推荐使用 8KB（8192 字节）作为起点，这是多数操作系统文件系统块大小的整数倍，也与 JVM 默认 I/O 缓冲策略对齐：
- 常见合理值：4096、8192、16384（即 4KB、8KB、16KB）
- 避免使用过小值（如 100），它仍会频繁调用内核
- 不建议盲目设为 1MB+，除非明确处理超大连续读且内存充足
正确使用 read(byte[]) 批量读取
调用 read(byte[] b) 返回的是**本次实际读到的字节数**，可能小于数组长度（尤其在流末尾或网络/磁盘延迟时），必须检查返回值，不能假设填满整个数组：
- 始终用
int len = in.read(buffer);获取真实读取长度 - 仅对
buffer[0] ~ buffer[len-1]范围做后续处理 - 当
len == -1表示流已结束，应立即退出循环
配合 BufferedInputStream 可进一步简化
如果不想手动管理字节数组，可直接包装 FileInputStream 为 BufferedInputStream，它内部已封装了默认 8KB 缓冲区，并透明处理批量读逻辑：
new BufferedInputStream(new FileInputStream(file))- 后续仍调用
read(byte[])，但底层自动缓冲，减少实际磁盘访问 - 注意：若需精确控制缓冲区大小，可用带 size 参数的构造方法，如
new BufferedInputStream(in, 16384)
避免常见误区
有些写法看似用了数组，实则未发挥缓冲优势：
- 错误：反复新建数组（
while (...) { byte[] buf = new byte[8192]; in.read(buf); }）→ 频繁分配对象，加重 GC - 错误：只调用
read()单字节读，再塞进数组 → 完全没减少系统调用 - 错误：忽略返回值，直接处理整个数组 → 可能读到旧数据或越界
- 建议：复用同一数组实例，声明在循环外，仅重用不重建
