手把手教你手動創建線程池

一、爲什麼要手動創建線程池?

我們之所以要手動創建線程池,是因爲 JDK 自帶的工具類所創建的線程池存在一定的弊端,那究竟存在怎麼樣的弊端呢?首先來回顧一下 JDK 中線程池框架的繼承關係:

JDK 線程池框架繼承關係圖

我們最常用的線程池實現類是ThreadPoolExecutor(紅框裏的那個),首先我們來看一下它最通用的構造方法:

/**
 * 各參數含義
 * corePoolSize    : 線程池中常駐的線程數量。核心線程數,默認情況下核心線程會一直存活,即使處於閒置狀態也不會 
 *                   受存活時間 keepAliveTime 的限制,除非將 allowCoreThreadTimeOut 設置爲 true。
 * maximumPoolSize : 線程池所能容納的最大線程數。超過這個數的線程將被阻塞。當任務隊列爲沒有設置大小的
 *				           LinkedBlockingQueue時,這個值無效。
 * keepAliveTime   : 當線程數量多於 corePoolSize 時,空閒線程的存活時長,超過這個時間就會被回收
 * unit            : keepAliveTime 的時間單位
 * workQueue       : 存放待處理任務的隊列
 * threadFactory   : 線程工廠
 * handler         : 拒絕策略,拒絕無法接收添加的任務
 */
public ThreadPoolExecutor(int corePoolSize,
                          int maximumPoolSize,
                          long keepAliveTime,
                          TimeUnit unit,
                          BlockingQueue<Runnable> workQueue,
                          ThreadFactory threadFactory,
                     	  RejectedExecutionHandler handler) { ... ... }

使用 JDK 自帶的 Executors工具類 (圖中藍色框中的那個,這是獨立於線程池繼承關係圖的工具類,類似於 Collections 和 Arrays) 可以直接創建以下種類的線程池:

  1. 線程數量固定的線程池,此方法返回 ThreadPoolExecutor

    public static ExecutorService newFixedThreadPool(int nThreads) {... ...}
    
  2. 單線程線程池,此方法返回 ThreadPoolExecutor

    public static ExecutorService newSingleThreadExecutor() {... ...}
    
  3. 可緩存線程的線程池,此方法返回 ThreadPoolExecutor

    public static ExecutorService newCachedThreadPool() {... ...}
    
  4. 執行定時任務的線程池,此方法返回 ScheduledThreadPoolExecutor

    public static ScheduledExecutorService newScheduledThreadPool(int corePoolSize) {... ...}
    
  5. 可以拆分執行子任務的線程池,此方法返回 ForkJoinPool

    public static ExecutorService newWorkStealingPool() {... ...}
    

JDK 自帶工具類創建的線程池存在的問題

直接使用這些線程池雖然很方便,但是存在兩個比較大的問題:

  1. 有的線程池可以無限添加任務或線程,容易導致 OOM;

    就拿我們最常用FixedThreadPoolCachedThreadPool來說,前者的詳細創建方法如下:

    public static ExecutorService newFixedThreadPool(int nThreads) {
    	return new ThreadPoolExecutor(nThreads, nThreads,
                                    0L, TimeUnit.MILLISECONDS,
                                    new LinkedBlockingQueue<Runnable>());
    }
    

    可見其任務隊列用的是LinkedBlockingQueue,且沒有指定容量,相當於無界隊列,這種情況下就可以添加大量的任務,甚至達到Integer.MAX_VALUE的數量級,如果任務大量堆積,可能會導致 OOM。

    CachedThreadPool的創建方法如下:

    public static ExecutorService newCachedThreadPool() {
    	return new ThreadPoolExecutor(0, Integer.MAX_VALUE,
                                    60L, TimeUnit.SECONDS,
                                    new SynchronousQueue<Runnable>());
    }
    

    這個雖然使用了有界隊列SynchronousQueue,但是最大線程數設置成了Integer.MAX_VALUE,這就意味着可以創建大量的線程,也有可能導致 OOM。

  2. 還有一個問題就是這些線程池的線程都是使用 JDK 自帶的線程工廠 (ThreadFactory)創建的,線程名稱都是類似pool-1-thread-1的形式,第一個數字是線程池編號,第二個數字是線程編號,這樣很不利於系統異常時排查問題。

如果你安裝了“阿里編碼規約”的插件,在使用Executors創建線程池時會出現以下警告信息:

在這裏插入圖片描述

阿里編碼規約的警告信息

爲避免這些問題,我們最好還是手動創建線程池。

二、 如何手動創建線程池

2.1 定製線程數量

