Java资源未正常关闭导致的内存泄漏本质是系统级资源（如文件句柄、Socket、Inflater、数据库连接）未释放，尤其涉及Native内存时GC无法回收，表现为堆内存平稳但句柄耗尽、OOM或Full GC频繁。
Java 资源未正常关闭导致的内存泄漏，本质是系统级资源（如文件句柄、Socket、Inflater、数据库连接等）未释放，尤其涉及 Native 内存时，GC 无法回收——这类泄漏往往不体现在堆内存暴涨，却会引发 OOM、句柄耗尽或 Full GC 频繁。排查关键不是找“对象”，而是找“没关干净的流/连接/句柄”。
看监控：先确认是不是资源型泄漏
这类问题通常伴随以下现象，满足任意两项即可高度怀疑：
- JVM 堆内存增长平缓，但 系统级指标异常：如 Linux 的
lsof -p PID | wc -l显示打开文件数持续上升（超 65535）、cat /proc/PID/status | grep Threads线程数只增不减； - 日志中频繁出现
java.io.IOException: Too many open files或OutOfMemoryError: unable to create new native thread； - GZIPInputStream、Inflater、ZipFile、SSLContext 等类的实例在堆 dump 中数量异常多，且多数处于“已使用但未 close”状态；
- 使用
jstat -gc PID观察到老年代增长缓慢，但jstat -compiler PID或jstat -class PID显示类加载数持续增加（可能因反复创建新流触发类加载）。
查代码：重点盯装饰器流和 try-with-resources 声明顺序
90% 的流泄漏源于嵌套声明 + 错误关闭顺序。比如 GZIPInputStream 包裹 FileInputStream，若外层 BufferedReader 先抛异常中断关闭流程，内层 GZIPInputStream 的 end() 就不会执行，Native 内存永久泄漏。
- 搜索项目中所有
new FileInputStream、new Socket、new ZipFile、new PreparedStatement等资源创建点； - 检查是否全部被
try-with-resources包裹；若用了，确认声明顺序是否从底层到顶层（如FileInputStream → GZIPInputStream → InputStreamReader → BufferedReader），而非反过来嵌套写； - 特别注意工具方法：比如封装了
getReader(String path)，内部 new 了流但没暴露 close 接口，调用方根本无法关闭。
抓现场：用 jmap + MAT 定位原生资源持有者
堆 dump 不仅能看 Java 对象，还能反向追踪 Native 资源归属：
立即学习“Java免费学习笔记（深入）”；
- 用
jmap -dump:format=b,file=heap.hprof PID获取快照； - 用 Eclipse MAT 打开，执行 Leak Suspects Report，重点关注
java.util.zip.Inflater、sun.nio.ch.FileChannelImpl、java.net.Socket实例； - 对任一可疑 Inflater 实例右键 → Path To GC Roots → exclude weak/soft references，查看谁持有了它——大概率指向某个未正确关闭的 GZIPInputStream 或其包装类；
- 结合线程栈（
jstack PID）比对：如果某线程长时间停留在read()或close()，说明卡在 IO 阻塞或 close 异常未处理。
验证修复：加日志 + 压测观察句柄变化
改完代码不能只看堆内存，要验证系统资源是否真正释放：
- 在关键流的
close()前加日志，如log.debug("Closing GZIPInputStream for {}", fileName)； - 压测时用
watch -n 1 'lsof -p PID | wc -l'实时监控句柄数，正常应波动平稳、峰值后回落； - 对数据库连接池，检查连接池监控指标（如 HikariCP 的
ActiveConnections、IdleConnections），确保归还率 100%，无连接泄漏； - 上线后设置
-XX:+PrintGCDetails -XX:+PrintGCTimeStamps，关注是否有GC pause突增——资源泄漏常伴随 GC 回收压力间接升高。
