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

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

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

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

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

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

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

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

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

3. 混合型任務(wù)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

最新評論