Interviewer: how does the JVM allocate and recycle off heap memory

JVM Memory model

stay JVM The memory is divided into two large blocks , They are heap memory and off heap memory , Heap memory is JVM Memory used , And off heap memory is non JVM Memory used , Generally, it is the memory allocated to the machine .

Then the whole memory model is as follows ：

interviewer ：JVM How to allocate and recycle off heap memory is therefore JVM The only memory that can be allocated normally in is heap memory , And we know that JVM It is not recommended that developers directly operate off heap memory , Therefore, it is easy to cause memory leakage , And it is difficult to check , But in JVM You can operate and recycle off heap memory in , But it is a way that is not recommended .

How to allocate off heap memory

So how to allocate memory outside the heap in heap memory ？

stay Java There are two ways to allocate off heap memory , Namely ByteBuffer#allocateDirect and Unsafe#allocateMemory.

Maybe the first one will often be used , This is a Java NIO Provides a class for allocating memory , This method is often used to allocate memory when doing network development , And the second way is Unsafe The way , We know Unsafe Is an unsafe class , This class is provided for developers to operate the lowest level data , similar C perhaps C++ How to operate memory directly , Therefore, it is not recommended to use , If this class is used to allocate memory but not recycled in time, it is easy to cause memory leakage .

The first way ：ByteBuffer#allocateDirect

This class allocates memory in the following way ：

// Distribute 10M Of memory
ByteBuffer byteBuffer = ByteBuffer.allocateDirect(10 * 1024 * 1024);

The second way ：Unsafe#allocateMemory

public class Test {
 private static Unsafe unsafe = null;

 public static void main(String[] args) throws NoSuchFieldException, IllegalAccessException {
 // Distribute 10M Of memory
 Field getUnsafe = Unsafe.class.getDeclaredField("theUnsafe");
 getUnsafe.setAccessible(true);
 unsafe = (Unsafe)getUnsafe.get(null);
 // After allocating memory, return the address of memory
 long address = unsafe.allocateMemory(10 * 1024 * 1024);
 }
}

In this way Unsafe Classes cannot be used directly , But you can use this class through reflection , This class needs to recycle manually after allocating memory , Otherwise, the allocated memory will not be released .

How to reclaim off heap memory

Having said how to allocate memory , Then continue to learn how to reclaim off heap memory .

The first way ：Unsafe#freeMemory

There are two ways to allocate out of heap memory , The second kind Unsafe In fact, it provides an implementation of freeing off heap memory , The implementation is as follows ：

public class Test {
 private static Unsafe unsafe = null;

 public static void main(String[] args) throws NoSuchFieldException, IllegalAccessException {
 // Distribute 10M Of memory
 Field getUnsafe = Unsafe.class.getDeclaredField("theUnsafe");
 getUnsafe.setAccessible(true);
 unsafe = (Unsafe)getUnsafe.get(null);
 // After allocating memory, return the address of memory
 long address = unsafe.allocateMemory(10 * 1024 * 1024);
 // Reclaim the allocated off heap memory
 unsafe.freeMemory(address);
 }
}

stay Unsafe Provided in freeMemory To reclaim off heap memory , But the premise is that you need to know the address of the allocated off heap memory to realize the corresponding memory recycling .

This method of reclaiming out of heap memory is actually a manual reclaiming by the developer , Not by JVM Memory reclamation caused , that JVM How to recycle off heap memory ？

The second way ：JVM Reclaim off heap memory

adopt ByteBuffer#allocateDirect There is JVM In fact, there is a certain memory occupation in , The specific relationship is as follows ：

interviewer ：JVM How to allocate and recycle off heap memory when passing ByteBuffer#allocateDirect After allocating off heap memory , The address of the memory outside the heap 、 Size and other information through DirectByteBuffer Association , Then the heap memory can be associated with the off heap memory .

that Cleaner What else is it ？

understand Cleaner Need to know JVM Four quotation methods in ： Strong citation 、 Weak reference 、 Soft citation 、 Virtual reference ,Cleaner Is the implementation of virtual reference , In the picture above ReferenceQueue Is a reference queue , Will need to be recycled Cleaner Put into the queue , The implementation logic is as follows ：

• JVM perform Full GC when DirectByteBuffer To recycle , After recycling Clearner There is no reference relationship

• Next time GC when Cleaner Objects in the ReferenceQueue in , At the same time Cleaner Remove from list

• Last call unsafe#freeMemory Clear out of heap memory

Then there may be questions , Why? DirectByteBuffer  It's going to be recycled ？

First DirectByteBuffer  Is an object stored in heap memory , Since it exists in heap memory, it will happen GC promotion , That is, to be promoted to the older generation , It happens in the elderly Full GC perhaps Old GC.

Be careful

Be careful 1：

In actual use DirectByteBuffer  Avoid using up the memory , But in practice, we may not know how much extra heap memory is left , So we can JVM Through parameter control , adopt JVM Parameters  -XX:MaxDirectMemorySize  Specify the maximum size of off heap memory , When the specified maximum memory size is exceeded , Will automatically trigger once Full GC To reclaim memory .

Be careful 2：

adopt DirectByteBuffer  When allocating memory , There may be insufficient allocated memory , therefore JVM If the out of heap memory allocation is insufficient , Will also take the initiative to launch a GC, Only this time GC It's through System.gc()  Enforcement of implementation GC, But in the actual production environment, we all pass JVM Parameters  -XX:+DisableExplicitGC, No use System.gc() Of , Therefore, in the actual use process, we must pay attention to the allocation of memory , Avoid memory leaks .

author ： Tom Chen

link ：https://juejin.cn/post/7115787649910046750

source ： Rare earth digs gold