堆外内存泄漏主要由未调用deflater.end()导致，需通过jcmd、jstack、jmap和gc日志定位；复现验证需循环创建deflater不调end()并监控res；修复应强制池化、try-with-resources或threadlocal复用，并注意jdk 21+ cleaner机制变更。
直接看堆外内存增长趋势和 deflater 对象生命周期，重点盯住没调用 end() 的实例。
确认是否真由 Deflater 引发堆外泄漏
先排除其他堆外来源（如 MappedByteBuffer、DirectByteBuffer），聚焦 Deflater：
- 用 jcmd
VM.native_memory summary scale=MB 查 Native Memory 总用量，重点关注 Internal 或 Other 类别是否随请求量线性上涨 - 配合 jstack 抓线程快照，搜索
Deflater、GZIPOutputStream、ZipOutputStream等关键词，看是否有大量处于运行/阻塞态的压缩相关线程 - 检查 GC 日志：如果堆内对象回收正常（Young GC 效果好、无 Full GC），但 RES 内存持续飙升，基本可锁定堆外问题
定位未 end() 的 Deflater 实例
Deflater 对象本身小，但每个背后都绑着一块 native buffer。泄漏根源在于 Java 对象还活着，而 end() 没被调用：
JavaStoryDevelop
下载
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- 用 jmap -histo:live
统计存活对象，重点关注 java.util.zip.Deflater实例数是否异常高（比如每秒创建数百个且不下降） - 若用到了 iText，检查 PDF 生成/合并逻辑：是否在循环中反复 new Document() / PdfWriter() 而未 close()；iText 5 中
PdfWriter.getInstance()、iText 7 中PdfWriter.close()都会触发底层 Deflater.end()，漏掉就留坑 - 自定义压缩工具类要严格遵循 try-with-resources 或 finally 块中显式调用
deflater.end()，不能依赖 finalize
验证与复现的关键操作
别靠猜，用可控方式复现并验证修复效果：
- 写一个最小复现脚本：循环 new Deflater() → setLevel() → setInput() → deflate() → 不调 end()，跑几千次后观察
top -p <pid></pid>的 RES 是否猛涨 - 加 JVM 参数 -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -Xlog:gc+ref=debug，观察 GC 是否真的回收了 Deflater 对象（注意：只有对象被 GC，其 Cleaner 才会触发 native 内存释放）
- 升级 JDK 后特别留意：JDK 21+ 对 Deflater 的 Cleaner 机制有调整，部分版本存在延迟释放问题；JDK 25 已知 G1GC 可能“跳过”某些 Cleaner 注册对象（参考携程踩坑案例）
快速缓解与长期规避
线上救火和代码规范要同步推进：
- 临时加 -XX:MaxDirectMemorySize=512m（或更低）限制堆外上限，让 OOM 提前暴露，避免被 OS kill
- 把 Deflater 改成池化使用：用 Apache Commons Pool 或自建 ThreadLocal
，复用实例，避免高频创建销毁 - 禁用默认构造函数，强制走带
nowrap=true参数的构造（减少 zlib header 开销），并在每次 use 后 reset() + end() 形成闭环 - 对短文本（
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
