Java输入输出类库与FileInputStream解析

本文深入剖析了Java中FileInputStream使用时的常见陷阱与最佳实践，从路径解析误区（当前工作目录 vs 类路径）、资源加载方式选择（getResourceAsStream()才是classpath资源的正确打开方式），到性能优化关键（BufferedInputStream批量读取的必要性及避坑要点），再到与Scanner混用导致的数据丢失风险，全面覆盖开发中高频出错场景；同时强调了JDK 9+小文件读取新方案、编码显式指定、流关闭原则及available()方法的不可靠性，帮助开发者避开隐蔽坑点，写出更健壮、高效、可维护的I/O代码。

FileInputStream 读取文件时为什么总是抛出 FileNotFoundException？

根本原因通常是路径没写对，而不是文件真丢了。Java 的 FileInputStream 默认以当前工作目录（不是类路径、也不是 src 目录）为基准解析相对路径。

• 运行 JAR 包时，"data.txt" 指的是 JAR 所在目录下的 data.txt，不是 JAR 包内部的资源
• IDE 运行时，当前工作目录通常是项目根目录，但不同 IDE（IntelliJ / Eclipse）可能有差异，建议用 System.getProperty("user.dir") 打印确认
• 若文件在 classpath 下（如 src/main/resources/config.json），别用 FileInputStream，改用 Class.getResourceAsStream()

BufferedInputStream + FileInputStream 组合还有必要吗？

有必要，尤其读取中大文件（几 MB 以上）时。直接用 FileInputStream.read() 单字节读取，系统调用太频繁，性能极差；而 BufferedInputStream 自动缓存，默认 8192 字节缓冲区，能大幅减少底层 I/O 次数。

• 不要手动包装成 new BufferedInputStream(new FileInputStream(...)) 后再调用 read() 单字节——这仍慢，应改用 read(byte[]) 批量读
• JDK 9+ 推荐优先用 Files.readAllBytes(Paths.get(...)) 读小文件（
• 注意：BufferedInputStream 不改变异常类型，FileNotFoundException 和 IOException 仍需显式捕获或声明

FileInputStream 与 Scanner 混用会出什么问题？

会丢数据，甚至阻塞。因为 Scanner 内部也维护缓冲区，它可能从 FileInputStream 预读若干字节（比如为了判断下一行是否存在），而你后续又用原流的 read()，就会跳过这部分已读未消费的数据。

• 选一个：要么全程用 Scanner（适合按行/按词解析文本），要么全程用 FileInputStream + InputStreamReader + BufferedReader（更可控、支持编码指定）
• Scanner 默认使用平台默认编码，中文环境易乱码；务必用 new Scanner(inputStream, "UTF-8") 显式指定
• 关闭流时，只关外层（如 Scanner 或 BufferedReader），它会自动委托关闭底层 FileInputStream

try (FileInputStream fis = new FileInputStream("log.bin");
     BufferedInputStream bis = new BufferedInputStream(fis)) {
    byte[] buf = new byte[4096];
    int len;
    while ((len = bis.read(buf)) != -1) {
        // 处理 buf[0] 到 buf[len-1]
    }
} catch (IOException e) {
    // 注意：FileInputStream 构造本身可能抛出 FileNotFoundException
    // 它是 IOException 子类，统一 catch 即可
}

今天关于《Java输入输出类库与FileInputStream解析》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！