怎么解决在使用 ByteBuffer.allocateDirect 后，由于没有触发 Full GC 导致的堆外 OOM-java教程-PHP中文网

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 次数，要验证对象是否真的被回收：

OpenJDK 24

OpenJDK 24 Windows x64 官方参考实现（24+36），适合 Windows 环境进行 Java 开发、编译、运行和版本兼容性验证。

下载

用 jmap -histo <pid></pid> 查看 java.nio.DirectByteBuffer 实例数量是否随时间增长；
开启 Native Memory Tracking（NMT）：-XX:NativeMemoryTracking=detail，再用 jcmd <pid> VM.native_memory summary</pid> 对比“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) {}
}