[[340904]]

本文轉載自微信公眾號「編程雜技」，作者theanarkh  。轉載本文請聯(lián)系編程雜技公眾號。

一. 方案對比

二. 其他的線程池方案

1 Libuv和nginx的線程池：線程數(shù)固定，多個線程共享一個任務隊列，沒有任務時主動掛起，不會主動退出。

2 Java：線程數(shù)運行時可以動態(tài)增加，支持空閑退出、任務過載多種處理策略，多種類型的線程池。

三. 訴求

1 提交一個js文件處理cpu型任務，這樣比較方便。而不是傳一個函數(shù)，需要經過各種序列化反序列化。

2 一個全局的線程池，可以支持多種類型的任務，類似libuv線程池

3 空閑過久的線程可以主動退出

4 任務過載可以動態(tài)擴展線程數(shù)

Nodejs線程池的調研：

1 machenjie/node-thread-pool 任務只能是代碼字符串，固定線程數(shù)，不支持空閑線程主動退出

2 Truth1984/thread_pools 任務只能是代碼字符串，沒有實現(xiàn)池化，每次創(chuàng)建一個線程，執(zhí)行完任務退出。

3 bruno303/node-workers-pool 任務只能是代碼字符串，不支持空閑退出

4 zebrajaeger/threadpool 不是線程池的概念 5

psastras/node-threadpool 沒有實現(xiàn)池化，不支持空閑退出

6 node-worker-threads-pool 周下載量20k左右，star 80。任務只能是代碼字符串，不支持空閑線程退出,固定線程數(shù)

7 threads 周下載量20k左右，star 1.1k 是對線程模塊的封裝，沒有實現(xiàn)池化能力

8 poolifier 周下載量5000左右，star 59，任務可以是js文件，一個類型的任務新建一個線程池，無法共享線程池

目前的npm包看起來還不太能滿足需求。所以決定寫一個。

四.線程池的設計需要考慮的問題

1 對于純cpu型的任務，線程數(shù)和cpu核數(shù)要相等才能達到最優(yōu)的性能，否則過多的線程引起的上下文切換反而會導致性能下降。

2 對于io型的任務，更多的線程理論上是會更好，因為可以更早地給硬盤發(fā)出命令，磁盤會優(yōu)化并持續(xù)地處理請求。當然，線程數(shù)也不是越多越好。線程過多會引起系統(tǒng)負載過高，過多上下文切換也會帶來性能的下降。

3 使用方便、簡單

整體架構(原圖[1])

五. 設計思想

1 任務隊列的設計

1.1傳統(tǒng)的線程池設計 維護一個共享的任務隊列，然后多個線程通過加鎖互斥的方式訪問該隊列，取出任務執(zhí)行。比如libuv，nginx。

1.2 我們的設計 因為我們是通過js使用nodejs線程池的，隊列也是使用js數(shù)據(jù)結構表示的。所以我們無法通過加鎖的方式互斥訪問共享隊列。這就會引起競態(tài)條件。我們使用的方式是，每個子線程維護自己的任務隊列，調度中心把任務提交給子線程，子線程自己插入所維護的隊列中。

2 線程類型和任務數(shù) 把線程分為核心線程和替補線程。分為幾個關鍵的概念：子線程當前的任務數(shù)，線程池的總任務數(shù)、核心線程數(shù)和最大線程數(shù)。在總任務數(shù)還沒有得到閾值時，所有任務都由核心線程處理，達到閾值后，會創(chuàng)建替補線程處理。

3 過載處理策略和選擇線程的策略 任務過載時，就會觸發(fā)過載處理策略。分為報錯、在主線程執(zhí)行任務、繼續(xù)交給子線程處理、刪除最老的任務。選擇線程的策略為選擇任務數(shù)最少的線程。

4 空閑策略 當沒有任務可處理的時候，線程池的線程怎么辦?

4.1 傳統(tǒng)的設計 使用條件變量機制，把線程阻塞在條件變量中，這時候操作系統(tǒng)不會調度該線程執(zhí)行，所以不會浪費cpu，等到有新任務到來時，主線程會喚醒被阻塞的子線程。不過阻塞的線程依然占據(jù)著系統(tǒng)資源，如果一直沒有任務，則浪費資源。

