directbytebuffer堆外内存回收依赖jvm自动联动机制：对象被gc回收后，cleaner（虚引用封装）触发deallocator执行unsafe.freememory。关键在及时释放强引用，避免因static缓存、threadlocal、nio channel未关闭等导致对象长期存活。

DirectByteBuffer 的堆外内存回收，靠的不是你手动 new PhantomReference 或调用 Cleaner.clean()，而是 JVM 内部一套自动联动机制。关键不在“怎么注册”，而在“怎么让对象及时被 GC”。

Cleaner 本质是 PhantomReference 的定制封装，但你不该直接操作它

• Cleaner 是 final 类，构造器私有，无法继承或替换
• 每次 new DirectByteBuffer，JDK 自动调用 Cleaner.create(this, new Deallocator(...))，绑定不可撤销
• 它内部用的是 dummyQueue（空队列），不走你创建的 ReferenceQueue；你调用 queue.poll() 或 remove() 完全无效
• clean() 方法是 package-private，外部代码无法显式触发

真正决定堆外内存是否释放的，是 DirectByteBuffer 对象本身的可达性

• 只要这个对象还被强引用着，哪怕只有一处隐式持有，Cleaner 就永远不会执行
• 常见“隐形延长生命周期”的情况包括：
  • 被 static 缓存、ConcurrentHashMap、Guava Cache 等长期持有
  • 存在 ThreadLocal 引用（尤其在线程池中复用线程时）
  • Lambda 表达式或匿名内部类意外捕获了 buffer 实例
  • 调用 slice()、duplicate()、asReadOnlyBuffer() 后，子 buffer 在 JDK 8 及更早版本中仍强引用父 buffer 的 cleaner
  • NIO Channel（如 FileChannel、SocketChannel）未 close，底层可能复用并隐式持有 buffer

如果你要自己管理非 ByteBuffer 的堆外资源（比如自定义 native buffer、GPU 显存等）

• 才需要手动套 PhantomReference + ReferenceQueue 模式
• 步骤是：分配资源 → 创建 PhantomReference 关联 ReferenceQueue → 启一个守护线程循环 queue.remove() → 在回调中调用 free() 或 close()
• Java 9+ 推荐用 jdk.internal.ref.Cleaner API，它封装了虚引用样板逻辑，更安全、不易出错
• 切记：清理逻辑必须轻量，不能含网络调用、磁盘 IO 或同步锁，否则会卡住 JVM 的 ReferenceHandler 线程

别迷信 System.gc() 或 -XX:+DisableExplicitGC

• Bits.reserveMemory() 在分配前可能触发 System.gc()，但这是 JDK 内部行为，不可控
• 显式调用 System.gc() 效果差、开销大，且在 -XX:+DisableExplicitGC 下完全失效
• 堆外 OOM 往往不是因为没 clean，而是因为 buffer 对象一直活在堆里 —— 解决引用泄漏比调优 GC 更有效

不复杂但容易忽略