不能直接用file.length()分配数组一次性读完，因存在竞态条件、特殊文件长度不准、超大数组oom风险；read()必须检查返回值len，正确使用new string(buffer, 0, len)；缓冲区推荐8192，依场景调整；bufferedinputstream可简化逻辑但牺牲控制权；byte[]需循环外复用防gc。
为什么不能直接用 file.length() 分配数组再一次性读完
看似最省事：先 file.length() 得到大小，再 new byte[(int) file.length()]，最后 in.read(buffer) —— 但这个做法在真实场景中风险很高。文件可能被其他进程并发写入，length() 和 read() 之间存在竞态窗口；如果文件是设备文件、socket 文件或某些特殊挂载点（如 /proc），length() 可能返回 0 或不准确值；JVM 对超大数组有堆限制，比如 2GB+ 文件在 32 位或受限堆配置下会直接抛 OutOfMemoryError。它只适合已知小而静态的配置文件，不是通用解法。
read(byte[]) 循环读取时必须检查返回值
每次调用 in.read(buffer) 返回的是实际读到的字节数，不是数组长度。忽略它会导致两种典型错误：一是把缓冲区里残留的旧数据当新内容处理（比如上次循环读了 3 字节，这次只读了 2 字节，却按 8 字节全量解析）；二是越界访问，比如 new String(buffer) 默认用整个数组，末尾未覆盖部分可能是随机垃圾值。正确做法是：
- 声明一个
int len接收返回值 - 只对
buffer[0]到buffer[len - 1]区间做操作 - 遇到
len == -1立即退出循环，不要继续读 - 字符串构造必须显式传入偏移和长度：
new String(buffer, 0, len)
缓冲区大小选 8192 还是 4096？别硬背，看场景
8192（8KB）是多数情况下的合理起点，但它不是银弹。关键要看你的 I/O 模式：
- 顺序大文件读取（如日志归档）：用
16384（16KB）可进一步降低系统调用次数，收益明显 - 小文件高频读（如模板文件加载）：用
4096更节省内存，避免浪费 - 嵌入式或内存受限环境（如 Android 低配机型）：
2048更稳妥，防止 GC 频繁触发 - 绝对不要用
100或1024这类过小值——它只是把单字节读的开销换成了高频数组填充，没本质改善
操作系统页大小（通常是 4KB）和磁盘块大小（常见 4KB/8KB）是重要参考，但最终应结合压测结果调整，而不是凭经验拍定。
要不要套一层 BufferedInputStream？看是否需要简化逻辑
如果你只关心「读得快」且不介意多一次对象包装，new BufferedInputStream(new FileInputStream(file)) 是最省心的选择。它内部默认用 8192 缓冲区，并自动处理分段读、剩余字节缓存等细节，你后续仍可调用 read(byte[])，底层会按需从自己的缓冲区供给，减少真实磁盘访问。但注意两个边界：
- 若你需要精确控制每次物理读的粒度（比如配合 mmap 或自定义预读策略），就不能依赖它，必须裸用
FileInputStream - 它的缓冲区大小不可动态调整，初始化后固定；如需运行时切换（例如根据文件类型切不同 buffer），只能自己管理
byte[]
真正容易被忽略的，是复用同一 byte[] 实例——它必须声明在循环外，否则每次迭代都 new 会快速触发 Young GC，反而拖慢整体吞吐。这点在长周期批处理任务里尤为关键。
