Unable to create new native thread - Java

I believe you have already seen this nasty message from JVM - "java.lang.OutOfMemoryError: Unable to create new native thread"

Let us have a look what causes this and what we can do to troubleshoot the issue.

Java applications are multi-threaded in nature. Even with a machine with a single core, Java runs multiple threads which share information under same JVM process. They are like workers to whom you can submit tasks to carry out. The thread concept gives pseudo-parallel nature to programs.

Every thread created inside JVM needs some memory to keep variables, control information etc. So, if application is creating so many threads that underlying operating system cannot allocate memory for, that OS level issue is thrown to application by JVM as an Out of Memory issue. The message java.lang.OutOfMemoryError: Unable to create new native thread means that the Java application has hit the limit of how many Threads it can launch.


The exact limit for native threads is very platform-dependent. For this issue to surface, following steps should be passed.


  1. A new Java thread is requested by an application running inside the JVM
  2. JVM native code proxies the request to create a new native thread to the OS
  3. The OS tries to create a new native thread which requires memory to be allocated to the thread
  4. The OS will refuse native memory allocation either because the 32-bit Java process size has depleted its memory address space – e.g. (2-4) GB process size limit has been hit – or the virtual memory of the OS has been fully depleted
  5. The java.lang.OutOfMemoryError: Unable to create new native thread error is thrown.

Example Platform Limits


The exact native thread limit is platform-dependent, for example tests on Windows, Linux and Mac OS X reveal that:

  • 64-bit Mac OS X 10.9, Java 1.7.0_45 – JVM dies after #2031 threads have been created
  • 64-bit Ubuntu Linux, Java 1.7.0_45 – JVM dies after #31893 threads have been created
  • 64-bit Windows 7, Java 1.7.0_45 – due to a different thread model used by the OS, this error seems not to be thrown on this particular platform. On thread #250,000 the process was still alive, even though the swap file had grown to 10GB and the application was facing extreme performance issues.

Solution to the Issue



1. By pass issue by increasing thresholds at OS level. 


If limits are deliberately set to too low and actually if Java application needs to create threads more than the limit set, you can consider increasing thread limits in OS.

In Linux 

Max User Processes by typing the command

ulimit -a.

core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 95153
max locked memory (kbytes, -l) unlimited
max memory size (kbytes, -m) unlimited
open files (-n) 32768
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 0
stack size (kbytes, -s) 10240
cpu time (seconds, -t) unlimited
max user processes (-u) 1024 
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited

vi /etc/security/limits.conf  and add below

*          soft     nproc          65535
*          hard     nproc          65535
*          soft     nofile         65535
*          hard     nofile         65535

Save and Exit check the user max processes ulimit

ulimit -a

core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 95153
max locked memory (kbytes, -l) unlimited
max memory size (kbytes, -m) unlimited
open files (-n) 32768
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 0
stack size (kbytes, -s) 10240
cpu time (seconds, -t) unlimited
max user processes (-u) 65535 
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited

This setting will allow OS to create 65535 native threads (relatively high :). Put to a reasonable value ).

2. Fix the thread leak in java application


All above symptoms tells you about a serious problem in the Java application. It creates so many threads!! There is a thread leak in your code...

To identify the code point where this happens you can get a thread dump. In linux,

jstack >> thread_dump.txt

You will see what are the threads being created inside JVM at the moment dump is created. Look for a threads where you generate unnecessarily and fix the code!


Hasitha Hiranya

No comments:

Post a Comment

Instagram