引言

大家好，我是你們的朋友小米！今天給大家?guī)硪黄P(guān)于Java線程池的面試題分析，希望通過這個故事讓大家更輕松地理解這個問題。

背景故事

在一個繁忙的互聯(lián)網(wǎng)公司，程序員小王正在準(zhǔn)備自己的社招面試。面試官看著簡歷，露出了微笑：“你知道線程池吧？”小王點點頭，心想這簡直是太簡單的知識點了！于是他信心滿滿地回答：“當(dāng)然知道！線程池是用來管理線程的，通過池化來避免頻繁創(chuàng)建銷毀線程的性能損耗。” 面試官瞇了瞇眼：“那好，假設(shè)你在一個高并發(fā)的環(huán)境中提交了大量任務(wù)，突然隊列滿了，線程池接收不到任務(wù)了，怎么辦？”

一聽這個問題，小王頓時腦袋一懵——他從來沒有遇到過這種情況！

其實，這個問題就是線程池的任務(wù)隊列滿了以后會發(fā)生什么？ 這是很多開發(fā)者可能在實際項目中都忽視的一個細(xì)節(jié)，但在面試中卻是一個常見且有挑戰(zhàn)性的問題。那么今天，我們就一起通過這個問題來探討一下，Java線程池的“深水區(qū)”到底有多深！

線程池的基礎(chǔ)回顧

圖片

在開始分析之前，咱們還是先回顧一下線程池的基本概念，以免有小伙伴對這個概念不太熟悉。

在Java中，線程池是由java.util.concurrent.Executor接口及其實現(xiàn)類ThreadPoolExecutor來實現(xiàn)的。線程池的核心作用就是將任務(wù)提交給線程池，讓線程池中的線程來執(zhí)行這些任務(wù)，而不需要每次任務(wù)都創(chuàng)建新線程。這樣就能顯著提高性能，減少資源消耗。

線程池的基本組成：

• 核心線程數(shù)： 用來執(zhí)行任務(wù)的線程數(shù)量，線程池啟動時會創(chuàng)建這個數(shù)量的線程。
• 最大線程數(shù)： 線程池中允許存在的最大線程數(shù)量，如果核心線程數(shù)不夠，且任務(wù)隊列已滿，線程池會創(chuàng)建新的線程，直到達(dá)到最大線程數(shù)。
• 任務(wù)隊列： 用來保存待執(zhí)行任務(wù)的隊列。如果線程池中的核心線程都忙時，新提交的任務(wù)會先存入這個隊列，等待線程空閑出來再執(zhí)行。
• 線程池的飽和策略： 當(dāng)線程池隊列已滿，且線程池的線程數(shù)已經(jīng)達(dá)到最大線程數(shù)時，任務(wù)應(yīng)該如何處理。這里就涉及到我們面試題的關(guān)鍵點。

線程池的飽和策略

接下來，我們來重點講解一下，當(dāng)線程池隊列滿了，且沒有空閑線程時，任務(wù)會如何處理？ 這時就需要看線程池的飽和策略（RejectedExecutionHandler）了。

Java線程池提供了四種默認(rèn)的飽和策略，分別是：

1、AbortPolicy（默認(rèn)策略）：

這是最常見也是最“直接”的策略。任務(wù)會被直接拒絕，并且拋出RejectedExecutionException異常。這種策略意味著，當(dāng)任務(wù)隊列滿了，線程池的線程數(shù)也達(dá)到了最大值，新的任務(wù)就會被拒絕并拋出異常。

舉個例子： 假設(shè)你提交了一個任務(wù)，而線程池的隊列已經(jīng)滿了，且沒有空閑線程可用，線程池會選擇拋出RejectedExecutionException。你如果沒有特別處理，就會看到這個異常，程序就會終止或進(jìn)入異常處理流程。

2、CallerRunsPolicy：

這個策略比較特別。當(dāng)線程池的任務(wù)隊列滿了并且線程池也沒有空閑線程時，提交任務(wù)的線程會自己執(zhí)行這個任務(wù)，而不是交給線程池來執(zhí)行。也就是說，調(diào)用者線程會直接執(zhí)行被拒絕的任務(wù)，而不會拋出異常。

