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，您可能会获得更多有关其工作原理的详细信息。
