jvm 不直接回收 directbytebuffer 堆外内存，而是依赖其对象被 gc 后由 cleaner 异步触发释放；cleaner 绑定自动不可干预，回收时机取决于 directbytebuffer 是否可被回收，常见阻断点包括静态引用、threadlocal 和隐式捕获。
JVM 并不直接回收 DirectByteBuffer 的堆外内存，而是靠对象生命周期与 Cleaner 的协同机制间接完成。关键在于：堆外内存的释放完全依赖 DirectByteBuffer 对象能否被及时 GC，Cleaner 只是这个过程的“自动触发器”，不是手动开关，也不提供实时性保障。
DirectByteBuffer 与 Cleaner 的绑定是自动且不可干预的
每次调用 ByteBuffer.allocateDirect()，JDK 内部会执行：
- 调用
Unsafe.allocateMemory()向操作系统申请堆外内存 - 在堆中创建
DirectByteBuffer实例（仅含元数据，极小） - 立即调用
Cleaner.create(this, new Deallocator(base, size))，将当前 buffer 绑定一个 Cleaner
这个过程无法跳过、无法替换 Cleaner 实现、也无法延迟注册。Cleaner 是 final 类，构造私有，你不能传入自定义子类或修改其行为。
Cleaner 的工作由 JVM 内部线程异步驱动
Cleaner 继承自 PhantomReference，但它不走标准虚引用流程：
- 它使用内部静态
dummyQueue，而非你创建的ReferenceQueue - 它的入队、出队、
clean()调用全部由 JVM 的ReferenceHandler线程在 GC 后统一处理 - 你调用
queue.poll()或反射强制调用clean()都无效——前者收不到，后者可能静默失败或破坏链表
真正决定回收时机的，是你对 DirectByteBuffer 引用的管理
堆外内存是否释放，99% 取决于 DirectByteBuffer 对象本身能否被 GC 掉。常见阻断点包括：
-
static字段或全局缓存（如ConcurrentHashMap）长期持有 buffer -
ThreadLocal存储未清理的 buffer，尤其在线程复用场景（如线程池） - lambda 或匿名内部类隐式捕获 buffer，延长其生命周期
- 调用
slice()、duplicate()、asReadOnlyBuffer()后，子 buffer 在 JDK 8 及更早版本中仍强引用父 buffer 的 cleaner - NIO Channel（如
FileChannel）未关闭，底层可能复用并隐式持有所关联的 buffer
安全回收的可行路径只有两个
想让堆外内存行为可预测，必须绕过 Cleaner 的被动性：
-
显式资源管理：对 Netty、RocketMQ 等框架，启用其内置池化（如
PooledByteBufAllocator），并确保buffer.release()被正确调用 -
资源约束兜底：通过
-XX:MaxDirectMemorySize设定硬上限；当Bits.reserveMemory()检测到超限时，会尝试触发System.gc()——但这只是试探，不是保障
生产环境禁止依赖 System.gc() 或反射调用 clean()。它们不可控、副作用大，且在 -XX:+DisableExplicitGC 下完全失效。
