解决 – java.lang.OutOfMemoryError： unable to create new native thread

一、认识问题:

首先我们通过下面这个 测试程序 来认识这个问题：

运行的环境 （有必要说明一下，不同环境会有不同的结果）：32位 Windows XP，Sun JDK 1.6.0_18， eclipse 3.4，

测试程序：

不指定任何JVM参数，eclipse中直接运行输出，看到了这位朋友了吧：

i = 5602

Exception in thread "main" java.lang.OutOfMemoryError: unable to create new native thread

at java.lang.Thread.start0(Native Method)

at java.lang.Thread.start(Thread.java:597)

at TestNativeOutOfMemoryError.main(TestNativeOutOfMemoryError.java:20)

二、分析问题：

这个异常问题本质原因是我们创建了太多的线程，而能创建的线程数是有限制的，导致了异常的发生。能创建的线程数的具体计算公式如下：

(MaxProcessMemory – JVMMemory – ReservedOsMemory) / (ThreadStackSize) = Number of threads

MaxProcessMemory 指的是一个进程的最大内存

JVMMemory JVM内存

ReservedOsMemory 保留的操作系统内存

ThreadStackSize 线程栈的大小

在java语言里， 当你创建一个线程的时候，虚拟机会在JVM内存创建一个Thread对象同时创建一个操作系统线程，而这个系统线程的内存用的不是JVMMemory，而是系统中剩下的内存(MaxProcessMemory – JVMMemory – ReservedOsMemory)。

结合上面例子我们来对公式说明一下：

MaxProcessMemory 在32位的 windows下是 2G

JVMMemory eclipse默认启动的程序内存是64M

ReservedOsMemory 一般是130M左右

ThreadStackSize 32位 JDK 1.6默认的stacksize 325K左右

公式如下：

(2*1024*1024-64*1024-130*1024)/325 = 5841

公式计算所得5841，和实践5602基本一致（有偏差是因为ReservedOsMemory不能很精确）

由公式得出结论：你给JVM内存越多，那么你能创建的线程越少，越容易发生java.lang.OutOfMemoryError: unable to create new native thread。

咦，有点背我们的常理，恩，让我们来验证一下,依旧使用上面的测试程序，加上下面的JVM参数，测试结果如下：

ThreadStackSize JVMMemory 能创建的线程数

默认的325K -Xms1024m -Xmx1024m i = 2655

默认的325K -Xms1224m -Xmx1224m i = 2072

默认的325K -Xms1324m -Xmx1324m i = 1753

默认的325K -Xms1424m -Xmx1424m i = 1435

-Xss1024k -Xms1424m -Xmx1424m i = 452

完全和公式一致。

三、解决问题：

1， 如果程序中有bug，导致创建大量不需要的线程或者线程没有及时回收，那么必须解决这个bug，修改参数是不能解决问题的。

2， 如果程序确实需要大量的线程，现有的设置不能达到要求，那么可以通过修改MaxProcessMemory，JVMMemory，ThreadStackSize这三个因素，来增加能创建的线程数：

a, MaxProcessMemory 使用64位操作系统

b, JVMMemory 减少JVMMemory的分配

c, ThreadStackSize 减小单个线程的栈大小

//—————————————————————————–华丽的分割线——————————————————————————————//

星期一早上到了公司，据称产品环境抛出了最可爱的异常—OutOfMemory, 它是这样来描述他自己的：

java.lang.OutOfMemoryError: unable to create new native thread

而且这位仁兄竟然还堂而皇之地同时出现在了3个application里面，所有应用全部遭殃。

那可爱的OOM是如何产生的呢？直接原因是创建的线程太多了，根本原因是某个地方的内存限制了。

搜罗了一下在网上找到了一个计算公式：

(MaxProcessMemory – JVMMemory – ReservedOsMemory) / (ThreadStackSize) = Number of threads

MaxProcessMemory：进程最大的寻址空间，但我想这个值应该也不会超过虚拟内存和物理内存的总和吧。关于不同系统的进程可寻址的最大空间，可参考下面表格：

Maximum Address Space Per Process
Operating System	Maximum Address Space Per Process
Redhat Linux 32 bit	2 GB
Redhat Linux 64 bit	3 GB
Windows 98/2000/NT/Me/XP	2 GB
Solaris x86 (32 bit)	4 GB
Solaris 32 bit	4 GB
Solaris 64 bit	Terabytes

JVMMemory: Heap + PermGen

ReservedOSMemory：Native
heap，JNI

