關於JVM(JDK)，Tomcat，Linux的最大線程數問題

1、JVM（JDK）最大線程數

JVM最大建立線程數量由JVM堆內存大小、線程的Stack內存大小、系統最大可建立線程數（Java線程的實現是基於底層系統的線程機制來實現的，Windows下_beginthreadex，Linux下pthread_create）三個方面影響。具體以下：

-Xms  最小堆內存
-Xmx  最大堆內存
-Xss   設置每一個線程的堆棧大小。JDK5.0之後每一個線程堆棧大小爲1M
操做系統限制 系統最大可開線程數，主要受如下幾個參數影響

        /proc/sys/kernel/pid_max

        /proc/sys/kernel/thread-max

        max_user_process（ulimit -u） 在64位Linux系統（CentOS 6， 3G內存）下測試，發現還有一個參數是會限制線程數量：max user process（可經過ulimit –a查看，默認值1024，經過ulimit –u能夠修改此值），這個值在上面的32位Ubuntu測試環境下並沒有限制

        /proc/sys/vm/max_map_count

將threads-max，pid_max，max user process，這三個參數值都修改爲100000，-Xms，-Xmx儘可能小（128m，64m），-Xss儘可能小（64位下最小104k，可取值128k）。事先預測在這樣的測試環境下，線程數量就只會受限於測試環境的內存大小（3G），但是實際的測試結果是線程數量在達到32K（32768，建立的數量最多的時候大概是33000左右）左右時JVM是拋出警告：Attempt to allocate stack guard pages failed，而後出現OutOfMemoryError沒法建立本地線程。查看內存後發現還有不少空閒，因此應該不是內存容量的緣由。/proc/sys/vm/max_map_count的數量翻倍，從65536變爲131072，建立的線程總數量達到65000+，電腦基本要卡死（3G內存）…

簡單查了下這個參數的做用，在[8]中的描述以下：

「This file contains the maximum number of memory map areas a process may have. Memory map areas are used as a side-effect of calling malloc, directly by mmap and mprotect, and also when loading shared libraries.

While most applications need less than a thousand maps, certain programs, particularly malloc debuggers, may consume lots of them, e.g., up to one or two maps per allocation.

The default value is 65536.」

 

操做系統最大線程數限制

32位Linux系統可建立的最大pid數是32678，這個數值能夠經過/proc/sys/kernel/pid_max來作修改（修改其值爲10000：echo 10000 > /proc/sys/kernel/pid_max），可是在32系統下這個值只能改小，沒法改大。

Windows可建立的線程數量比linux可能更少。

在64位Linux系統（CentOS 6）下，還有一個參數會限制線程數量：max user process（可經過ulimit –a查看，默認值1024，經過ulimit –u能夠修改此值）

測試程序以下：

import java.util.concurrent.atomic.AtomicInteger; 
public class TestThread extends Thread { 
    private static final AtomicInteger count = new AtomicInteger(); 
    public static void main(String[] args) { 
        while (true) 
            (new TestThread()).start(); 
    } 
    @Override 
    public void run() { 
        System.out.println(count.incrementAndGet()); 
        while (true) 
            try { 
                Thread.sleep(Integer.MAX_VALUE); 
            } catch (InterruptedException e) { 
                break; 
            } 
    } 
} 

測試環境：

系統：Ubuntu 10.04 Linux Kernel 2.6 （32位）

內存：2G

JDK：1.7

測試結果：

◆ 不考慮系統限制

-Xms	-Xmx	-Xss	結果
1024m	1024m	1024k	1737
1024m	1024m	64k	26077
512m	512m	64k	31842
256m	256m	64k	31842

在建立的線程數量達到31842個時，系統中沒法建立任何線程。

由上面的測試結果能夠看出增大堆內存（-Xms，-Xmx）會減小可建立的線程數量，增大線程棧內存（-Xss，32位系統中此參數值最小爲60K）也會減小可建立的線程數量。

◆ 結合系統限制

線程數量31842的限制是是由系統能夠生成的最大線程數量決定的：/proc/sys/kernel/threads-max，可其默認值是32080。修改其值爲10000：echo 10000 > /proc/sys/kernel/threads-max，修改後的測試結果以下：

-Xms	-Xmx	-Xss	結果
256m	256m	64k	9761

這樣的話，是否是意味着能夠配置儘可能多的線程？再作修改：echo 1000000 > /proc/sys/kernel/threads-max，修改後的測試結果以下：

-Xms	-Xmx	-Xss	結果
256m	256m	64k	32279
128m	128m	64k	32279

發現線程數量在達到32279之後，再也不增加。查了一下，32位Linux系統可建立的最大pid數是32678，這個數值能夠經過/proc/sys/kernel/pid_max來作修改（修改方法同threads-max），可是在32系統下這個值只能改小，沒法更大。在threads-max必定的狀況下，修改pid_max對應的測試結果以下：

pid_max	-Xms	-Xmx	-Xss	結果
1000	128m	128m	64k	582
10000	128m	128m	64k	9507

在Windows上的狀況應該相似，不過相比Linux，Windows上可建立的線程數量可能更少。基於線程模型的服務器總要受限於這個線程數量的限制。

 

總結：

JVM中能夠生成的最大數量由JVM的堆內存大小、Thread的Stack內存大小、系統最大可建立的線程數量（Java線程的實現是基於底層系統的線程機制來實現的，Windows下_beginthreadex，Linux下pthread_create）三個方面影響。具體數量能夠根據Java進程能夠訪問的最大內存（32位系統上通常2G）、堆內存、Thread的Stack內存來估算。

