Java out-of-heap memory

The JVM can use 2 different kinds of memory: heap memory and out -of-heap memory.

Heap memory is fully allocated and freed by the JVM, and if the program does not have a defective code that causes memory leaks, you will not encounter the Java.lang.OutOfMemoryError error.

The use of out-of-heap memory is designed to directly allocate and free memory for increased efficiency. After JDK5.0, there are 2 ways in which you can directly manipulate local memory in your code: using undisclosed unsafe and NIO packets under Bytebuffer.

for An introduction to unsafe objects and how to obtain them, refer to: http://blog.csdn.net/aitangyong/article/details/38276681

using Bytebuffer to allocate local memory is very simple, just bytebuffer.allocatedirect (10 * 1024 * 1024).

C language memory allocation and release function Malloc/free, must be corresponding, otherwise there will be a memory leak or a wild pointer illegal access. Do we need to manually release the acquired out-of-heap memory in Java?

Let's take a look at the Bytebuffer provided in NiO.

We set the maximum heap outside memory to 40M, run this code will find: The program can continue to run, will not report OutOfMemoryError. If you use-verbose:gc-xx:+printgcdetails, you will find that the program is frequently garbage collected activities. So How does Directbytebuffer release the out-of-heap memory?

We modify the startup parameters of the JVM and rerun the previous code:

Compared to the previous JVM startup parameters, the-XX:+DISABLEEXPLICITGC is added, which prevents the code from displaying the call GC. How the code shows the call to the GC, via the System.GC () function call. If this JVM startup parameter is added, then calling System.GC () in the code does not have any effect, which is equivalent to not having this line of code.

It is clear that the heap memory (including the new generation and the old age) is plentiful, but the out-of-heap memory overflows. That is to say, the recovery of NiO Direct memory relies on SYSTEM.GC (). If the direct memory in Java NIO is used in our application, use-XX:+DISABLEEXPLICITGC must be careful to have a potential memory leak risk .

      we know that Java code cannot enforce when the JVM is garbage collected, that is, the triggering of the garbage collection action, which is controlled entirely by the JVM itself, It will pick the right time to reclaim useless Java objects in the heap's memory. In the code show call System.GC (), just recommend that the JVM do garbage collection, However, it is not certain that garbage collection will be performed, it may be garbage collected, or it may not. When is the right time? In general, when the system is relatively idle (such as when there are few active threads in the JVM), there is not enough memory to be garbage collected. The fundamental contradiction in our example is that the

the recovery mechanism of Direct memory: The Direct memory is controlled by GC, for example Bytebuffer BB = bytebuffer.allocatedirect (1024), and the execution of this code consumes 1k of RAM outside the heap. The Java heap will only occupy the size of a pointer reference to an object, the 1k space outside the heap will only be recycled when the BB object is recycled, there will be a noticeable asymmetry, that is, the heap may occupy a lot, and the heap does not occupy much, resulting in the GC has not been triggered, it is easy to appear direct Memory consumes light from physical memories.

The memory allocated by direct Bytebuffer is also collected by the GC, and unlike unsafe, which is completely self-managed, the hotspot scans the direct Bytebuffer object for references when it is in GC, and if not, it also reclaims the out-of-heap memory it occupies.

Reference: http://blog.csdn.net/aitangyong/article/details/39403031

http://blog.csdn.net/aitangyong/article/category/2159887

http://blog.csdn.net/aitangyong/article/details/39323125

http://hellojava.info/?p=56

Java out-of-heap memory