JAVA NIO Memory leak

Write NIO programs often use Bytebuffer to read or write data, then use bytebuffer.allocate (capability) or bytebuffer.alloctedirect (capability) To allocate the cache? The first is to allocate JVM heap memory, which belongs to the GC jurisdiction, which is relatively slow due to the need for copying, and the second is to allocate OS local memory, which is not in GC jurisdiction, and is relatively fast because no memory copy is required.

We certainly want to choose faster, but the problem is that direct memory is not part of the GC jurisdiction, you need to figure out how this part of memory management, otherwise the memory leaks will be troublesome. There is a corresponding wrapper class Directbytebuffer in Java, which belongs to the Java class, which is recycled by GC when appropriate, and the local method is called to release the direct memory before it is reclaimed. So local memory can be recycled automatically with Directbytebuffer objects, seemingly no problem, but if the local memory is constantly allocated, heap memory is rarely used, then the JVM does not need to execute Gc,directbytebuffer objects will not be recycled, This time the heap memory is sufficient, but the local memory may have used the light, and try to allocate local memory again will appear OutOfMemoryError, the program directly crashes.

Is there a solution? Automatic release is not reliable, we can manually release local memory, grasp the initiative? Sure enough. Directbytebuffer holds a cleaner object that has a clean () method that can be used to free local memory, so we can call this method to manually free local memory when needed.

The following code and test scenarios help to understand and validate the above description.

Code Listing 1:

Package Com.stevex.app.nio;import Java.nio.bytebuffer;import Java.util.concurrent.timeunit;public class directbytebuffertest {public static void main (string[] args) throws interruptedexception{//Allocate 128MB Direct memory Bytebuffer b b = Bytebuffer.allocatedirect (1024*1024*128); TimeUnit.SECONDS.sleep (10); System.out.println ("OK");}}

Test Case 1: Set the JVM parameter-xmx100m, run an exception because if-xx:maxdirectmemorysize is not set, the default is the same as the-XMX parameter value, allocating 128M of direct memory out of bounds.

Exception in thread "main" Java.lang.OutOfMemoryError:Direct buffer Memoryat java.nio.Bits.reserveMemory (Bits.java : 658) at java.nio.directbytebuffer.<init> (directbytebuffer.java:123) at Java.nio.ByteBuffer.allocateDirect ( bytebuffer.java:306) at Com.stevex.app.nio.DirectByteBufferTest.main (Directbytebuffertest.java:8)

Test Case 2: Set JVM parameter-xmx256m, run normally, because 128M is less than 256M, is within the scope of allocation.

Ok

Test Case 3: Set JVM parameter-xmx256m-xx:maxdirectmemorysize=100m, run exception, allocate the direct memory 128M exceeds the qualified 100M.

Exception in thread "main" Java.lang.OutOfMemoryError:Direct buffer Memoryat java.nio.Bits.reserveMemory (Bits.java : 658) at java.nio.directbytebuffer.<init> (directbytebuffer.java:123) at Java.nio.ByteBuffer.allocateDirect ( bytebuffer.java:306) at Com.stevex.app.nio.DirectByteBufferTest.main (Directbytebuffertest.java:8)

Code Listing 2:

Package Com.stevex.app.nio;import Java.nio.bytebuffer;import Java.util.concurrent.timeunit;import Sun.nio.ch.directbuffer;public class Directbytebuffertest {public static void main (string[] args) throws interruptedexception{//Allocation 512MB Direct cache Bytebuffer BB = bytebuffer.allocatedirect (1024*1024*512); TimeUnit.SECONDS.sleep (10);//Clear Direct cache ((Directbuffer) BB). Cleaner (). Clean (); TimeUnit.SECONDS.sleep (10); System.out.println ("OK");}}

Test Case 4: Set the JVM parameter-xmx768m, run the program to observe the memory usage changes, will find clean () memory drops immediately, indicating that using the clean () method can effectively recover the direct cache in a timely manner.

This article is from "Power from absolute love!" "Blog, be sure to keep this provenance http://stevex.blog.51cto.com/4300375/1582209

JAVA NIO Memory leak