舉個例子： 你提交了一個任務(wù)，線程池的隊列已經(jīng)滿了，且線程池的線程數(shù)也已達(dá)到最大值，線程池不會創(chuàng)建新線程，而是把任務(wù)“交給”提交任務(wù)的線程（即當(dāng)前執(zhí)行任務(wù)的線程）來執(zhí)行。

這種策略可以避免任務(wù)丟失，但可能會導(dǎo)致調(diào)用者線程的負(fù)載過高，影響程序的整體響應(yīng)能力。

3、DiscardPolicy：

采用這種策略時，如果線程池隊列滿了并且沒有空閑線程，線程池會悄悄地丟棄這個任務(wù)，且不拋出任何異常。任務(wù)就像沒提交一樣，不會被執(zhí)行。

舉個例子： 你提交了一個任務(wù)，但線程池的隊列已滿，線程池沒有空閑線程。這個任務(wù)就被丟棄，線程池會繼續(xù)執(zhí)行已有的任務(wù)。這個策略適合不要求任務(wù)一定執(zhí)行的場景，但如果丟棄任務(wù)是不可接受的，就需要慎用。

4、DiscardOldestPolicy：

這種策略會丟棄隊列中最舊的任務(wù)，并嘗試提交當(dāng)前任務(wù)。也就是說，線程池會拋棄最早提交的任務(wù)，以便為新的任務(wù)騰出位置。

舉個例子： 你提交了一個任務(wù)，線程池隊列已滿，且沒有空閑線程。線程池會刪除隊列中最舊的任務(wù)（即已經(jīng)排隊很久但還未執(zhí)行的任務(wù)），然后嘗試把當(dāng)前提交的任務(wù)放入隊列中。

如何選擇合適的飽和策略？

選擇合適的飽和策略需要結(jié)合業(yè)務(wù)場景。對于一些對任務(wù)執(zhí)行時間有嚴(yán)格要求的業(yè)務(wù)，丟棄任務(wù)顯然不可取，應(yīng)該選擇CallerRunsPolicy策略，讓任務(wù)交給調(diào)用者線程執(zhí)行。而對于一些可以容忍丟棄任務(wù)的場景，可以選擇DiscardPolicy或者DiscardOldestPolicy。

總結(jié)一下：

• AbortPolicy：任務(wù)拒絕，拋出異常。
• CallerRunsPolicy：任務(wù)交給提交任務(wù)的線程執(zhí)行。
• DiscardPolicy：丟棄任務(wù)，不拋異常。
• DiscardOldestPolicy：丟棄最舊的任務(wù)，嘗試提交新任務(wù)。

如何在代碼中設(shè)置線程池的飽和策略？

創(chuàng)建線程池時，我們可以通過ThreadPoolExecutor構(gòu)造方法中的參數(shù)來指定線程池的飽和策略：

圖片

在這個構(gòu)造方法中，AbortPolicy就是默認(rèn)的飽和策略。如果你想使用其他的策略，可以將其替換為CallerRunsPolicy、DiscardPolicy、DiscardOldestPolicy。

面試官的回答

回到小王的面試場景，面試官問完這個問題后，看到小王略顯慌張的表情，笑著說道：“其實，線程池的飽和策略是非常重要的，很多開發(fā)者在高并發(fā)的場景下往往忽視了這一點，導(dǎo)致任務(wù)的丟失或者線程池的異常行為。所以，在選擇線程池的飽和策略時，我們一定要根據(jù)具體的業(yè)務(wù)需求來決定，而不是盲目使用默認(rèn)的策略。”

小王松了一口氣：“原來如此，之前我并沒有考慮過這個細(xì)節(jié)，謝謝您的解答！”

面試官點點頭：“好的，你已經(jīng)掌握了線程池的基本知識，接下來我們繼續(xù)……”

END

線程池的飽和策略雖然是一個常見的面試題，但很多開發(fā)者在實際工作中可能并沒有遇到過這樣的情形，或者并沒有深刻理解它的作用。希望通過今天的分析，大家能對這個問題有更清晰的認(rèn)識。在面試時，如果遇到類似的問題，也能快速應(yīng)答！