Are Java DirectByteBuffer wrappers garbage collect

最新推荐文章于 2025-09-05 16:34:31 发布

转载最新推荐文章于 2025-09-05 16:34:31 发布 · 91 阅读

0 ·

CC 4.0 BY-SA版权

原文链接：https://my.oschina.net/u/138995/blog/213507

文章标签：

#java #python

本文探讨了Java中DirectByteBuffer的工作原理及其与垃圾回收的关系。解释了即使创建大量DirectByteBuffer实例并放弃引用，也不会导致内存溢出的情况，前提是垃圾回收器有机会进行清理。

2019独角兽企业重金招聘Python工程师标准>>>

I understand that when a directbytebuffer is allocated, its not subject to garbage collection, but what I'm wondering is if the wrapping object is garbage collected.

For example, if I allocated a new DirectByteBuffer dbb, and then duplicated(shallow copied) it using dbb.duplicate(), I'd have two wrappers around the same chunk of memory.

Are those wrappers subject to garbage collection? If I did

while(true){ DirectByteBuffer dbb2 = dbb.duplicate(); }

Would I eventually OOM myself?

In the Sun JDK, a java.nio.DirectByteBuffer—created by ByteBuffer#allocateDirect(int)—has a field of type sun.misc.Cleaner, which extends java.lang.ref.PhantomReference.

When this Cleaner (remember, a subtype of PhantomReference) gets collected and is about to move into the associated ReferenceQueue, the collection-related thread running through the nested type ReferenceHandler has a special case treatment of Cleaner instances: it downcasts and calls on Cleaner#clean(), which eventually makes its way back to calling on DirectByteBuffer$Deallocator#run(), which in turn calls on Unsafe#freeMemory(long). Wow.

It's rather circuitous, and I was surprised to not see any use of Object#finalize() in play. The Sun developers must have had their reasons for tying this in even closer to the collection and reference management subsystem.

In short, you won't run out of memory by virtue of abandoning references to DirectByteBufferinstances, so long as the garbage collector has a chance to notice the abandonment and its reference handling thread makes progress through the calls described above.

转载于:https://my.oschina.net/u/138995/blog/213507