where memory is allocate outside of Java heap. gc

本文探讨了JDK中DirectByteBuffer的内存分配问题及其可能导致的延迟回收情况。文章指出了现有实现下DirectByteBuffer所分配的内存只有在其被垃圾回收时才会被释放,并讨论了使用sun.misc.Unsafe类直接管理内存的可能性及注意事项。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

JDK provides abillity to allocate so-called direct ByteBuffers, where memory is allocate outside of Java heap. This can be beneficial since this memory is not touched by garbage collector, and as such does not contribute to GC overhead: this is a very useful for property for long-living things like caches.

However, there is one critical problem with existing implementation: underlying memory is only allocated asynchronously when the owning ByteBuffer is garbage-collected; there is no way to force early deallocation. This can be problematic since GC cycle itself is not influenced by handling of ByteBuffers, and given that ByteBuffers are likely to reside in Old Generation memory area, it is possible that GC is called hours after ByteBuffer is no longer in use.

But in theory it should be possible to use sun.misc.Unsafe methods (freeMemory, allocateMemory) directly: this is what JDK itself uses for allocating/deallocating native memory. Looking at code, one potential concern I see is possibility of double-freeing of memory -- so I would want to make sure that state would be properly cleaned.

Can anyone point me to code that does this? Ideally would want to use this instead of JNA.

NOTE: I saw this question which is sort of related.

Looks like the answers pointed out are good way to go: here is code example from Elastic Search that uses the idea. Thanks everyon!

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值