前言

Tomcat/Jetty 是目前比較流行的 Web 容器，兩者接受請求之後都會轉交給執行緒池處理，這樣可以有效提高處理的能力與併發度。JDK 提高完整執行緒池實現，但是 Tomcat/Jetty 都沒有直接使用。Jetty 採用自研方案，內部實現 QueuedThreadPool 執行緒池元件，而 Tomcat 採用擴充套件方案，踩在 JDK 執行緒池的肩膀上，擴充套件 JDK 原生執行緒池。

JDK 原生執行緒池可以說功能比較完善，使用也比較簡單，那為何 Tomcat/Jetty 卻不選擇這個方案，反而自己去動手實現那？

JDK 執行緒池

通常我們可以將執行的任務分為兩類：

• cpu 密集型任務
  
• io 密集型任務

cpu 密集型任務，需要執行緒長時間進行的複雜的運算，這種型別的任務需要少建立執行緒，過多的執行緒將會頻繁引起上文切換，降低任務處理處理速度。

而 io 密集型任務，由於執行緒並不是一直在執行，可能大部分時間在等待 IO 讀取/寫入資料，增加執行緒數量可以提高併發度，儘可能多處理任務。

JDK 原生執行緒池工作流程如下：

詳情可以檢視 一文教你安全的關閉執行緒池,上圖假設使用 LinkedBlockingQueue。

靈魂拷問:上述流程是否記錯過？在很長一段時間內，我都認為執行緒數量到達最大執行緒數，才放入佇列中。￣□￣｜｜

上圖中可以發現只要執行緒池執行緒數量大於核心執行緒數，就會先將任務加入到任務佇列中，只有任務佇列加入失敗，才會再新建執行緒。也就是說原生執行緒池佇列未滿之前，最多隻有核心執行緒數量執行緒。

這種策略顯然比較適合處理 cpu 密集型任務，但是對於 io 密集型任務，如資料庫查詢，rpc 請求呼叫等，就不是很友好了。

由於 Tomcat/Jetty 需要處理大量客戶端請求任務，如果採用原生執行緒池，一旦接受請求數量大於執行緒池核心執行緒數，這些請求就會被放入到佇列中，等待核心執行緒處理。這樣做顯然降低這些請求總體處理速度，所以兩者都沒采用 JDK 原生執行緒池。

解決上面的辦法可以像 Jetty 自己實現執行緒池元件，這樣就可以更加適配內部邏輯，不過開發難度比較大，另一種就像 Tomcat 一樣，擴充套件原生 JDK 執行緒池，實現比較簡單。

下面主要以 Tomcat 擴充套件執行緒池，講講其實現原理。

擴充套件執行緒池

首先我們從 JDK 執行緒池原始碼出發，檢視如何這個基礎上擴充套件。

可以看到執行緒池流程主要分為三步，第二步根據 queue#offer 方法返回結果，判斷是否需要新建執行緒。

JDK 原生佇列型別 LinkedBlockingQueue, SynchronousQueue，兩者實現邏輯不盡相同。

LinkedBlockingQueue

offer 方法內部將會根據佇列是否已滿作為判斷條件。若佇列已滿，返回 false，若佇列未滿，則將任務加入佇列中，且返回 true。

SynchronousQueue

這個佇列比較特殊，內部不會儲存任何資料。若有執行緒將任務放入其中將會被阻塞，直到其他執行緒將任務取出。反之，若無其他執行緒將任務放入其中，該佇列取任務的方法也將會被阻塞，直到其他執行緒將任務放入。

對於 offer 方法來說，若有其他執行緒正在被取方法阻塞，該方法將會返回 true。反之，offer 方法將會返回 false。

所以若想實現適合 io 密集型任務執行緒池，即優先新建執行緒處理任務，關鍵在於 queue#offer 方法。可以重寫該方法內部邏輯，只要當前執行緒池數量小於最大執行緒數，該方法返回 false，執行緒池新建執行緒處理。

當然上述實現邏輯比較糙，下面我們就從 Tomcat 原始碼檢視其實現邏輯。

Tomcat 擴充套件執行緒池

Tomcat 擴充套件執行緒池直接繼承 JDK 執行緒池 java.util.concurrent.ThreadPoolExecutor，重寫部分方法的邏輯。另外還實現了 TaskQueue，直接繼承 LinkedBlockingQueue，重寫 offer 方法。

首先檢視 Tomcat 執行緒池的使用方法。

可以看到 Tomcat 執行緒池使用方法與普通的執行緒池差不太多。

接著我們檢視一下 Tomcat 執行緒池核心方法 execute 的邏輯。

execute 方法邏輯比較簡單，任務核心還是交給 Java 原生執行緒池處理。這裡主要增加一個重試策略，如果原生執行緒池執行拒絕策略的情況，丟擲 RejectedExecutionException 異常。這裡將會捕獲，然後重新再次嘗試將任務加入到 TaskQueue ，盡最大可能執行任務。

這裡需要注意 submittedCount 變數。這是 Tomcat 執行緒池內部一個重要的引數，它是一個 AtomicInteger 變數，將會實時統計已經提交到執行緒池中，但還沒有執行結束的任務。也就是說 submittedCount 等於執行緒池佇列中的任務數加上執行緒池工作執行緒正在執行的任務。 TaskQueue#offer 將會使用該引數實現相應的邏輯。

接著我們主要檢視 TaskQueue#offer 方法邏輯。

核心邏輯在於第三步，這裡如果 submittedCount 小於當前執行緒池執行緒數量，將會返回 false。上面我們講到 offer 方法返回 false，執行緒池將會直接建立新執行緒。

Dubbo 2.6.X 版本增加 EagerThreadPool，其實現原理與 Tomcat 執行緒池差不多，感興趣的小夥伴可以自行翻閱。

折衷方法

上述擴充套件方法雖然看起不是很難，但是自己實現代價可能就比較大。若不想擴充套件執行緒池執行 io 密集型任務，可以採用下面這種折衷方法。

new ThreadPoolExecutor(10, 10,
        0L, TimeUnit.MILLISECONDS,
        new LinkedBlockingQueue<Runnable>(100));

不過使用這種方式將會使 keepAliveTime 失效，執行緒一旦被建立，將會一直存在，比較浪費系統資源。

總結

JDK 實現執行緒池功能比較完善，但是比較適合執行 CPU 密集型任務，不適合 IO 密集型的任務。對於 IO 密集型任務可以間接通過設定執行緒池引數方式做到。

歡迎關注我的公眾號：程式通事，獲得日常乾貨推送。如果您對我的專題內容感興趣，也可以關注我的部落格：studyidea.cn

相關推薦