背景

首先先明確一下線程池的主要作用是什么
線程池解決的核心問題就是資源管理問題。在并發環境下，系統不能夠確定在任意時刻中，有多少任務需要執行，有多少資源需要投入。這種不確定性將帶來以下若干問題：

頻繁申請/銷毀資源和調度資源，將帶來額外的消耗，可能會非常巨大。創建一個線程不僅會消耗內存資源，并且會增加CPU的線程的上下文切換頻繁，當線程達到一定的極限的時候CPU就只能忙的切換線程，而其他什么事情也不做了。

對資源無限申請缺少抑制手段，易引發系統資源耗盡的風險。當我們無限的去申請線程的時候就有可能產生OOM等問題

系統無法合理管理內部的資源分布，會降低系統的穩定性。比如說我們的mysql有自己的池，我們的redis也有自己的池。還比如我們使用的隊列消費也有自己的池。這也就是一種安全隔離

那就是快速的處理請求，一個人工作怎么有多個人工作快呢？這里也牽扯到一個多人合作的配合問題，也就是線程線程的切換問題，我們都知道Java語言的線程切換方式采用的是搶占式，意思就是由系統來分配資源。線程太多的時候系統就會有忙不過來的情況。

我們如果使用Java語言的話，我們來分析一下Java線程池。

Java中的ThreadPoolExecutor

理論上線程池的參數設置情況

理論必定只是理論，到真實的場景中我們的目的性是不一樣的。有的是追求快，有的時候機器資源很充足，有的是追求穩的。

所以在設置線程池的時候我們還是確定一個最后權重比較大的目標去設置。

線程池的目的我們也知道了，大概設置的基礎理論也清楚了。看看美團技術團隊給的兩個場景。

快速響應用戶請求

描述：用戶發起的實時請求，服務追求響應時間。比如說用戶要查看一個商品的信息，那么我們需要將商品維度的一系列信息如商品的價格、優惠、庫存、圖片等等聚合起來，展示給用戶。

分析：從用戶體驗角度看，這個結果響應的越快越好，如果一個頁面半天都刷不出，用戶可能就放棄查看這個商品了。而面向用戶的功能聚合通常非常復雜，伴隨著調用與調用之間的級聯、多級級聯等情況，業務開發同學往往會選擇使用線程池這種簡單的方式，將調用封裝成任務并行的執行，縮短總體響應時間。另外，使用線程池也是有考量的，這種場景最重要的就是獲取最大的響應速度去滿足用戶，所以應該不設置隊列去緩沖并發任務，調高corePoolSize和maxPoolSize去盡可能創造多的線程快速執行任務。

總結：將核心線程數和最大線程數設置到最大。這里的最大也就是我們在不影響其他接口或業務的情況下，還有就是機器資源OK的情況下。現在我們的機器都是分布式，在CPU或內存超過某一個閥值的時候就會自動擴容彈機器。還有就是隊列的使用，也就是看你用戶的峰值會有多少，設置一個有界隊列當突然流量，比如100個同時請求，這個時候我們的系統最大承受能力是80個線程數，哪我們就設置個核心線程數設置的是20個，那么我們就搞100。個大小容量的隊列。然后避過這個高峰我們的線程繼續去消費。但是在我們目前這種場景是不設置隊列的。設置位0，因為用戶對等待是零容忍的。

快速處理批量任務

描述：離線的大量計算任務，需要快速執行。比如說，統計某個報表，需要計算出全國各個門店中有哪些商品有某種屬性，用于后續營銷策略的分析，那么我們需要查詢全國所有門店中的所有商品，并且記錄具有某屬性的商品，然后快速生成報表。

分析：這種場景需要執行大量的任務，我們也會希望任務執行的越快越好。這種情況下，也應該使用多線程策略，并行計算。但與響應速度優先的場景區別在于，這類場景任務量巨大，并不需要瞬時的完成，而是關注如何使用有限的資源，盡可能在單位時間內處理更多的任務，也就是吞吐量優先的問題。所以應該設置隊列去緩沖并發任務，調整合適的corePoolSize去設置處理任務的線程數。在這里，設置的線程數過多可能還會引發線程上下文切換頻繁的問題，也會降低處理任務的速度，降低吞吐量。

總結：這里的話我們會看到這個是一個穩定的請求過程，不會出現突然的猛增等情況，所以我個人認為在機器資源充分的情況下可以不設置隊列，但是就如上文所說，盡量多的并發充分利用資源，所以說這里的話可以使用隊列做一個臨時緩沖做準備的地方，那我的理解就是，機器資源只有那么多設置的核心線程數和最大線程數不能滿足這些大量的請求，但是我又不想讓這些請求被拒絕，所以我開個緩沖隊列來進行緩沖消費。

總結

線程池的作用

線程池理論參數設置參考

場景分析

參考

美團技術團隊-Java線程池實現原理及其在美團業務中的實踐

總結

以上是生活随笔為你收集整理的matlab 设置最大并行数_浅析线程池参数设置的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。