Java頻繁創(chuàng)建線程排查和解決方案

更新時(shí)間：2025年02月19日 14:26:17 作者：趙廣陸

文章討論了Java線程池的使用和配置,以及線程對(duì)內(nèi)存的影響,作者通過實(shí)驗(yàn)和理論分析,指出線程并不是占用JVM的內(nèi)存,而是由操作系統(tǒng)分配的本地線程,文章還提到了線程池的優(yōu)點(diǎn),如節(jié)省系統(tǒng)開銷、提高性能和方便控制

產(chǎn)生原因

因?yàn)榫幾g工具突然報(bào)錯(cuò)，需要手動(dòng)創(chuàng)建線程池，之前都是用ExecutorService直接創(chuàng)建的線程池用的封裝好的，但是阿里巴巴規(guī)范不讓用，網(wǎng)上找了個(gè)代碼copy導(dǎo)致創(chuàng)建的線程池?zé)o法關(guān)閉，暫時(shí)沒關(guān)注原因，解決的話還是使用ExecutorService的注入類，并且配置好線程池參數(shù)，而不去new線程池，也不要隨緣關(guān)閉線程池，引發(fā)了一些列知識(shí)點(diǎn)總結(jié)一下。

Java 服務(wù)器可以跑多少個(gè)線程

一臺(tái)Java服務(wù)器能跑多少個(gè)線程？這個(gè)問題來自一次線上報(bào)警如下圖，超過了我們的配置1200閾值產(chǎn)生了預(yù)警。

[告警觸發(fā):1] thread_size Alerts Firing [critical] jvm當(dāng)前活躍線程數(shù)超過1200, 當(dāng)前值:1258, 描述: 當(dāng)前活躍線程數(shù)已經(jīng)超過1200 alertname:thread_size application:oldlu:gray exported_application:msun-ecg-app-ecg hospital:/人民 instance:10.9.2.155:30260 job:jvm_exporter notify:base r_cluster:eu0 severity:critical type:jvm 開始時(shí)間:2022-11-15 15:05:01

共計(jì)1258個(gè)線程，和監(jiān)控?cái)?shù)據(jù)得出的吻合。但這個(gè)數(shù)量應(yīng)該是大了，我們都知道線程多了，就會(huì)有線程切換，帶來性能開銷。

當(dāng)時(shí)就想到一臺(tái)java服務(wù)器到底可以跑多少個(gè)線程呢？跟什么有關(guān)系？現(xiàn)整理如下。

每個(gè)線程都有一個(gè)線程?？臻g通過-Xss設(shè)置，查了一下我們服務(wù)器的關(guān)于jvm內(nèi)存的配置

-Xms4096m
-Xmx4096m
-XX:MaxPermSize=1024m1.2.3.

只有這三個(gè)，并沒有-Xss 和-XX:ThreadStackSize的配置，因此是走的默認(rèn)值。幾種JVM的默認(rèn)棧大小

可以通過如下命令打印輸出默認(rèn)值的大小，命令：jinfo -flag ThreadStackSize

[root@host-192-168-202-229 ~]#jinfo -flag ThreadStackSize 1807

-XX:ThreadStackSize=10241.2.3.

線程數(shù)量=（機(jī)器本身可用內(nèi)存-JVM分配的堆內(nèi)存）/Xss的值，比如我們的容器本身大小是8G,堆大小是4096M,走-Xss默認(rèn)值，可以得出最大線程數(shù)量：4096個(gè)。

根據(jù)計(jì)算公式，得出如下結(jié)論：

結(jié)論1：jvm堆越大，系統(tǒng)創(chuàng)建的線程數(shù)量越小。
結(jié)論2：當(dāng)-Xss的值越小，可生成線程數(shù)量越多。

我們知道操作系統(tǒng)分配給每個(gè)進(jìn)程的內(nèi)存大小是有限制的，比如32位的Windows是2G。因此操作系統(tǒng)對(duì)一個(gè)進(jìn)程下的線程數(shù)量是有限制的，不能無限的增多。經(jīng)驗(yàn)值：3000-5000左右。

剛才說的是不考慮系統(tǒng)限制的情況，那如果考慮系統(tǒng)限制呢，主要跟以下幾個(gè)參數(shù)有關(guān)系

/proc/sys/kernel/pid_max 增大，線程數(shù)量增大，pid_max有最高值，超過之后不再改變，而且32，64位也不一樣
/proc/sys/kernel/thread-max 系統(tǒng)可以生成最大線程數(shù)量
max_user_process（ulimit -u）centos系統(tǒng)上才有，沒有具體研究
/proc/sys/vm/max_map_count 增大，數(shù)量增多

線程是非常寶貴的資源，我們要嚴(yán)格控制線程的數(shù)量，象上面我們的截圖情況，顯然線程數(shù)量過多。這個(gè)是跟我們自己配置了fixed大小的線程池有關(guān)系。京東有自己的rpc框架jsf，里面可以針對(duì)每個(gè)服務(wù)端口設(shè)置線程大小。

Java 線程多影響內(nèi)存嗎

主要的影響如下：

