Java應用中線程數量的合理性評估

        相信大多使用Java的同窗曾經都遇到過由於寫多線程代碼引發的一些不正常現象，因此在使用須要多線程的地方會很當心或者刻意避免使用多線程。可是另外一方面，它可以顯著提升應用性能、改善應用結構、增長處理器執行效率。現在的主機動輒2四、32核，有性能要求的場景下多線程則成爲必選方案。其實大多數多線程編程引發的血案無非是如下幾點的問題：1）變量的讀寫無控制；2）資源競爭致使的死鎖；3）依賴執行順序。可以避免掉上面三個問題，接下來若是還要說多線程可以致使的問題，那就是性能問題了。

    雖然說多線程可以顯著提升性能增長處理器的執行效率，但不合理的使用一樣可以減慢響應速度，甚至拖垮操做系統。

這裏舉一個栗子，由一個線上報警提及：陽光明媚的一天，收到了一個報警，內容是這麼說的

，很顯然，報警閥值是2000。最初收到報警有點方：「應用有異常了！我要趕快到機器上處理下。」，關流量、查看線程數GC以及內存狀況、dump文件、重啓應用、開流量一鼓作氣。靜下來思考發現其實重點在於你設置的閥值是否合理？是否引發了性能問題？

        要評估這個數字並非一件很難的事情，先從一臺主機可以支撐多少個線程數提及。先看JVM中可以分配多少個線程，JVM運行在系統層面，其自己在受系統約束的前提下，也有幾個參數能夠控制線程的數量：     

-Xms	最小heap區域所佔大小
-Xmx	最大heap區域所佔大小
-Xss	每一個線程棧的容量大小

瞭解虛擬機運行數據區的同窗應該知道，每一個線程運行時所存放的私有數據都在虛擬機棧和本地方法棧，因此當-Xms、-Xmx定義的數字越大，就意味線程私有數據可存放的空間越小，可建立的線程越小。-Xss定義了單個線程棧的容量，那麼它越大，一樣可建立的線程數量也就越小。

        Java自身的限制肯定了之後來肯定系統層面，Linux中一樣有線程的概念，那麼這將是一個影響因素。這個線程同時會受pid的約束，由於一組同源線程的pid是一致的（比如一個Java進程下N多個線程，top -p [pid] -H 可查看），進而可知pid也將是約束之一。通常狀況下不會超過這兩個限制，接下來要說的一個參數相信大多數同窗都遇到過：ulimit -u ，這個是用戶級別的線程限制。總結下來就是這樣的：

cat /proc/sys/kernel/threads-max	thread-max
cat /proc/sys/kernel/pid_max	pid_max
ulimit -u	max_user_process

前面的命令能夠直接查出系統線程上的限制。從上面的兩個分析中得知，系統層面有線程數量的直接限制，JVM層面由控制內存從而間接限制了內存數量。

        參考以上結論並分析栗子，2000與系統限制相差甚遠；JVM給的內存非常足崩；意味着2000是這兩個層面徹底容許的線程數量。可是做爲一個默認報警閥值，它表明了絕大多數Java應用的線程閥值，因此「容許」並不意味着它必定是安全的，接下來分析業務線程。

        jstack [pid]可看到全部java線程，首先按照狀態去分析線程，優先看死鎖，再看狀態佔有率。死鎖0個，可是「WAITING 」狀態的線程居然佔到了幾乎五分之三，線程棧中均爲ThreadPoolExecutor調用，哈，都是線程池中的線程，這些線程這樣的狀態是不是業務指望呢，從線程棧中並不能獲得更多的信息，這點須要你們注意，線程池建立時必定要在threadFactory中指定線程名字，便於分析和排查問題。我這裏的栗子因爲沒有指定，因此只能抓瞎，計算了同組下線程數量最多的，發現是256*3個，剩下的有128*2等，128*2爲druid-conn組，那麼256*3從何而來，翻了翻代碼找了一個邏輯，一共三個線程池定義：newFixedThreadPool，數量爲CPUprocessors*2，bingo~ 這就對上了，這256*3均爲該邏輯生產而來，且因爲該線程池定義爲固定大小，即建立一個任務就生產一個線程直至到定義的最大限制，無釋放線程功能。因此線程總數一直處於線程池的峯值，頻繁出現報警。

        因爲線程池比較複雜，因此在定義池子的規則時比較麻煩，因此JDK提供了一系列工廠類來生成經常使用的線程池：

• newSingleThreadExecutor：建立一個單線程的線程池。這個線程池只有一個線程在工做，也就是至關於單線程串行執行全部任務。若是這個惟一的線程由於異常結束，那麼會有一個新的線程來替代它。此線程池保證全部任務的執行順序按照任務的提交順序執行。
• newFixedThreadPool：建立固定大小的線程池。每次提交一個任務就建立一個線程，直到線程達到線程池的最大大小。線程池的大小一旦達到最大值就會保持不變，若是某個線程由於執行異常而結束，那麼線程池會補充一個新線程。
• newCachedThreadPool：建立一個可緩存的線程池。若是線程池的大小超過了處理任務所須要的線程，那麼就會回收部分空閒（60秒不執行任務）的線程，當任務數增長時，此線程池又能夠智能的添加新線程來處理任務。此線程池不會對線程池大小作限制，線程池大小徹底依賴於操做系統（或者說JVM）可以建立的最大線程大小。
• newScheduledThreadPool：建立一個大小無限的線程池。此線程池支持定時以及週期性執行任務的需求。
• newSingleThreadScheduledExecutor：建立一個單線程的線程池。此線程池支持定時以及週期性執行任務的需求。

線程池的出現可以解決大量線程建立以及切換消耗系統資源的問題，可是定義的策略也關係到系統資源的利用率。雖然這個栗子並無直接影響到系統資源，可是在資源可用的狀況下維護這麼大一個線程池也未必會提升利用率。從業務上來看使用該線程池的場景天天只有個位數頻度，咱們不須要使用newFixedThreadPool使全部線程等待，進而替換爲可收縮的線程池定義：

便可解決線程過多的問題。知道了緣由以及解法，2000即變成線程數峯值，而不是常態了。

Java的線程池實現衆多，咱們這裏只討論了線程池的建立，ThreadPoolExecutor，在線程池的架構版圖中處於以下位置。

這個栗子中，咱們分析了系統層面的限制，討論了JVM層面內存配置對線程數量的影響，但具體線程數量仍是要從業務自己出發，選擇合適的線程池，可讓咱們充分利用線程池避免過早觸碰天花板。系統和JVM只能給咱們定義數量天花板，當業務所需數量觸碰到天花板時，意味着你早早就該升級機器啦！