是的，fileinputstream 的 finalize() 方法在 gc 回收前会尝试调用 close() 以释放文件描述符，但该机制不可靠、不及时、不保证执行，且自 jdk 9 起已废弃，唯一可靠方式是显式调用 close() 或使用 try-with-resources。

是的，Java 中 FileInputStream 的 finalize() 方法在 GC 回收该对象前会尝试调用 close()，从而间接关闭底层文件描述符（FileDescriptor）。但这只是“尽力而为”的安全网，并不可靠、不及时、不保证执行。

---

FileInputStream 的 finalize 确实会 close，但有严重限制

FileInputStream 在 JDK 8 及更早版本中重写了 protected void finalize() throws IOException，其核心逻辑是：

• 检查 fd 是否非空且不是标准输入（FileDescriptor.in）；
• 若满足条件，则调用 close()；
• close() 内部会真正释放 FileDescriptor（通过 fd.closeAll(...) 触发 native 层关闭）。

所以从代码行为上看：GC 触发 finalize → finalize 调用 close → close 释放 fd。

但关键问题在于——这整条链路依赖于 GC 的调度，而 GC 不承诺以下任何一点：

• 对象何时变得不可达
• GC 何时运行
• finalize() 何时被调用（甚至是否被调用）
• finalize() 执行是否成功（比如抛异常可能被静默吞掉）

✅ 示例验证：自定义继承类重写 finalize() 加日志，配合 System.gc() 可观察到调用；但去掉 System.gc()，仅靠自然 GC，可能数秒、数分钟甚至永不触发。

OpenJDK 24 Windows x64

OpenJDK 24 Windows x64 官方参考实现（24+36），适合 Windows 环境进行 Java 开发、编译、运行和版本兼容性验证。

下载

---

finalize 已废弃，且 JDK 9+ 彻底转向 Cleaner 机制

• finalize() 自 Java 9 起被标记为 @Deprecated，官方明确不推荐使用；
• JDK 9 引入 java.lang.ref.Cleaner，FileInputStream（及 FileOutputStream 等）在较新 JDK 中已改用 FileCleanable 与 Cleaner 协作清理 fd；
• Cleaner 基于虚引用（PhantomReference），比 finalize() 更轻量、可注册回调、不阻塞 GC，但仍不替代显式 close。

也就是说：
➡️ 旧版靠 finalize() 是“赌运气”；
➡️ 新版靠 Cleaner 是“稍好一点的赌运气”；
➡️ 唯一可靠方式，始终是主动调用 close()。

---

不关流的实际后果很直接

• 文件描述符（fd）是操作系统级资源，数量有限（Linux 默认通常 1024 或 65536）；
• FileInputStream 不 close() → fd 长期占用 → Too many open files 错误；
• 多线程或高并发场景下，泄漏速度极快，服务可能几小时内宕机；
• 即使你“测试时没出错”，也不代表生产环境安全——GC 行为随堆大小、JVM 参数、负载强度剧烈变化。

---

正确做法就三条

• 使用 try-with-resources（最推荐）：

  try (FileInputStream fis = new FileInputStream("a.txt")) {
      // 读取...
  } // 自动调用 fis.close()

• 手动关闭必须放在 finally 且判空：

  FileInputStream fis = null;
  try {
      fis = new FileInputStream("a.txt");
      // ...
  } finally {
      if (fis != null) {
          try { fis.close(); } catch (IOException ignored) {}
      }
  }

• 切勿依赖 finalize / Cleaner / System.gc() 去“兜底”。

不复杂，但容易忽略。

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南