DirectByteBuffer不使用旧的Java终结器。相反，它使用内部sun.misc.CleanerAPI。它创建一个新线程并存储PhantomReference到每个DirectByteBuffer创建的线程中（除了重复和切片指的是主缓冲区）。当DirectByteBuffer变成
幻影可到达的
（也就是说，不再存在对字节缓冲区的强引用，软引用或弱引用）并且垃圾回收器看到了这一点时，它将此缓冲区添加到ReferenceQueue由Cleaner线程处理的。因此应该发生三个事件：

• DirectByteBuffer 变得幻影可达。
• 执行垃圾收集（在单独的线程中），DirectByteBuffer收集Java对象并将一个条目添加到中ReferenceQueue。
• Cleaner线程到达该条目并运行已注册的清理操作（在本例中为java.nio.DirectByteBuffer.Deallocator对象），该操作最终释放了本机内存。

因此，总的来说，您无法保证它何时被释放。如果Java堆中有足够的内存，则垃圾收集器可能很长时间没有激活。同样，即使它是幻影可达的，清理线程也可能需要一些时间才能到达此条目。可能正在忙于处理也使用了Cleaner
API的先前对象。但是请注意，部分变通方法是在JDK中实现的：如果您之前创建了新的DirectByteBuffer并且分配了太多的直接内存，则可能会显式调用垃圾回收器以强制释放先前废弃的缓冲区。有关详细信息，请参见Bits.reserveMemory()（从DirectByteBuffer构造函数调用）。

请注意，在Java-9中，内部CleanerAPI已更正并发布以供一般使用：现在是java.lang.ref.Cleaner。阅读JavaDoc，您可能会获得更多有关其工作原理的详细信息。