堆外内存泄露排查：分析 DirectMemory 未及时触发 GC 导致 OOM 的成因与 -XX:MaxDirectMemorySize 参数

几乎每个用Ja va做服务端开发的团队，早晚都会踩一脚这个坑：堆外内存泄漏。很多人以为是“没释放”，但真相其实是“该释放却没被回收”。要理解这个问题，得从DirectByteBuffer这个袋里对象的生命周期讲起。

堆外内存泄漏的本质，不是代码里少调了某个释放方法，而是DirectByteBuffer对象在堆内活得太久了。它本身很小，只是个装着指针和元信息的小对象，常驻在老年代；但它引用的那块堆外内存可能高达几百MB。JVM的GC策略在这里露出一个关键短板——YGC只管新生代的小年轻们，一旦DirectByteBuffer混进了老年代，它就彻底“隐身”了。除非老年代触发CMS、G1 Mixed GC或者Full GC，否则Cleaner那条回收链就一直卡着不动，堆外内存就这么一直占着。

DirectMemory 为何不随堆内 GC 及时回收？

回到GC本身的运行逻辑，就看得更清楚了。YGC只清理新生代，而老年代里的DirectByteBuffer，GC完全不去碰它。当老年代迟迟不触发CMS、G1 Mixed GC或Full GC时，这些对象就一直“活着”，堆外内存持续占用。Cleaner的clean()调用依赖GC回收DirectByteBuffer后的ReferenceQueue处理链——链条卡在老年代未回收，整个回收就停滞。

换个角度说：不是堆外内存没被释放，是触发释放的那个机制（GC回收DirectByteBuffer）根本没被触发。

-XX:MaxDirectMemorySize 的真实作用机制

这个参数的作用常被误解。它不是一个硬性的内存隔离墙，而更像一个触发器。它的默认值等于-Xmx（堆最大值），但很多服务并没有显式设置，这就容易低估堆外内存的占用压力。当DirectBuffer的分配总量逼近这个阈值时，JVM内部会尝试调用System.gc()，主动触发一次Full GC，试图清理那些“活着但应该被回收”的DirectByteBuffer。

但这里有个坑：如果启用了-XX:+DisableExplicitGC，System.gc()就完全被禁用了。那这个保护机制就彻底失效，堆外内存只能等着被耗尽。Netty等框架内部也依赖这套机制做兜底——一旦它被禁用，而老年代又长期不触发GC，OOM几乎一定会来。

典型泄漏场景与识别信号

实际工作中的泄漏案例，往往不是代码里忘记调release()，而是生命周期管理失控了。典型的场景包括：Netty中ByteBuf跨ChannelHandler传递时没有retain()/release()配对，尤其是异常分支里release被遗漏；Reactor链中onErrorDropped日志频繁出现，说明Flux异步流中断后资源未被清理。这些都是非常常见的陷阱。

识别信号也不难抓。如果你通过jstat -gc观察，会发现YGC非常频繁，但OU（老年代使用量）却在缓慢上涨；同时用NMT（Native Memory Tracking）查看，Internal/Direct的占用也在持续攀升。如果OOM的堆栈里出现io.netty.buffer.*或ja va.nio.DirectByteBuffer，并且报错信息明确写着“used: xxx, limit: yyy”，那基本就锁定了。

排查与加固建议

别等到OOM才动手。可以从运行态和配置两个方向同时入手。启动时开启NMT：-XX:NativeMemoryTracking=detail，然后用jcmd VM.native_memory summary实时查看Direct内存分配情况。

检查一下启动参数里有没有误加了-XX:+DisableExplicitGC。如果因为某些原因必须禁用System.gc()，那就必须严格配合-XX:MaxDirectMemorySize，并且加一套主动监控告警。

对于Spring Cloud Gateway这类Netty应用，可以考虑启用Netty自身的内存泄漏检测：-Dio.netty.leakDetectionLevel=paranoid（这条只在测试环境用，生产环境可以改为simple级别）。另外，通过jmap -histo | grep DirectByteBuffer统计实例数，结合业务流量判断是否异常增长，这也是一条很实用的排查路径。