4.2 我們的設計 我們在js層無法像底層線程一樣使用條件變量，所以我們無法阻塞自己，這就意味著我們會一直在空轉、浪費資源。所以我們設計了線程的空閑退出時間，達到這個時間后，線程退出。盡快釋放資源。

5 如何設計用戶和線程池的通信 用戶提交任務后，如果知道任務什么時候執(zhí)行完?如何拿到執(zhí)行結果?執(zhí)行任務的時候，參數(shù)如何傳進去?

5.1 傳統(tǒng)的設計 用戶把需要處理的邏輯封裝到函數(shù)中，然后子線程中阻塞時執(zhí)行，執(zhí)行完后，同步拿到結果。

5.2 我們的設計 但是在nodejs中不太一樣。Nodejs使用work_thread模塊創(chuàng)建的線程，其實是一個和主線程獨立的事件循環(huán)。所以我們在子線程里執(zhí)行任務時，其實就相當于在執(zhí)行一個nodejs的實例，這就意味著我們可以以同步和異步的方式編程我們任務函數(shù)代碼。那么以異步方式進行處理的任務，我們如何拿到結果?為了解決以上問題，我們使用函數(shù)和Promise方案。用戶提交的任務具體表現(xiàn)為一個返回Promise的函數(shù)，使用函數(shù)是因為我們可以在處理任務(執(zhí)行函數(shù))時，把用戶自定義的參數(shù)傳進去，使用Promise可以等到用戶返回的Promise決議時，拿到返回的值，從而返回給用戶。

具體實現(xiàn)：用戶定義的邏輯test.js

module.exports = function() { 
    return new Promise((resolve, reject) => { 
        setTimeout(() => { 
            resolve({code: 0}); 
        },3000) 
    }) 
} 

子線程邏輯

const result = await require('./test')(options); 

六.成果

線程池支持的參數(shù)

1 coreThreads：核心線程數(shù)，默認10個 
2 maxThreads：最大線程數(shù)，默認50，只在支持動態(tài)擴容的情況下，該參數(shù)有效，否則該參數(shù)等于核心線程數(shù) 
3 sync：線程處理任務的模式，同步則串行處理任務，異步則并行處理任務，不同步等待用戶代碼的執(zhí)行結果 
4 discardPolicy：任務超過閾值時的處理策略，策略如下 
5 preCreate：是否預創(chuàng)建線程池 
6 maxIdleTime：線程空閑多久后自動退出 
7 pollIntervalTime：線程隔多久輪詢是否有任務需要處理 
8 maxWork：線程池最大任務數(shù)  
9 expansion：是否支持動態(tài)擴容線程，閾值是最大線程數(shù) 

支持的線程池類型

// 串行處理任務隊列里的任務 
const defaultSyncThreadPool = new SyncThreadPool(); 
// 并行處理任務隊列里的任務 
const defaultAsyncThreadPool = new AsyncThreadPool(); 
// 針對cpu密集型任務的線程池，線程數(shù)等于cpu核數(shù) 
const defaultCpuThreadPool = new CPUThreadPool(); 
// 線程數(shù)固定的線程池 
const defaultFixedThreadPool = new FixedThreadPool(); 
// 只有一個線程的線程池，任務在線程池中按序執(zhí)行 
const defaultSingleThreadPool = new SingleThreadPool(); 

七. 使用方式

方式1

nodejs子線程和nodejs主線程共享一個libuv線程池，如果在子線程中使用了libuv的線程池，會和主線程競爭libuv子線程。從而影響主線程的任務執(zhí)行。如果是純cpu的計算，則可以這樣使用。下面是這種使用方式下，nodejs的架構。

方式2

在nodejs主進程外開啟一個新的進程進行任務的處理，和主進程保持獨立，保證穩(wěn)定性的同時，也不會和主進程競爭libuv的線程。如果在子線程中需要用到libuv線程池，則使用方式2比較好。下面是方式2對應的nodejs架構。

八. 具體例子

References

[1] 原圖: https://www.processon.com/view/link/5f53a187e401fd60bde1bab1

[2] github地址: https://github.com/theanarkh/nodejs-threadpool