堆外内存泄漏主要由未调用Deflater.end()导致，需通过jcmd、jstack、jmap和GC日志定位；复现验证需循环创建Deflater不调end()并监控RES；修复应强制池化、try-with-resources或ThreadLocal复用，并注意JDK 21+ Cleaner机制变更。
直接看堆外内存增长趋势和 deflater 对象生命周期，重点盯住没调用 end() 的实例。
确认是否真由 Deflater 引发堆外泄漏
先排除其他堆外来源（如 MappedByteBuffer、DirectByteBuffer），聚焦 Deflater：
- 用 jcmd <pid> 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() 没被调用：
- 用 jmap -histo:live <pid> 统计存活对象，重点关注
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>的 RES 是否猛涨 - 加 JVM 参数 -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -Xlog:gc+ref=debug，观察 GC 是否真的回收了 Deflater 对象（注意：只有对象被 GC，其 Cleaner 才会触发 native 内存释放）
- 升级 JDK 后特别留意：JDK 21+ 对 Deflater 的 Cleaner 机制有调整，部分版本存在延迟释放问题；JDK 25 已知 G1GC 可能“跳过”某些 Cleaner 注册对象（参考携程踩坑案例）
快速缓解与长期规避
线上救火和代码规范要同步推进：
立即学习“Java免费学习笔记（深入）”；
- 临时加 -XX:MaxDirectMemorySize=512m（或更低）限制堆外上限，让 OOM 提前暴露，避免被 OS kill
- 把 Deflater 改成池化使用：用 Apache Commons Pool 或自建 ThreadLocal<Deflater>，复用实例，避免高频创建销毁
- 禁用默认构造函数，强制走带
nowrap=true参数的构造（减少 zlib header 开销），并在每次 use 后 reset() + end() 形成闭环 - 对短文本（
