java線程池配置參數(shù)包括corepoolsize、maximumpoolsize、keepalivetime、unit、workqueue、threadfactory和rejectedexecutionhandler。1.corepoolsize是核心線程數(shù)，始終存活除非設(shè)置允許超時；2.maximumpoolsize是最大線程數(shù)，決定高峰期可創(chuàng)建的線程上限；3.keepalivetime和unit控制非核心線程空閑存活時間；4.workqueue用于緩存任務(wù)，常見類型有arrayblockingqueue（有界隊列，適合任務(wù)量可控場景）、linkedblockingqueue（無界或有界隊列，適合突發(fā)任務(wù)但需防內(nèi)存溢出）、synchronousqueue（不存儲任務(wù)，適合強同步場景）、priorityblockingqueue（優(yōu)先級隊列）和delayqueue（延遲獲取任務(wù)）；5.threadfactory用于自定義線程創(chuàng)建過程，便于調(diào)試與監(jiān)控；6.rejectedexecutionhandler為拒絕策略，包括abortpolicy（拋異常）、callerrunspolicy（調(diào)用者執(zhí)行）、discardoldestpolicy（丟棄最老任務(wù)）和discardpolicy（靜默丟棄），也可自定義策略以實現(xiàn)日志記錄、告警或降級處理。合理配置需結(jié)合任務(wù)類型（cpu密集型建議corepoolsize為cpu核數(shù)+1，io密集型可根據(jù)阻塞系數(shù)調(diào)整線程數(shù)），并配合負載測試與性能監(jiān)控持續(xù)優(yōu)化。
Java多線程池的配置參數(shù)是平衡系統(tǒng)資源、響應(yīng)速度和穩(wěn)定性的關(guān)鍵，理解并合理設(shè)置它們能顯著提升應(yīng)用性能。這不僅僅是填幾個數(shù)字那么簡單，它關(guān)乎你的應(yīng)用在不同負載下的表現(xiàn)，甚至決定了它能否在高峰期穩(wěn)定運行。
多線程池的核心，ThreadPoolExecutor，其構(gòu)造函數(shù)里那幾個參數(shù)，每一個都蘊含著對系統(tǒng)行為的深遠影響。首先是corePoolSize，核心線程數(shù)。這就像你公司里的正式員工，無論活多活少，他們都在崗。這些線程創(chuàng)建后會一直存在，除非設(shè)置了allowCoreThreadTimeOut。然后是maximumPoolSize，最大線程數(shù)，這代表了你的公司在業(yè)務(wù)高峰期能雇傭的臨時工加上正式員工的總數(shù)。當核心線程都在忙，并且工作隊列也滿了的時候，線程池才會創(chuàng)建新的非核心線程，直到達到這個上限。
接著是keepAliveTime和unit，非核心線程的空閑存活時間。當線程池中的線程數(shù)量超過corePoolSize，且這些非核心線程在keepAliveTime時間內(nèi)沒有任務(wù)可執(zhí)行時，它們就會被終止，回收資源。這很像臨時工，活干完了就讓他們回家，節(jié)省開支。
立即學(xué)習(xí)“Java免費學(xué)習(xí)筆記（深入）”；
workQueue，工作隊列，這是線程池最關(guān)鍵的一個環(huán)節(jié)。當提交的任務(wù)數(shù)超過corePoolSize時，多余的任務(wù)會先被放入這個隊列中等待。它的選擇直接影響到線程池的行為模式：是任務(wù)先入隊等待，還是先創(chuàng)建新線程？不同的隊列類型有不同的特性，比如有界隊列和無界隊列，這會深刻影響系統(tǒng)的內(nèi)存占用和任務(wù)拒絕策略的觸發(fā)時機。
threadFactory，線程工廠，這通常是一個被忽視但很有用的參數(shù)。它允許你自定義如何創(chuàng)建線程，比如給線程命名，設(shè)置優(yōu)先級，或者綁定異常處理器。這對于調(diào)試和監(jiān)控來說非常方便，能讓你一眼看出是哪個線程池里的哪個任務(wù)出了問題。
最后是RejectedExecutionHandler，拒絕策略。當線程池和工作隊列都滿了，無法再接收新任務(wù)時，就會觸發(fā)這個策略。這就像你的公司實在忙不過來了，你得決定是拒絕新客戶，還是讓老客戶等，甚至讓客戶自己想辦法。這是系統(tǒng)過載時的最后一道防線，選擇不當可能導(dǎo)致任務(wù)丟失或系統(tǒng)崩潰。
如何根據(jù)業(yè)務(wù)場景選擇合適的線程池大小？
選擇合適的線程池大小，并沒有一個放之四海而皆準的公式，它更像是一門藝術(shù)，需要結(jié)合你的應(yīng)用特性、硬件資源以及預(yù)期的負載模式來權(quán)衡。我個人在實踐中，通常會從任務(wù)類型入手去思考。
如果你的任務(wù)是CPU密集型的，比如進行大量計算、數(shù)據(jù)加密解密、圖像處理等，那么線程池的核心線程數(shù)就應(yīng)該接近于你的CPU核心數(shù)。為什么呢？因為這類任務(wù)會長時間占用CPU，過多的線程反而會導(dǎo)致頻繁的上下文切換，降低整體效率。通常我會設(shè)置corePoolSize為“CPU核數(shù) + 1”，那個“+1”是為了應(yīng)對偶爾的頁缺失或少量IO操作。maximumPoolSize可以和corePoolSize保持一致，或者略大一點，因為這類任務(wù)的并發(fā)瓶頸通常不在于線程數(shù)量，而在于CPU的計算能力。工作隊列通常會選擇一個有界隊列，防止任務(wù)堆積導(dǎo)致內(nèi)存溢出。
而對于IO密集型任務(wù)，比如數(shù)據(jù)庫操作、網(wǎng)絡(luò)請求、文件讀寫等，情況就大不相同了。這類任務(wù)在執(zhí)行時會有大量的等待時間，線程在等待IO完成時并不會占用CPU。因此，你可以設(shè)置更多的線程來提高并發(fā)度，讓CPU在等待一個IO任務(wù)時可以去處理另一個任務(wù)。一個經(jīng)驗法則可以是“CPU核數(shù) * (1 + 阻塞系數(shù))”，阻塞系數(shù)通常在0.8到0.9之間。這意味著你可能需要設(shè)置一個遠大于CPU核心數(shù)的corePoolSize和maximumPoolSize。工作隊列的選擇可以更靈活，無界隊列在IO密集型場景下可以容納更多等待中的任務(wù)，但要警惕內(nèi)存消耗。
當然，這只是一個起點。在實際部署前，你還需要進行充分的負載測試和性能監(jiān)控。觀察CPU利用率、內(nèi)存使用情況、線程池隊列長度以及任務(wù)的平均響應(yīng)時間。這些數(shù)據(jù)會告訴你當前的配置是否合理，是需要增加線程數(shù)來提高吞吐量，還是減少線程數(shù)以降低資源消耗和上下文切換開銷。記住，沒有“完美”的配置，只有“最適合當前場景”的配置。
線程池中的隊列（BlockingQueue）有哪些類型，各自適用場景是什么？
線程池里的工作隊列，也就是BlockingQueue，是連接任務(wù)生產(chǎn)者和線程消費者之間的橋梁，它的選擇直接決定了任務(wù)的緩沖機制和線程池的擴容邏輯。這塊我經(jīng)常看到有人直接用默認的LinkedBlockingQueue，但其實不同的隊列類型，在特定場景下表現(xiàn)差異巨大。
首先是ArrayBlockingQueue，它是一個基于數(shù)組的有界阻塞隊列。這意味著你必須在創(chuàng)建時指定它的容量。它的優(yōu)點是內(nèi)部實現(xiàn)是數(shù)組，數(shù)據(jù)結(jié)構(gòu)相對緊湊，并且可以指定是公平（fair）還是非公平（non-fair）訪問。公平模式下，等待時間最長的線程會優(yōu)先獲取鎖，避免饑餓，但性能開銷會大一些。我通常會在需要嚴格控制任務(wù)數(shù)量，并且對內(nèi)存占用有較高要求，或者需要公平性保證的場景下使用它。比如，一個上游系統(tǒng)發(fā)送數(shù)據(jù)量非常大，但我們下游處理能力有限，用ArrayBlockingQueue可以防止任務(wù)無限堆積，從而避免OOM。
然后是LinkedBlockingQueue，它是一個基于鏈表的阻塞隊列。默認情況下，它的容量是Integer.MAX_VALUE，也就是一個幾乎無界的隊列。這使得它在處理突發(fā)大量任務(wù)時表現(xiàn)良好，因為任務(wù)可以直接入隊而無需等待線程創(chuàng)建。它的吞吐量通常比ArrayBlockingQueue高。但無界隊列的風(fēng)險在于，如果任務(wù)生產(chǎn)速度持續(xù)大于消費速度，它會無限增長，最終耗盡內(nèi)存導(dǎo)致OOM。我個人在使用時，除非明確知道任務(wù)量不會失控，或者有其他機制來限制任務(wù)提交，否則我都會給它指定一個合理的容量，把它當成一個有界隊列來用。
SynchronousQueue則是一個非常特殊的隊列，它不存儲任何元素。每次插入操作都必須等待一個對應(yīng)的移除操作，反之亦然。它更像是一個直接傳遞的通道，而不是一個存儲容器。這種隊列的特點是吞吐量極高，因為它沒有內(nèi)部存儲的開銷。它適用于那些任務(wù)提交和執(zhí)行之間需要強同步的場景，或者當線程池的maximumPoolSize被設(shè)置得很大，希望優(yōu)先創(chuàng)建新線程而不是將任務(wù)入隊時。使用SynchronousQueue時，線程池的行為更傾向于“有多少任務(wù)就創(chuàng)建多少線程（直到maximumPoolSize），而不是先排隊”。
還有PriorityBlockingQueue，一個支持優(yōu)先級的無界阻塞隊列。它會根據(jù)元素的自然順序或構(gòu)造函數(shù)中提供的Comparator來決定元素的優(yōu)先級。這在需要處理不同優(yōu)先級任務(wù)的場景下很有用，比如高優(yōu)先級的用戶請求應(yīng)該比低優(yōu)先級的后臺任務(wù)更快得到執(zhí)行。但需要注意的是，它也是無界的，同樣存在內(nèi)存溢出的風(fēng)險。
最后是DelayQueue，一個無界阻塞隊列，只有當元素的延遲時間到期時才能從隊列中獲取元素。這在實現(xiàn)定時任務(wù)調(diào)度、緩存過期等場景非常實用。
選擇隊列時，我的思考路徑通常是：首先評估任務(wù)量是否可控，如果不可控，我會傾向于有界隊列（如ArrayBlockingQueue或有界的LinkedBlockingQueue）；如果任務(wù)需要優(yōu)先級，PriorityBlockingQueue是首選；如果追求極致的吞吐量且任務(wù)是瞬時傳遞的，SynchronousQueue值得考慮。但無論哪種，都要結(jié)合實際的業(yè)務(wù)場景和預(yù)期的負載進行測試驗證。
線程池的拒絕策略（RejectedExecutionHandler）有哪些，又該如何選擇和自定義？
拒絕策略，即RejectedExecutionHandler，是線程池在資源耗盡時的最后一道防線。當線程池中的核心線程都在忙碌，工作隊列也已滿，并且當前線程數(shù)已經(jīng)達到maximumPoolSize時，新提交的任務(wù)就會被拒絕。理解并合理設(shè)置拒絕策略至關(guān)重要，它決定了你的系統(tǒng)在過載時如何優(yōu)雅地降級，而不是直接崩潰。
Java ThreadPoolExecutor 內(nèi)置了四種標準的拒絕策略：
- AbortPolicy (默認策略)：這是最粗暴但也最直接的策略。它會直接拋出RejectedExecutionException運行時異常。這意味著如果你的代碼沒有捕獲這個異常，程序可能會崩潰。我通常在對任務(wù)丟失非常敏感，且希望通過異常來明確告知調(diào)用方系統(tǒng)已過載，需要采取措施（比如限流、熔斷）的場景下使用它。
- CallerRunsPolicy：這個策略比較有趣。它不會拒絕任務(wù)，而是讓提交任務(wù)的線程（調(diào)用者線程）自己去執(zhí)行這個任務(wù)。這實際上是一種反壓機制：當線程池處理不過來時，它會把壓力傳導(dǎo)回任務(wù)提交方，從而減緩任務(wù)提交的速度。我個人比較喜歡在一些批處理或后臺服務(wù)中使用它，因為它能有效避免任務(wù)丟失，并起到一種天然的限流作用。但要注意，如果調(diào)用者線程是主線程或關(guān)鍵線程，可能會導(dǎo)致其阻塞，影響用戶體驗。
- DiscardOldestPolicy：這個策略會丟棄隊列中等待時間最久（最老）的那個任務(wù)，然后嘗試重新提交當前被拒絕的任務(wù)。它適用于那些對實時性要求較高，可以接受少量任務(wù)丟失，但希望系統(tǒng)能持續(xù)運行的場景。比如，在處理實時數(shù)據(jù)流時，偶爾丟棄一些舊數(shù)據(jù)可能比完全停止處理要好。
- DiscardPolicy：這個策略更直接，它會直接丟棄當前嘗試提交的任務(wù)，不拋出任何異常。這意味著任務(wù)會靜默地丟失。我很少直接使用它，除非是在一些對任務(wù)丟失完全不敏感的場景，比如日志記錄（但即使是日志，也希望能盡量記錄下來）。因為它缺乏反饋，一旦任務(wù)丟失，很難追蹤問題。
在實際項目中，我發(fā)現(xiàn)內(nèi)置策略往往不能完全滿足所有需求，這時候就需要自定義拒絕策略。自定義策略非常簡單，你只需要實現(xiàn)RejectedExecutionHandler接口，并重寫它的rejectedExecution方法。
例如，一個常見的自定義需求是記錄被拒絕的任務(wù)日志并發(fā)送告警。你可以這樣做：
public class CustomRejectedExecutionHandler implements RejectedExecutionHandler { @Override public void rejectedExecution(Runnable r, ThreadPoolExecutor executor) { // 記錄日志 System.err.println("Task " + r.toString() + " rejected from " + executor.toString()); // 發(fā)送告警（例如通過郵件、短信或監(jiān)控系統(tǒng)） // LogManager.getLogger().warn("Thread pool is full, task rejected: " + r.toString()); // AlertService.sendAlert("Thread pool overload!", r.toString()); // 根據(jù)業(yè)務(wù)需求，可以選擇： // 1. 拋出異常：throw new RejectedExecutionException("Task " + r.toString() + " rejected."); // 2. 將任務(wù)重新放回隊列（如果隊列允許且有空間）：executor.getQueue().offer(r); // 3. 降級處理：比如將任務(wù)放入一個降級隊列，等待后續(xù)處理或持久化到磁盤 // FallbackQueue.add(r); } }
在選擇和自定義拒絕策略時，我的核心原則是：明確你對任務(wù)丟失的容忍度，以及你希望系統(tǒng)在過載時如何表現(xiàn)。是寧愿拋異常讓系統(tǒng)停下來以便修復(fù)，還是寧愿丟棄一些任務(wù)也要保持部分服務(wù)可用？是希望將壓力傳導(dǎo)回上游，還是默默消化？這些思考決定了你最終的選擇。拒絕策略不是萬能藥，它只是系統(tǒng)過載時的一個應(yīng)急預(yù)案，真正的解決方案通常需要結(jié)合限流、熔斷、降級等更全面的架構(gòu)設(shè)計。
