聊聊接口最大并發處理數
今天跟大家聊聊一個 Java 界的老話題，就是怎么理解接口的最大并發處理數。
前言
生活在 2023 年的互聯網時代下，又是在國內互聯網越發內卷的背景下，相信大家面試找工作、網上學習查資料時都了解過互聯網系統設計三高指標，那就是高并發、高性能、高可用。本文主要講高并發、高性能相關。本質上高性能也是為了給高并發鋪平道路。而高并發設計中一部分就是對應了本文主題接口最大并發數。本文思維導圖如下，
圖片
并發和并行
再開始講并發之前，我需要再給大家回顧一些舊知識。
什么是并發？什么是并行...
并發（Concurrency）
早期計算機的 CPU 都是單核的，一個 CPU 在同一時間只能執行一個進程/線程，當系統中有多個進程/線程等待執行時，CPU 只能執行完一個再執行下一個。
計算機在運行過程中，有很多指令會涉及 I/O 操作，而 I/O 操作又是相當耗時的，速度遠遠低于 CPU，這導致 CPU 經常處于空閑狀態，只能等待 I/O 操作完成后才能繼續執行后面的指令。
為了提高 CPU 利用率，減少等待時間，人們提出了一種 CPU 并發工作的理論。
所謂并發，就是通過一種算法將 CPU 資源合理地分配給多個任務，當一個任務執行 I/O 操作時，CPU 可以轉而執行其它的任務，等到 I/O 操作完成以后，或者新的任務遇到 I/O 操作時，CPU 再回到原來的任務繼續執行。
下圖展示了兩個任務并發執行的過程：
圖片
圖片來源自C語言中文網-并發和并行的區別（圖解）
雖然 CPU 在同一時刻只能執行一個任務，但是通過將 CPU 的使用權在恰當的時機分配給不同的任務，使得多個任務在視覺上看起來是一起執行的。CPU 的執行速度極快，多任務切換的時間也極短，用戶根本感受不到，所以并發執行看起來才跟真的一樣。
并行（Parallelism）
并發是針對單核 CPU 提出的，而并行則是針對多核 CPU 提出的。和單核 CPU 不同，多核 CPU 真正實現了“同時執行多個任務”。
多核 CPU 內部集成了多個計算核心（Core），每個核心相當于一個簡單的 CPU，如果不計較細節，你可以認為給計算機安裝了多個獨立的 CPU。
多核 CPU 的每個核心都可以獨立地執行一個任務，而且多個核心之間不會相互干擾。在不同核心上執行的多個任務，是真正地同時運行，這種狀態就叫做并行。
例如，同樣是執行兩個任務，雙核 CPU 的工作狀態如下圖所示：
圖片
圖片來源自C語言中文網-并發和并行的區別（圖解）
雙核 CPU 執行兩個任務時，每個核心各自執行一個任務，和單核 CPU 在兩個任務之間不斷切換相比，它的執行效率更高。
思考一下
那么這里我們講了關于并發、并行概念與我們的接口最大并發處理數之間有什么關系嘞？放心這都是鋪墊，為了讓你好消化后面的內容。
這里我給大家總結下并發與并行的概念：
- 并發：在同一時間段內，多個任務都在執行，但不一定是同時執行。這意味著這些任務在輪流使用 CPU 的時間片，給人一種它們在“同時”運行的錯覺。并發的真正含義在于，盡管多個程序或進程可能正在運行，但每次只有一個進程或線程實際上正在使用 CPU。
- 并行：指在同一時刻，多個任務都在執行。這通常需要多個處理器或多核的 CPU 來實現，因為只有這樣，每個處理器或核心才能在同一時刻執行一個任務。例如，當音樂軟件和 IDEA 同時運行時，如果計算機有兩個以上的 CPU 核心，那么這兩個應用程序就可以真正地并行運行。
大家注意我上面加粗的字體，并發強調的是在同一段時間內，它是一個時間范圍的概念。打個比方，并發是一個人同時吃三個饅頭，吃完一個饅頭需要 1 分鐘，他就算胃口在大，也只能一個一個饅頭吃，吃完三個需要花 3 分鐘。
再看并行，并行強調的在同一時刻。打個比方，并行就是三個人同時吃三個饅頭。這三個人可以在同一時刻一人吃一個饅頭。吃完三個只需要花 1 分鐘。
那么看到這里，我在問你個問題，3 個人的在 3 分鐘內最多能吃多少個饅頭？
相信大家都能告訴我。
理解接口的最大并發處理數
在 Java 語言里面，我們怎么理解并發跟并行嘞？還是跟吃饅頭一樣，我給大家打個比方，相信大家就明白了。
比如說我有一個接口，他的 RT (響應時長)是 50 毫秒，只有一個線程處理客戶端請求，那這個線程在 1000 毫秒就能夠處理 20 個客戶端請求。
這里 20 就代表一個線程在 1 秒內的最大并發數。
那假如有兩個線程處理客戶端請求，接口的最大并發數是不是變成了 40，三個線程處理客戶端請求，接口的最大并發數就變成了 60，以此類推。
這里我們就可以得出一個公式，線程個數 * 單線程最大并發數 就代表接口的最大并行處理數。
那么根據公式，我們得出一個結論，通過增大線程數或者減少接口響應時間可以增大接口的最大并發處理數。
聊聊 Tomcat 容器的并發處理配置
在 Spring Boot 發布后，Tomcat 就成為了 Spring Boot 默認的 web 容器。這里結合上文內容，給大家講解下 Spring Boot 中涉及 Tomcat 服務器的一些關鍵參數，以及在高并發情況下如何通過這些參數來控制請求量。Spring boot 配置文件如下，
SpringBoot 版本：3.1.5
server:
port: 8080
tomcat:
threads:
max: 200
min-spare: 10
accept-count: 100
max-connections: 8192server.port
該參數用于指定服務器監聽的端口號。通過配置不同的端口號，可以實現多個服務在同一主機上并行運行。
這里為了方便大家理解，我用開飯店來給大家做比喻。通過指定服務器 ip + 啟動端口，就相當于告訴顧客我們的飯店位置，等待顧客上門吃飯。
server.tomcat.threads.max
該參數定義了 Tomcat 服務器的最大線程數。在高并發情況下，可以通過增加最大線程數來提高服務器最大并發處理數的能力，但需要注意服務器的硬件資源限制。
threads.max 相當于設置飯店在最忙碌時候，需要的最大的服務員數量，假如說一個服務員只能服務 1 個客人，那么 200 個服務員就可以同時服務 200 個客人，注意這是并行服務哦。
server.tomcat.threads.min-spare
此參數用于設置服務器在空閑狀態下保持的最小線程數。確保服務器在處理請求時有足夠的線程可用，以避免延遲。
threads.min-spare 相當于設置飯店空閑時候需要的最少的服務員數量。
server.tomcat.max-connections
該參數指定服務器接受和處理的客戶端最大連接數。超過這個限制后，會放入 accept-count 隊列中
max-connections 相當于設置飯店空間內客人的最大容納數量，注意是容納，進了飯店的客人不是一進來就能享受服務的。往往還需要等待一段時間。這段時間就是當服務員服務上一個客人完畢后，有空出來的服務員才能給進店新客人服務。
server.tomcat.accept-count
此參數定義了當所有可能的請求處理線程都在使用時，傳入連接請求的最大隊列長度。在高并發情況下，可以通過適當調整此參數來控制連接請求的排隊長度。
accept-count 相當于設置飯店門口的排隊人數大小。想一想我們外出吃飯的時候，什么情況需要排隊，當然是店內爆滿，沒有座位。那么這個時候你就需要排個隊了。注意如果說排隊人都滿了，怎么辦？
這個時候飯店就會通知沒有排上隊，還想要假如排隊的人，“你們不要排隊了，今天吃飯人滿了，大家去別處吃飯吧！”。
對應上 Tomcat 就是遇到客戶端連接數量超過了 max-connections + accept-count 大小后的情況，此時 Tomcat 會直接拒絕新的客戶端連接。