便可推导出单个JVM Instance可支持的最大线程数的估计值：

(MaxProcessMemory<固定值> – Xms<初始化值，最小值> – XX:PermSize<初始化值，最小值>
– 100m<估算值>) / Xss = Number of threads<最大值>

在本地(32bit windows)试了试，可达的线程的最大值差不多就是这个数，它不受物理内存的限制，会利用虚拟内存，从任务管理器看到memory已经是5500
m左右了（开了两个jvm），我机器的物理内存是2g，也不知道这个准不准，后来还抛出了“unable
to create new native thread”的兄弟“Exception in thread "CompilerThread0" java.lang.OutOfMemoryError: requested 471336 bytes for Chunk::new. Out of swap space?“。

本地测完了后，就该轮到dev环境了，linux2.6，64bit，双核，8G（虚拟机），总的物理内存是16g。在上面整了一下，创建到了15000多个线程的时候挂掉了。此时其他application也不能创建新的线程，而且db也报错了，操作系统不能fork新的线程了。这应该是操作系统的哪里限制了新线程的创建，

· max thread，linux2.6似乎是32000

· 最大可用内存：物理内存+虚拟内存

· 配置，在linux可以限制可用资源的大小，show一下这些参数

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

为了进一步确定在linux上一个jvm因为达到了最大寻址空间OOM了，不会影响其他jvm，我在Linux做了进一步测试，一开始用Sun文档中说的最大寻址空间3G试了一下，发现根本不对，达到了3G后还是非常high地在创建新的线程。于是出动超级无敌变态的JVM初始化配置。

oracle 27408 27017 12 13:45 ? 00:00:07 /home/oracle/ias1013/FWAPP/FWDev/jdk/bin/java -server -Xmx4096m -Xms4096m -XX:+HeapDumpOnOutOfMemoryError -XX:PermSize=4096m -XX:MaxPermSize=4096m -XX:HeapDumpPath=/home/oracle/ias1013/FWAPP/FWDev/j2ee/OC4J_OOMTest/workEnv/log -Xss100m

结果在create 3379个线程后，“unable
to create new native thread”出现了，这时其他jvm都是可以create新线程的。如果按照上面公式计算，linux
64bit，2.6kernel，它的最大寻址空间肯定超过了300g，当然应该还没有达到可用内存的限制，因为其他JVM还能create新线程。

我还怀疑是不是oracle application server上的某个配置参数限制了总的线程数，影响了所有application，但我们的产品环境一个application就是一个单独的application
server。

现在基本上可以确定是操作系统哪里设置错了，我想System team的帅哥们应该把产品环境的某个参数配置错了，系统本身的影响肯定不会有了，因为产品环境上我们只create了800左右个线程，就OOM了，那应该就是配置的问题了，怀疑的参数有下面四个

max user processes (-u) 2048

virtual memory (kbytes, -v) unlimited

max memory size (kbytes, -m) unlimited

stack size (kbytes, -s) 10240

最后发现只有max user processes 和virtual memory对总的线程数有影响，我把max
user processes降到2048后，发现此时只能创建 2000左右个线程了(Xms64m,
Xss1m)，进一步地把virtual memory下调到2048000K发现能创建的就更少了1679（Xms64m,
Xss1m），而它只会对当前shell起作用，而多个application server应该是不同的shell,所以他是打酱油的。另外两个参数好像就是来做做俯卧撑的，操作系统stack size是不应该会有什么影响，我们把它上调到102400，还是可以创建2000左右的线程数（max
user processes），因为java有自己的线程模型，它的栈的大小是用Xss来控制的。Max
memory size不知道是啥东东，照理说如果是最大内存应该不会只在旁边做俯卧撑，那这个参数到底是春哥还是曾哥，查了一下man ulimit，有下面解释

-a All current limits are reported

-c The maximum size of core files created

-d The maximum size of a process data segment

-f The maximum size of files created by the shell

-l The maximum size that may be locked into memory

-m The maximum resident set size (has no effect on Linux)

-n The maximum number of open file descriptors (most systems do not allow this value to be set)

-p The pipe size in 512-byte blocks (this may not be set)

-s The maximum stack size

-t The maximum amount of cpu time in seconds

-u The maximum number of processes available to a single user

-v The maximum amount of virtual memory available to the shell

“Has no effect on Linux”就足以证明它确实只是来做做俯卧撑的。最后查出只有“max user processes”会对所有application能创建总的线程数有限制。

转：http://www.chinasb.org/archives/2011/12/4138.shtml