*Java NIO *(New Input/Output) is high-performance networking and file handling API that facilitates you to do non-blocking IO. Non-blocking I/O provides following advantages:
Concurrency: NIO enables handling multiple connections simultaneously without blocking threads, leading to better concurrency.
Asynchronous Programming: Asynchronous programming allows the application to perform other tasks while waiting for I/O operations to complete, improving overall efficiency.
Performance: Non-blocking I/O can manage more connections with fewer threads, reducing the resources required for handling concurrent requests.
One of our applications was leveraging this NIO, however it suffered from frequent ‘java.lang.OutOfMemoryError: Direct buffer memory’ when we were running in Java 11. However when we upgraded to Java 17 frequency of the occurrence of ‘java.lang.OutOfMemoryError: Direct buffer memory’ got reduced dramatically. In this post we would like to share our findings and resolution to fix this problem.
Simple Java NIO Client
To demonstrate our case, we have built a simple Spring Boot application that asynchronously uploads images. This application was leveraging Spring WebClient to connect with REST APIs. Spring WebClient underlyingly uses Java NIO technology to handle connections. Below is the source code of this application.
Java 11 NIO Memory Leak
We executed the above code in Java 11. After around 15 iterations this simple application started to throw ‘java.lang.OutOfMemoryError: Direct buffer memory’. Below is the output printed in the console.
Java 17 NIO Memory Optimization
We executed the same program in Java 17. However to run this program in Java 17, we had to make some minor modifications. Below is the revised code that runs on Java 17 that simulates the same behaviour as above.
There was an improvement in memory usage after the upgrade. Java 17 was able to handle at least twice as many NIO connections compared to Java 11. Below is the output from the console. You could see the application was able to iterate until 50 connections before it struck with ‘java.lang.OutOfMemoryError’. On the other hand Java 11 failed with ‘java.lang.OutOfMemoryError’ right after 15 connections.
Troubleshooting ‘OutOfMemoryError: Direct buffer memory’
In order to troubleshoot this problem, we leveraged the yCrash monitoring tool. This tool is capable of predicting outages before it surfaces in the production environment. Once it predicts outage in the environment, it captures 360° troubleshooting artifacts from your environment, analyses them and instantly generates a root cause analysis report. Artifacts it captures includes Garbage Collection log, Thread Dump, Heap Substitute, netstat, vmstat, iostat, top, top -H, dmesg, kernel parameters, disk usage….
You can register here and start using the free-tier of this tool.
The yCrash server analyzed the sample application and provided clear indications of issues with recommendations. Below is the incident summary report that yCrash generated for the SpringBoot WebClient application.You can notice yCrash clearly pointing out the error with necessary recommendations to remediate the problem.
Fig 1: Incident Summary Report from yCrash
Garbage Collection analysis Report
yCrash’s Garbage Collection (GC) analysis report revealed that Full GCs were consecutively running (see screenshot below). When GC runs, the entire application pauses and no transactions will be processed. Entire application would become unresponsive. We observed the unresponsiveness behaviour before the SpringBoot WebClient application crashed with OutOfMemoryError.
Fig 2: yCrash report pointing our Consecutive Full GC problem
**Logs analysis reporting OutOfMemoryError: Direct buffer memory
**yCrash’s application log analysis report revealed that application was suffering from ‘ java.lang.OutOfMemoryError: Direct buffer memory’ (see the screenshot below) which causing the application to crash
Fig 3: yCrash log report pointing java.lang.OutOfMemoryError: Direct buffer memory
**Why Java NIO application suffering from OutOfMemoryError?
**Java NIO objects are stored in the ‘Direct Buffer Memory’ region of JVM’s native memory. (Note: There are different memory regions in JVM. To learn about them, you may watch this video clip). When we executed the above two programs, we had set the Direct Buffer Memory size as 200k (i.e. -XX:MaxDirectMemorySize=200k). Under 200k Direct Buffer Memory allocation Java 11 was able to do only 15 iterations, whereas Java 17 was able to go till 50 iterations. It clearly indicates the optimization JDK team has done in Java 17 version.
Fig 4: WebClient Objects stored in Direct Memory Region of Native Region
On java 11 or below versions increase -XX:MaxDirectMemorySize
Thus if your application is leveraging Java NIO and running on Java 11 or below versions and experiencing ‘java.lang.OutOfMemoryError: Direct buffer memory’, there are couple of solutions in front of you:
Consider allocating higher Direct Buffer Memory Size.
Consider upgrading to Java 17 or higher version
Since upgrading Java 17, requires more dependencies, we increased the direct memory size to a higher value using the JVM argument -XX:MaxDirectMemorySize=1000k. After making this change, Java 11 version of the application was able to run successfully without any errors.
Conclusion
In this post we discussed ‘java.lang.OutOfMemoryError: Direct buffer memory’ caused by Java NIO in Java 11 and potential solutions to fix the same. We hope you find it helpful.
Top comments (0)