一台Java服務器能跑多少個線程?這個問題來自一次線上報警如下圖,超過了我們的配置閾值。
圖:京東自研UMP監控分析
打出jstack文件,通過IBM Thread and Monitor Dump Analyzer for Java工具查看如下:
圖:IBM Thread and Monitor Dump Analyzer for Java
共計1661個線程,和監控數據得出的吻合。但這個數量應該是大了,我們都知道線程多了,就會有線程切換,帶來性能開銷。
當時就想到一台Java服務器到底可以跑多少個線程呢?跟什么有關系?現整理如下。
每個線程都有一個線程棧空間通過-Xss設置,查了一下我們服務器的關於jvm內存的配置
1 2 3 |
|
只有這三個,並沒有-Xss 和-XX:ThreadStackSize的配置,因此是走的默認值。
圖:JVM的默認棧大小
可以通過如下命令打印輸出默認值的大小,命令:
1 |
|
例如:
1 2 |
|
不考慮系統限制,可以通過如下公式計算,得出最大線程數量。
線程數量 =(機器本身可用內存 - JVM分配的堆內存)/ Xss的值,比如我們的容器本身大小是8G,堆大小是4096M,-Xss默認值,可以得出最大線程數量:4096個。
根據計算公式,得出如下結論:
-
結論1:jvm堆越大,系統創建的線程數量越小。
-
結論2:當-Xss的值越小,可生成線程數量越多。
我們知道操作系統分配給每個進程的內存大小是有限制的,比如32位的Windows是2G。因此操作系統對一個進程下的線程數量是有限制的,不能無限的增多。經驗值:3000-5000左右(我沒有驗證)。
剛才說的是不考慮系統限制的情況,那如果考慮系統限制呢,主要跟以下幾個參數有關系:
-
/proc/sys/kernel/pid_max 增大,線程數量增大,pid_max有最高值,超過之后不再改變,而且32,64位也不一樣
-
/proc/sys/kernel/thread-max 系統可以生成最大線程數量
-
max_user_process(ulimit -u)centos系統上才有,沒有具體研究
-
/proc/sys/vm/max_map_count 增大,數量增多
線程是非常寶貴的資源,我們要嚴格控制線程的數量,像上面我們的截圖情況,顯然線程數量過多。這個是跟我們自己配置了fixed大小的線程池有關系。京東有自己的rpc框架jsf,里面可以針對每個服務端口設置線程大小。