java io流未关闭不会直接导致堆内存泄漏，但会持续占用文件描述符和堆外内存，引发“too many open files”或gc overhead limit exceeded；需用lsof/process explorer定位句柄泄漏，并通过分层声明的try-with-resources确保装饰流正确释放。
Java IO流未正常关闭不会直接导致堆内存泄漏，但会引发文件描述符（File Descriptor）耗尽、堆外内存持续增长，最终触发OOM或系统级异常。问题核心在于底层资源未释放，而非Java对象本身占满堆内存。
关键判断：先确认是不是句柄泄漏
别急着改代码，先验证现象：
- Linux/macOS下执行 lsof -p [pid] | wc -l，观察句柄数是否随运行时间只增不减；聚焦业务常见后缀，比如 lsof -p [pid] | grep "\.log\|\.gz"
- Windows可用 Process Explorer 附加进程，打开Lower Pane → Handles，搜索文件路径，看同一文件是否出现数十个重复句柄
- 配合JVM参数 -XX:+PrintGCDetails 和 jstack [pid]，若线程常卡在
read()或close()调用上，基本可锁定IO阻塞+资源滞留
修复重点：确保装饰流按正确顺序关闭
嵌套流（如 GZIPInputStream 包装 FileInputStream）必须从内到外关闭，否则 Inflater.end() 等Native资源可能跳过释放。try-with-resources的声明顺序决定关闭顺序——越早声明，越晚关闭。
错误写法（看似规范，实则危险）：
Java Maven Common
下载
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
正确写法（显式分层，强制内层优先关闭）：
try (FileInputStream fis = new FileInputStream("a.gz");GZIPInputStream gis = new GZIPInputStream(fis);
InputStreamReader isr = new InputStreamReader(gis);
BufferedReader reader = new BufferedReader(isr)) { ... }
哪些流必须关？哪些可以不关？
不是所有流都需手动管理：
-
必须关闭：涉及系统资源的流，包括
FileInputStream、FileOutputStream、Socket.getInputStream()、URLConnection.getInputStream()、ObjectInputStream、GZIPInputStream等 -
无需关闭：纯内存操作流，如
ByteArrayInputStream、ByteArrayOutputStream、StringReader、StringWriter—— 它们不持有文件句柄或Native内存 -
注意陷阱：用
Files.newInputStream(path)返回的流必须关；但Files.readAllBytes(path)是一次性读取，内部已处理，无需额外关闭
长期预防：建立编码与监控双防线
单靠人盯代码不可靠，要嵌入机制：
- 所有IO操作强制使用 try-with-resources，禁用裸
new XXXStream()+finally { close() }写法（易被异常打断） - CI阶段加入静态扫描，例如用 SpotBugs 检查
OS_OPEN_STREAM规则，自动拦截未关闭流 - 线上服务配置 -XX:+HeapDumpOnOutOfMemoryError，并定期用MAT分析堆转储中
java.util.zip.Inflater、sun.nio.ch.FileChannelImpl实例数量是否异常堆积 - 对高IO服务，设置系统级限制并告警：ulimit -n 值建议设为 65535，并监控
/proc/[pid]/fd/目录条目数突增
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