一、模擬問題:

首先咱們經過下面這個測試程序 來認識這個問題：
運行的環境 （有必要說明一下，不一樣環境會有不一樣的結果）：32位 Windows XP，Sun JDK 1.6.0_18， eclipse 3.4，
測試程序：

Java代碼 

import java.util.concurrent.CountDownLatch;  
  
public class TestNativeOutOfMemoryError {  
  
    public static void main(String[] args) {  
  
        for (int i = 0;; i++) {  
            System.out.println("i = " + i);  
            new Thread(new HoldThread()).start();  
        }  
    }  
  
}  
  
class HoldThread extends Thread {  
    CountDownLatch cdl = new CountDownLatch(1);  
  
    public HoldThread() {  
        this.setDaemon(true);  
    }  
  
    public void run() {  
        try {  
            cdl.await();  
        } catch (InterruptedException e) {  
        }  
    }  
}  

不指定任何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  減少單個線程的棧大小

 

2、Tomcat最大線程數

當一個進程有 500 個線程在跑的話，那性能已是很低很低了。Tomcat 默認配置的最大請求數是 150，也就是說同時支持 150 個併發，固然了，也能夠將其改大。
當某個應用擁有 250 個以上併發的時候，應考慮應用服務器的集羣。
具體能承載多少併發，須要看硬件的配置，CPU 越多性能越高，分配給 JVM 的內存越多性能也就越高，但也會加劇 GC 的負擔。
操做系統對於進程中的線程數有必定的限制：
Windows 每一個進程中的線程數不容許超過 2000
Linux 每一個進程中的線程數不容許超過 1000
另外，在 Java 中每開啓一個線程須要耗用 1MB 的 JVM 內存空間用於做爲線程棧之用。
Tomcat的最大併發數是能夠配置的，實際運用中，最大併發數與硬件性能和CPU數量都有很大關係的。更好的硬件，更多的處理器都會使Tomcat支持更多的併發。
Tomcat 默認的 HTTP 實現是採用阻塞式的 Socket 通訊，每一個請求都須要建立一個線程處理。這種模式下的併發量受到線程數的限制，但對於 Tomcat 來講幾乎沒有 BUG 存在了。
Tomcat 還能夠配置 NIO 方式的 Socket 通訊，在性能上高於阻塞式的，每一個請求也不須要建立一個線程進行處理，併發能力比前者高。但沒有阻塞式的成熟。
這個併發能力還與應用的邏輯密切相關，若是邏輯很複雜須要大量的計算，那併發能力勢必會降低。若是每一個請求都含有不少的數據庫操做，那麼對於數據庫的性能也是很是高的。
對於單臺數據庫服務器來講，容許客戶端的鏈接數量是有限制的。
併發能力問題涉及整個系統架構和業務邏輯。
系統環境不一樣，Tomcat版本不一樣、JDK版本不一樣、以及修改的設定參數不一樣。併發量的差別仍是滿大的。
maxThreads="1000" 最大併發數 
minSpareThreads="100"///初始化時建立的線程數
maxSpareThreads="500"///一旦建立的線程超過這個值，Tomcat就會關閉再也不須要的socket線程。
acceptCount="700"// 指定當全部可使用的處理請求的線程數都被使用時，能夠放處處理隊列中的請求數，超過這個數的請求將不予處理

3、Linux最大線程數

研發環境上的Linux項目啓動報錯：Caused by: java.lang.OutOfMemoryError: unable to create new native thread

開始覺得是內存不足致使沒法建立線程，把jvm的-Xms，-Xmx的2個參數都加大一倍：-Xms2048m -Xmx2048m。把-Xss參數調小，仍是啓動失敗。應該是系統方面的限制了，這臺機器上搞了100個過tomcat進程，還有很多其餘軟件，東西比較多且雜。確認過機器的內存仍是足夠的，先排查系統參數，以後再清理垃圾資源了。

一、系統可生成最大線程數

cat /proc/sys/kernel/threads-max
這個值很大，tomcat進程的所有線程數確定沒有超過它，若是實際線程數比它大可改大（實際多是代碼問題，開啓了太多線程）。

二、進程最大線程數

ps -eLf | grep 項目名 | wc -l 查看單個項目線程數，啓動失敗的這個項目線程數通常在600左右
cat /proc/sys/vm/max_map_count
65530
這個值沒有問題，jvm的啓動參數爲-Dconfig.server.maxThreads=3000，也沒有問題

三、用戶最大進程數

ulimit -a
其中max user processes就是表示用戶的最大進程數，個人這個值很大，進程數也沒有超過它。若是超過的話，能夠修改最大進程數的配置
vi /etc/security/limits.d/90-nproc.conf
* soft nproc 1024
root soft nproc unlimited
上面能夠看除了root用戶外的全部用戶均限制爲1024，所以經過能夠註釋此行或者將值改大，保存後修改馬上生效
#* soft nproc 1024
root soft nproc unlimited

四、整個系統已用的線程或進程數

cat /proc/sys/kernel/pid_max 該值是32678（32位Linux系統可建立的最大pid數是32678），查詢當前整個系統已用的線程或進程數：pstree -p | wc -l，結果比32678稍小，問題就在這了 vim /proc/sys/kernel/pid_max,改成65535保存退出的時候報錯以下 /proc/sys/kernel/pid_max E667 Fsync failed 改爲下面方式便可： echo "65535" > /proc/sys/kernel/pid_max 不須要重啓，保存後馬上生效，重啓項目終於好了