java中未在finally中关闭stream流的核心问题是“关不牢”，异常发生时流无法释放导致句柄泄漏；必须关闭绑定系统资源的流（如fileinputstream、socket流等），而内存流（如bytearrayinputstream）无需手动关闭；推荐使用try-with-resources确保自动、逆序、可靠关闭。

Java中未在finally中关闭Stream流，核心问题不是“没关”，而是“关不牢”——异常一来，流就悬在那儿，句柄持续占用，直到进程重启或系统崩溃。

为什么finally里不关就容易出事

很多代码只在try块末尾调用close()，但一旦read()或write()抛出IOException，后续语句直接跳过，流对象根本没机会释放。更隐蔽的是：即使写了finally，若没做null检查，流初始化失败时调用close()会触发NullPointerException，反而掩盖原始异常。

哪些流必须关、哪些其实不用

不是所有流都需手动关闭：

Java Maven Common

Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。

下载

• 必须关闭的：FileInputStream、FileOutputStream、BufferedReader、BufferedWriter、ObjectInputStream、ObjectOutputStream、Socket.getInputStream()等——它们背后绑定了操作系统文件描述符或网络连接
• 通常不用关的：ByteArrayInputStream、ByteArrayOutputStream、StringReader、StringWriter——数据在内存中，不涉及底层资源

真正可靠的关闭写法

别再手写finally了。JDK 7+ 的try-with-resources是事实标准，它会在退出作用域时自动调用close()，且能按声明逆序关闭嵌套流（比如BufferedReader → FileReader → FileInputStream），避免顺序错误。

示例：

```java
try (FileInputStream fis = new FileInputStream("a.txt");
     BufferedInputStream bis = new BufferedInputStream(fis);
     DataInputStream dis = new DataInputStream(bis)) {
    // 读取逻辑
} // 所有流在此自动关闭，无论是否异常

嵌套和包装流的关闭陷阱

常见误区是只关外层、漏掉底层源头。例如：

• 用new BufferedReader(new InputStreamReader(conn.getInputStream()))，只关BufferedReader不够，conn.getInputStream()本身也得由你负责——除非你确认上层框架已托管其生命周期
• Spring RestTemplate或OkHttp返回的Response.body().byteStream()，必须显式消费并关闭，否则socket句柄卡在CLOSE_WAIT状态
• XML/JSON解析器（如DocumentBuilder.parse(is)）绝不会帮你关传入的InputStream，必须自己包在try-with-resources里

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