星期一早上到了公司，據稱產品環境拋出了最可愛的異常—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能創建總的線程數有限制。