在實(shí)際開發(fā)中，線程池幾乎是每個(gè) Java 后端繞不開的組件。但真正讓人困惑的往往不是怎么用線程池，而是——線程數(shù)到底該怎么配。

有人按 CPU 核數(shù)來，有人直接乘 2，還有人干脆拍腦袋設(shè)一個(gè)固定值。這些做法在某些場(chǎng)景下 “看起來能跑”，但在 IO 較多或混合型任務(wù)中，往往會(huì)帶來性能下降、請(qǐng)求堆積，甚至線程池耗盡的問題。

這篇文章主要面向 Java 后端開發(fā)者，結(jié)合常見的 IO 密集型、CPU 密集型以及混合型任務(wù)，梳理線程池線程數(shù)配置的基本思路，并給出可參考的計(jì)算方式，幫助你在不同場(chǎng)景下做出更合理的選擇。

1. 按照任務(wù)類型對(duì)線程池進(jìn)行分類

在討論線程數(shù)之前，首先需要明確一點(diǎn)：線程數(shù)的配置和任務(wù)類型是強(qiáng)相關(guān)的。 使用標(biāo)準(zhǔn)構(gòu)造器 ThreadPoolExecutor 創(chuàng)建線程池時(shí)，會(huì)涉及線程數(shù)的配置，而線程數(shù)的配置與異步任務(wù)類型是分不開的。這里將線程池的異步任務(wù)大致分為以下三類：

1. IO 密集型任務(wù)

此類任務(wù)主要是執(zhí)行 IO 操作。由于執(zhí)行 IO 操作的時(shí)間較長(zhǎng)，導(dǎo)致 CPU 的利用率不高，這類任務(wù) CPU 常處于空閑狀態(tài)。Netty 的 IO 讀寫操作為此類任務(wù)的典型例子。

2. CPU 密集型任務(wù)

此類任務(wù)主要是執(zhí)行計(jì)算任務(wù)。由于響應(yīng)時(shí)間很快，CPU 一直在運(yùn)行，這種任務(wù) CPU 的利用率很高。

3. 混合型任務(wù)

此類任務(wù)既要執(zhí)行邏輯計(jì)算，又要進(jìn)行 IO 操作（如 RPC 調(diào)用、數(shù)據(jù)庫(kù)訪問）。相對(duì)來說，由于執(zhí)行 IO 操作的耗時(shí)較長(zhǎng)（一次網(wǎng)絡(luò)往返往往在數(shù)百毫秒級(jí)別），這類任務(wù)的 CPU 利用率也不是太高。Web 服務(wù)器的 HTTP 請(qǐng)求處理操作為此類任務(wù)的典型例子。

一般情況下，針對(duì)以上不同類型的異步任務(wù)需要?jiǎng)?chuàng)建不同類型的線程池，并進(jìn)行針對(duì)性的參數(shù)配置。

2. 為 IO 密集型任務(wù)確定線程數(shù)

由于 IO 密集型任務(wù)的 CPU 使用率較低，導(dǎo)致線程空余時(shí)間很多，因此通常需要開 CPU 核心數(shù)兩倍的線程。當(dāng) IO 線程空閑時(shí)，可以啟用其他線程繼續(xù)使用 CPU，以提高 CPU 的使用率。

接下來為 IO 密集型任務(wù)創(chuàng)建了一個(gè)簡(jiǎn)單的參考線程池，具體代碼如下：

import java.util.concurrent.LinkedBlockingQueue;
import java.util.concurrent.ThreadPoolExecutor;
import java.util.concurrent.TimeUnit;

public class ThreadUtil {

    private static final int CPU_COUNT = Runtime.getRuntime().availableProcessors();

    private static final int THREAD_COUNT = Math.max(2, CPU_COUNT);
    
    private static final int QUEUE_COUNT = 128;
    
    private static final int KEEP_ALIVE_SECONDS = 30;
    
    private static class ThreadPoolExecutorDemo{
        private static final ThreadPoolExecutor EXECUTOR = new ThreadPoolExecutor(
                THREAD_COUNT,
                THREAD_COUNT,
                KEEP_ALIVE_SECONDS,
                TimeUnit.SECONDS,
                new LinkedBlockingQueue<>(QUEUE_COUNT),
                new ThreadPoolExecutor.AbortPolicy()
        );
    }
}

3. 為 CPU 密集型任務(wù)確定線程數(shù)

CPU 密集型任務(wù)也叫計(jì)算密集型任務(wù)，其特點(diǎn)是要進(jìn)行大量計(jì)算而需要消耗 CPU 資源，比如計(jì)算圓周率、對(duì)視頻進(jìn)行高清解碼等。CPU 密集型任務(wù)雖然也可以并行完成，但是并行的任務(wù)越多，花在任務(wù)切換的時(shí)間就越多 CPU 執(zhí)行任務(wù)的效率就越低，所以要最高效地利用 CPU，CPU 密集型任務(wù)并行執(zhí)行的數(shù)量應(yīng)當(dāng)?shù)扔?CPU 的核心數(shù)。

比如說 4 個(gè)核心的 CPU，通過 4 個(gè)線程并行執(zhí)行 4 個(gè) CPU 密集型任務(wù)，此時(shí)的效率是最高的。但是如果線程數(shù)遠(yuǎn)遠(yuǎn)超出 CPU 核心數(shù)量，就需要頻繁地切換線程，線程上下文切換時(shí)需要消耗時(shí)間，反而會(huì)使得任務(wù)效率下降。因此，對(duì)于 CPU 密集型的任務(wù)來說，線程數(shù)等于 CPU 數(shù)就行。