消耗時(shí)間：線程的創(chuàng)建和銷毀都需要時(shí)間，當(dāng)有大量的線程創(chuàng)建和銷毀時(shí)，那么這些時(shí)間的消耗則比較明顯，將導(dǎo)致性能上的缺失
非常耗CPU和內(nèi)存：大量的線程創(chuàng)建、執(zhí)行和銷毀是非常耗cpu和內(nèi)存的，這樣將直接影響系統(tǒng)的吞吐量，導(dǎo)致性能急劇下降，如果內(nèi)存資源占用的比較多，還很可能造成OOM
容易導(dǎo)致GC頻繁的執(zhí)行：大量的線程的創(chuàng)建和銷毀很容易導(dǎo)致GC頻繁的執(zhí)行，從而發(fā)生內(nèi)存抖動(dòng)現(xiàn)象，而發(fā)生了內(nèi)存抖動(dòng)，對(duì)于移動(dòng)端來說，最大的影響就是造成界面卡頓

而針對(duì)上述所描述的問題，解決的辦法歸根到底就是：重用已有的線程，從而減少線程的創(chuàng)建。所以這就涉及到線程池(ExecutorService)的概念了，線程池的基本作用就是進(jìn)行線程的復(fù)用，下面將具體介紹線程池的使用

使用線程池管理線程的優(yōu)點(diǎn)

節(jié)省系統(tǒng)的開銷：線程的創(chuàng)建和銷毀由線程池維護(hù)，一個(gè)線程在完成任務(wù)后并不會(huì)立即銷毀，而是由后續(xù)的任務(wù)復(fù)用這個(gè)線程，從而減少線程的創(chuàng)建和銷毀，節(jié)約系統(tǒng)的開銷
節(jié)省時(shí)間：線程池旨在線程的復(fù)用，這就可以節(jié)約我們用以往的方式創(chuàng)建線程和銷毀所消耗的時(shí)間，減少線程頻繁調(diào)度的開銷，從而節(jié)約系統(tǒng)資源，提高系統(tǒng)吞吐量
提高性能：在執(zhí)行大量異步任務(wù)時(shí)提高了性能
方便控制：Java內(nèi)置的一套ExecutorService線程池相關(guān)的api，可以更方便的控制線程的最大并發(fā)數(shù)、線程的定時(shí)任務(wù)、單線程的順序執(zhí)行等

優(yōu)先級(jí)線程池的優(yōu)點(diǎn)

從上面我們可以得知，創(chuàng)建一個(gè)優(yōu)先級(jí)線程池非常有用，它可以在線程池中線程數(shù)量不足或系統(tǒng)資源緊張時(shí)，優(yōu)先處理我們想要先處理的任務(wù)，而優(yōu)先級(jí)低的則放到后面再處理，這極大改善了系統(tǒng)默認(rèn)線程池以FIFO方式處理任務(wù)的不靈活

java線程占多大的內(nèi)存，占哪里的內(nèi)存

說到線程，我們往往想到的是線程安全、線程池，很少會(huì)去考慮線程的內(nèi)存。

那么一個(gè)線程占用多大的內(nèi)存？占用哪里的內(nèi)存呢？

占多大的內(nèi)存

jdk1.4默認(rèn)的單個(gè)線程是占用256k的內(nèi)存
jdk1.5+默認(rèn)的單個(gè)線程是占用1M的內(nèi)存
可以通過-Xss參數(shù)設(shè)定，一般默認(rèn)就好

占哪里的內(nèi)存

這TM還用問？java線程當(dāng)然是占用jvm的內(nèi)存?。?/p>

好，我們做個(gè)實(shí)驗(yàn)，用jMeter同時(shí)并發(fā)調(diào)用java里某個(gè)接口200次，讓java里增加大約190個(gè)線程（tomcat會(huì)有駐留線程，我這是10個(gè)），看下堆內(nèi)存的情況：

從圖中看到當(dāng)線程猛增時(shí)，堆內(nèi)存也猛增，然后堆內(nèi)存會(huì)迅速下降，這是因?yàn)槎焉蟦ew了大量的對(duì)象，所以猛增，然后線程執(zhí)行完后，對(duì)象被GC了，所以下降。

上面提到堆內(nèi)存下降是因?yàn)榫€程執(zhí)行完了，GC回收了new出來的對(duì)象。但從圖中看出，堆內(nèi)存下降后線程數(shù)并沒有下降，這是為什么呢？

用過線程池的都知道，線程執(zhí)行完后并不會(huì)立即銷毀掉，會(huì)有一個(gè)保活時(shí)間，保活時(shí)間過了后才會(huì)銷毀 jdk1.8，每個(gè)線程占用1M內(nèi)存，如果是占用的堆內(nèi)存，那堆內(nèi)存應(yīng)該會(huì)增加190M左右，但從圖中看并沒有，所以線程不是占用的堆內(nèi)存空間。

實(shí)際上，java里每新起一個(gè)線程，jvm會(huì)向操作系統(tǒng)請(qǐng)求新起一個(gè)本地線程，此時(shí)操作系統(tǒng)會(huì)用空閑的內(nèi)存空間來分配這個(gè)線程。所以java里線程并不會(huì)占用 jvm的內(nèi)存空間，而是會(huì)占用操作系統(tǒng)空閑的內(nèi)存空間，所以不會(huì)引起oom，占用的是堆外內(nèi)存