FileNotFoundException是IOException的受检子类,反映JVM无法以指定方式打开路径,原因包括权限不足、目录误用、符号链接断裂等,不单是文件不存在。

FileNotFoundException 是什么,为什么它总在运行时才爆出来
FileNotFoundException 是 IOException 的子类,属于受检异常(checked exception),编译器强制你处理它。但它又很“假”——名字叫“文件没找到”,实际触发条件远不止路径不存在:权限不足、路径是目录而非文件、符号链接断裂、NFS挂载失效、甚至某些 JVM 在 Windows 上对 UNC 路径解析失败,都会抛这个异常。
关键点在于:它不反映“磁盘上有没有这个文件”,而反映“当前 JVM 进程能否以指定方式(如 new FileInputStream(path))打开该路径”。所以别只查 ls 或 File.exists() 就以为安全了。
用 try-catch 还是 throws?选错会导致资源泄漏
直接 throws FileNotFoundException 看似省事,但把异常甩给调用方后,往往导致上层忽略或错误吞掉——比如日志没打、用户看到空白页、定时任务静默失败。更危险的是,如果配合 FileInputStream 等资源操作,不加 try-with-resources 会真漏关流。
- 优先用
try-with-resources包裹所有带AutoCloseable的 IO 操作 - 捕获后别空 catch:
catch (FileNotFoundException e) { logger.warn("config file missing, using defaults", e); } - 若必须 throws,请确保调用链最外层(如 Spring Controller、main 方法)有统一兜底处理逻辑
try (FileInputStream fis = new FileInputStream("/etc/app.conf")) {
// 处理配置
} catch (FileNotFoundException e) {
// 明确记录缺失上下文:哪个服务?哪个环境?期望路径是否可配?
throw new IllegalStateException("Critical config missing: /etc/app.conf", e);
}
比 catch 更早一步:用 Files.exists() + Files.isReadable() 预检
File.exists() 不可靠——它不检查权限,也不区分文件/目录;Files.exists(Paths.get(path)) 好些,但仍不够。真正稳妥的预检是组合判断:
立即学习“Java免费学习笔记(深入)”;
-
Files.exists(path):路径是否存在(含软链目标) -
Files.isRegularFile(path):确保是普通文件,不是目录或设备 -
Files.isReadable(path):当前进程是否有读权限(Linux/macOS 有效,Windows 下部分场景可能误报)
注意:这三步不是原子操作,中间仍可能被其他进程删改。预检只降低概率,不能替代 try-catch。
Path configPath = Paths.get("/data/inventory.json");
if (!Files.exists(configPath) ||
!Files.isRegularFile(configPath) ||
!Files.isReadable(configPath)) {
throw new IllegalStateException("Config file invalid: " + configPath);
}
// 此时再 new FileInputStream 才相对安全
常见陷阱:getResourceAsStream() 和 classpath 路径的隐式转换
很多人用 MyClass.class.getResourceAsStream("config.properties") 却仍遇到 FileNotFoundException,问题不在文件本身,而在路径规则:
- 路径以
/开头 → 从 classpath 根开始找(如/static/js/app.js) - 路径不以
/开头 → 相对于当前类所在包(com.example.App调用"config.properties"会去找com/example/config.properties) - 打包成 JAR 后,路径分隔符必须是
/,不能用\(Windows 开发者常在这里翻车)
调试技巧:打印 MyClass.class.getResource("config.properties") 返回的 URL,看它到底指向哪。返回 null 就说明 classpath 里压根没这个资源。
FileNotFoundException 最难缠的地方不是找不到文件,而是“你以为找到了,其实打开方式错了”——比如用 FileReader 读二进制文件、用 Paths.get() 解析含空格的用户输入路径、或者在容器里挂载路径时权限没透传。每次看到这个异常,先别急着补 catch,花 30 秒确认下 ls -l 输出和 Java 进程 UID 是否一致。