首先要說明一點,定製線程池的線程數並不是多麼高深的學問,也不是說一旦線程數設定不合理,你的程序就無法運行,而是要儘量避免以下兩種極端條件:

  1. 線程數量過大

    這會導致過多的線程競爭稀缺的 CPU 和內存資源。CPU 核心的數量和計算能力是有限的,在分配不到 CPU 執行時間的情況下,線程只能處於空閒狀態。而在JVM 中,線程本身也是對象,也會佔用內存,過多的空閒線程自然會浪費寶貴的內存空間。

  2. 線程數量過小

    線程池存在的意義,或者說併發編程的意義就是爲了“壓榨”計算機的運算能力,說白了就是別讓 CPU 閒着。如果線程數量比 CPU 核心數量還小的話,那麼必定有 CPU 核心將處於空閒狀態,這是極大的浪費。

所以在實際開發中我們需要根據實際的業務場景合理設定線程池的線程數量,那又如何分析業務場景呢?我們的業務場景大致可以分爲以下兩大類:

  1. CPU (計算)密集型

    這種場景需要大量的 CPU 計算,比如加密、計算 hash 等,最佳線程數爲 (CPU 核心數 + 1)。比如8核 CPU,可以把線程數設置爲 9,這樣就足夠了,因爲在 CPU 密集型的場景中,每個線程都會在比較大的負荷下工作,很少出現空閒的情況,正好每個線程對應一個 CPU 核心,然後不停地工作,這樣就實現了最優利用率。多出的一個線程起到了備胎的作用,在其他線程意外中斷時頂替上去,確保 CPU 不中斷工作。其實也大可不必這麼死板,線程數量設置爲 CPU 核心數的 1 到 2 倍都是可以接受的。

  2. I/O 密集型

    比如讀寫數據庫,讀寫文件或者網絡讀寫等場景。各種 I/O 設備 (比如磁盤)的速度是遠低於 CPU 執行速度的,所以在 I/O 密集型的場景下,線程大部分時間都在等待資源而非 CPU 時間片,這樣的話一個 CPU 核心就可以應付很多線程了,也就可以把線程數量設置大一點。線程具體數量的計算方法可以參考 Brain Goetz 的建議:

    假設有以下變量:

    • Nthreads = 線程數量
    • Ncpu = CPU 核心數
    • Ucpu = 期望的CPU 的使用率 ,因爲 CPU 可能還要執行其他任務
    • W = 線程的平均等待資源時間
    • C = 線程平均使用 CPU 的計算時間
    • W / C = 線程等待時間與計算時間的比率

    這樣爲了讓 CPU 達到期望的使用率,最優的線程數量計算公式如下:

    Nthreads = Ncpu * Ucpu ( 1 + W / C )*

CPU 核心數可以通過以下方法獲取:

int N_CPUS = Runtime.getRuntime().availableProcessors();

當然,除了 CPU,線程數量還會受到很多其他因素的影響,比如內存和數據庫連接等,需要具體問題具體分析。

2.2 使用可自定義線程名稱的線程工廠

這個就簡單多了,可以藉助大名鼎鼎的谷歌開源工具庫 Guava,首先引入如下依賴:

<!-- https://mvnrepository.com/artifact/com.google.guava/guava -->
<dependency>
  <groupId>com.google.guava</groupId>
  <artifactId>guava</artifactId>
  <version>28.2-jre</version>
</dependency>

然後我就可以使用其提供的ThreadFactoryBuilder類來創建線程工廠了,Demo 如下:

public class ThreadPoolDemo {

    // 線程數
    public static final int THREAD_POOL_SIZE = 16;

    public static void main(String[] args) throws InterruptedException {
        // 使用 ThreadFactoryBuilder 創建自定義線程名稱的 ThreadFactory
        ThreadFactory namedThreadFactory = new ThreadFactoryBuilder()
                .setNameFormat("hyn-demo-pool-%d").build();
        
        // 創建線程池,其中任務隊列需要結合實際情況設置合理的容量
        ThreadPoolExecutor executor = new ThreadPoolExecutor(THREAD_POOL_SIZE,
                THREAD_POOL_SIZE,
                0L,
                TimeUnit.MILLISECONDS,
                new LinkedBlockingQueue<>(1024),
                namedThreadFactory,
                new ThreadPoolExecutor.AbortPolicy());
        
        // 新建 1000 個任務,每個任務是打印當前線程名稱
        for (int i = 0; i < 1000; i++) {
            executor.execute(() -> System.out.println(Thread.currentThread().getName()));
        }
        // 優雅關閉線程池
        executor.shutdown();
        executor.awaitTermination(1000L, TimeUnit.SECONDS);
        // 任務執行完畢後打印"Done"
        System.out.println("Done");
    }
}

控制檯打印結果如下:

... ...
hyn-demo-pool-2
hyn-demo-pool-6
hyn-demo-pool-13
hyn-demo-pool-12
hyn-demo-pool-15
Done

可見這樣的線程名稱相比pool-1-thread-1更有辨識度,可以爲不同用途的線程池設定不同的名稱,便於系統出故障時排查問題。

三、總結

本文爲大家介紹了手動創建線程池的詳細方法,不過這些都是理論性的內容,而多線程編程是非常注重實踐的一門學問,在實際生產環境中要綜合考慮各種因素並不斷嘗試,才能實現最佳實踐。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章