DirectByteBuffer未被及时回收导致堆外内存无法释放，因其依赖GC触发Cleaner异步清理，而强引用（如静态缓存、ThreadLocal持有）会阻止其进入GC周期；需用jmap -histo查实例数、NMT跟踪内存变化、GC日志确认Cleaner执行，并优先通过对象池复用和合理设置-XX:MaxDirectMemorySize从源头控制。
直接内存（堆外内存）oom 的核心问题，往往不是“没触发 full gc”，而是directbytebuffer 对象本身未被及时回收，导致底层堆外内存长期无法释放。因为 directbytebuffer 的清理依赖其内部 cleaner 机制，而 cleaner 的执行时机与 gc 强相关——但不等于必须靠 full gc 才能触发。
为什么“没触发 Full GC”容易被误认为原因
很多人观察到堆外内存持续上涨、jstat 显示 Full GC 很少，就断定“因为没 Full GC，所以堆外内存不释放”。其实：
- DirectByteBuffer 的 Cleaner 是在对象被 GC 回收时才入队，由一个低优先级的守护线程（
sun.misc.Cleaner）异步执行清理； - 即使只发生 Young GC，只要 DirectByteBuffer 进入老年代后被老年代 GC 回收，Cleaner 就会被触发；
- 真正卡住释放的常见原因是：DirectByteBuffer 被长生命周期对象意外强引用（如静态缓存、连接池未关闭、ThreadLocal 持有），导致它根本进不了 GC 周期。
关键排查：确认 DirectByteBuffer 是否真被 GC 了
不能只看 Full GC 次数，要验证对象是否真的被回收：
- 用
jmap -histo <pid>查看java.nio.DirectByteBuffer实例数量是否随时间增长； - 开启 Native Memory Tracking（NMT）：
-XX:NativeMemoryTracking=detail，再用jcmd <pid> VM.native_memory summary对比“direct memory”和“mapped”区域变化； - 配合
-XX:+PrintGCDetails -Xlog:gc+ref=debug（JDK9+）观察 Cleaner 相关日志，确认是否有Cleaner执行记录。
不依赖 GC 的主动释放方案
既然 Cleaner 不可控，最稳妥的方式是显式释放（JDK9+ 推荐，JDK8 可反射调用）：
- JDK9+：直接使用
Buffer#clean()（实际是jdk.internal.ref.Cleaner的封装），但需注意该方法非 public，需通过反射或封装工具类调用； - JDK8：通过反射调用
DirectByteBuffer.cleaner().clean()，例如：
public static void cleanDirectBuffer(ByteBuffer buffer) {
if (buffer == null || !buffer.isDirect()) return;
try {
Method cleanerMethod = buffer.getClass().getMethod("cleaner");
cleanerMethod.setAccessible(true);
Object cleaner = cleanerMethod.invoke(buffer);
if (cleaner != null) {
Method cleanMethod = cleaner.getClass().getMethod("clean");
cleanMethod.invoke(cleaner);
}
} catch (Exception ignored) {}
}
从源头控制：避免过度分配
比“释放”更有效的是“少分配”：
- 检查所有
allocateDirect()调用点，确认容量是否合理（比如 4MB/连接 × 1500 连接 = 6GB，远超默认限制）； - 复用 DirectByteBuffer：用对象池（如 Netty 的
PooledByteBufAllocator）管理，避免频繁创建销毁； - 设置合理上限：
-XX:MaxDirectMemorySize=512m（根据业务压测结果定），让 OOM 更早暴露问题，而不是静默泄漏。