接下來為 CPU 密集型任務(wù)創(chuàng)建了一個(gè)簡(jiǎn)單的參考線程池，具體代碼如下：

import java.util.concurrent.*;

public class ThreadUtil {

    private static final int CPU_COUNT = Runtime.getRuntime().availableProcessors();

    private static final int THREAD_COUNT = CPU_COUNT;

    private static final int QUEUE_COUNT = 128;

    private static final int KEEP_ALIVE_SECONDS = 30;

    private static class ThreadPoolExecutorDemo{
        private static final ThreadPoolExecutor EXECUTOR = new ThreadPoolExecutor(
                THREAD_COUNT,
                THREAD_COUNT,
                KEEP_ALIVE_SECONDS,
                TimeUnit.SECONDS,
                new LinkedBlockingQueue<>(QUEUE_COUNT),
                new ThreadPoolExecutor.AbortPolicy()
        );
    }
}

4. 為混合型任務(wù)確定線程數(shù)

混合型任務(wù)既要執(zhí)行邏輯計(jì)算，又要進(jìn)行大量非CPU 耗時(shí)操作（如 RPC 調(diào)用、數(shù)據(jù)庫(kù)訪問、網(wǎng)絡(luò)通信等），所以混合型任務(wù) CPU 利用率不是太高，非 CPU 耗時(shí)往往是 CPU 耗時(shí)的數(shù)倍。比如在 Web 應(yīng)用處理 HTTP 請(qǐng)求處理時(shí)，一次請(qǐng)求處理會(huì)包括 DB 操作、RPC 操作、緩存操作等多種耗時(shí)操作。一般來說，一次 Web 請(qǐng)求的 CPU 計(jì)算耗時(shí)往往較少，大致在 100 - 500 毫秒，而其他耗時(shí)操作會(huì)占用 500 - 1000 毫秒，甚至更多的時(shí)間。

在為混合型任務(wù)創(chuàng)建線程池時(shí)，如何確定線程數(shù)呢？在工程實(shí)踐中，通常會(huì)通過 線程等待時(shí)間和 CPU 計(jì)算時(shí)間的比例 來估算線程數(shù)，常見的計(jì)算思路如下：

最佳線程數(shù) = （（線程等待時(shí)間+線程CPU時(shí)間）/線程CPU時(shí)間 ）* CPU核數(shù)

經(jīng)過簡(jiǎn)單的換算，以上公式可進(jìn)一步轉(zhuǎn)換為：

最佳線程數(shù)目 =（線程等待時(shí)間與線程CPU時(shí)間之比 + 1）* CPU核數(shù)

通過公式可以看出：等待時(shí)間所占比例越高，需要的線程就越多；CPU 耗時(shí)所占比例越高，需要的線程就越少。下面舉一個(gè)例子：比如在 Web 服務(wù)器處理 HTTP 請(qǐng)求時(shí)，假設(shè)平均線程 CPU 運(yùn)行時(shí)間為 100 毫秒，而線程等待時(shí)間（比如包括 DB 操作、RPC操作、緩存操作等）為 900 毫秒，如果 CPU 核數(shù)為 8，那么根據(jù)上面這個(gè)公式，估算如下：

（900ms+100ms）/100ms8= 108 = 8

經(jīng)過計(jì)算，以上案例中需要的線程數(shù)為 80。很多人認(rèn)為，線程數(shù)越高越好。那么，使用很多線程是否就一定比單線程高效呢？答案是否定的，比如大名鼎鼎的 Redis 就是單線程的，但它卻非常高效，基本操作都能達(dá)到十萬量級(jí)/秒。

由于 Redis 基本都是內(nèi)存操作，在這種情況下單線程可以高效地利用 CPU，多線程反而不是太適用。多線程適用場(chǎng)景一般是：存在相當(dāng)比例非 CPU 耗時(shí)操作，如 IO、網(wǎng)絡(luò)操作，需要盡量提高并行化比率以提升 CPU 的利用率。

總體來說，線程池線程數(shù)并不存在一個(gè)放之四海而皆準(zhǔn)的固定值。不同類型的任務(wù)，其 CPU 使用情況和等待時(shí)間差異很大，直接決定了線程數(shù)配置的側(cè)重點(diǎn)。

對(duì)于 IO 密集型、CPU 密集型以及混合型任務(wù)，本文給出的配置思路和估算公式可以作為一個(gè)起點(diǎn)，但在真實(shí)的生產(chǎn)環(huán)境中，仍然需要結(jié)合具體的業(yè)務(wù)特性、硬件條件以及壓測(cè)結(jié)果進(jìn)行不斷調(diào)整。

實(shí)際上，線程池真正“難”的地方，往往不止是線程數(shù)本身，還包括隊(duì)列大小、拒絕策略以及運(yùn)行時(shí)的監(jiān)控和調(diào)優(yōu)。這些問題在復(fù)雜系統(tǒng)中同樣容易被忽視，后續(xù)也值得單獨(dú)展開討論。

到此這篇關(guān)于淺談Java 線程池線程數(shù)怎么定的文章就介紹到這了,更多相關(guān)Java 定線程池線程數(shù) 內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評(píng)論