流关闭不当不直接导致堆内存泄漏，但会引发文件描述符耗尽、连接池枯竭、缓冲区对象驻留等问题，最终触发OutOfMemoryError；应优先使用try-with-resources，确保自动关闭，避免手动close遗漏或重复关闭。
流关闭不当本身不直接造成堆内存泄漏，但会引发资源耗尽和间接内存问题——比如文件描述符被占满、连接池枯竭、缓冲区对象长期驻留，最终触发 OutOfMemoryError 或使 GC 无法回收关联对象。关键在于：未关闭的流常持有底层资源（如 FileChannel、Socket、ByteBuffer），而这些资源背后可能绑定堆外内存或强引用堆内对象。
为什么流没关会“像”内存泄漏
常见表现不是堆内存直线飙升，而是：
- 频繁 Full GC 后老年代仍居高不下，因为流对象及其缓冲区（如
BufferedInputStream的内部byte[]）迟迟不被释放 - 系统级报错如
java.io.IOException: Too many open files，说明 OS 层资源耗尽，JVM 可能被迫缓存更多状态 - 数据库连接池、HTTP 客户端连接复用失败，导致新建连接激增，每个连接附带的缓冲区和上下文对象堆积
必须用 try-with-resources 替代手动 close
这是最根本、最可靠的解决方式。它确保无论是否发生异常，资源都会在作用域结束时自动关闭。
- ✅ 正确写法（JDK 7+）：
try (FileInputStream fis = new FileInputStream("data.txt");<br> BufferedReader reader = new BufferedReader(new InputStreamReader(fis))) {<br> // 使用 reader<br>}（自动调用close()） - ❌ 错误写法：
FileInputStream fis = new FileInputStream("data.txt");<br>BufferedReader reader = new BufferedReader(new InputStreamReader(fis));<br>// 忘记 close()，或只在 try 块里 close 却没包在 finally 中
对已存在的 legacy 代码做兜底防护
若暂时无法重构为 try-with-resources，至少保证 finally 块中安全关闭：
Java Maven Common
下载
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
立即学习“Java免费学习笔记（深入）”；
- 关闭前判空：
if (reader != null) try { reader.close(); } catch (IOException ignored) {} - 多个资源按逆序关闭（后开先关），避免前一个关闭失败导致后续跳过
- 不要把
close()放在catch里——异常时try中的流可能根本没创建成功
特别注意包装流和自定义流的关闭行为
像 BufferedInputStream、GZIPInputStream、ObjectInputStream 这类包装流，调用其 close() 会**自动委托到底层流**。你只需关闭最外层，无需重复关底层。
- ✅ 推荐：
try (ObjectInputStream ois = new ObjectInputStream(new FileInputStream("obj.dat"))) { ... } - ❌ 多余且危险：
ois.close(); fis.close();——fis可能已被ois.close()关闭，再关会抛IOException - ⚠️ 注意：某些框架流（如 Spring 的
Resource）需调用其专用方法（如resource.getInputStream().close()），不能只关 resource 本身
配合工具及时发现遗漏
静态检查比靠人眼更可靠：
- 启用 IDE 警告（IntelliJ/IDEA 默认标出未关闭的 AutoCloseable）
- 在 CI 中集成
SpotBugs或SonarQube，规则如OS_OPEN_STREAM、RV_DONT_JUST_NULL_CHECK_READLINE - 运行时监控：通过
jstat -gc <pid>观察EC（Eden 区）、OU（老年代使用量）趋势；若频繁 Full GC 且OU不降，配合jmap -dump:format=b,file=heap.hprof <pid>用 MAT 查看java.io.*实例数量是否异常偏高
