SpringBoot可以同時處理多少請求？

碼猿技術專欄發表於2023-03-08
Spring Boot

大家好，我是不才陳某~

我們都知道，SpringBoot預設的內嵌容器是Tomcat，也就是我們的程式實際上是執行在Tomcat裡的。所以與其說SpringBoot可以處理多少請求，倒不如說Tomcat可以處理多少請求。

關注公眾號：碼猿技術專欄，回覆關鍵詞：1111 獲取阿里內部效能調優手冊

關於Tomcat的預設配置，都在spring-configuration-metadata.json檔案中，對應的配置類則是org.springframework.boot.autoconfigure.web.ServerProperties。

和處理請求數量相關的引數有四個：

  • 「server.tomcat.threads.min-spare」：最少的工作執行緒數，預設大小是10。該引數相當於長期工，如果併發請求的數量達不到10，就會依次使用這幾個執行緒去處理請求。
  • 「server.tomcat.threads.max」：最多的工作執行緒數，預設大小是200。該引數相當於臨時工，如果併發請求的數量在10到200之間，就會使用這些臨時工執行緒進行處理。
  • 「server.tomcat.max-connections」：最大連線數，預設大小是8192。表示Tomcat可以處理的最大請求數量，超過8192的請求就會被放入到等待佇列。
  • 「server.tomcat.accept-count」：等待佇列的長度，預設大小是100。

舉個例子說明一下這幾個引數之間的關係：

如果把Tomcat比作一家飯店的話，那麼一個請求其實就相當於一位客人。min-spare就是廚師(長期工)；max是廚師總數(長期工+臨時工)；max-connections就是飯店裡的座位數量；accept-count是門口小板凳的數量。來的客人優先坐到飯店裡面，然後廚師開始忙活，如果長期工可以幹得完，就讓長期工幹，如果長期工幹不完，就再讓臨時工幹。圖中畫的廚師一共15人，飯店裡有30個座位，也就是說，如果現在來了20個客人，那麼就會有5個人先在飯店裡等著。如果現在來了35個人，飯店裡坐不下，就會讓5個人先到門口坐一下。如果來了50個人，那麼飯店座位+門口小板凳一共40個，所以就會有10人離開。

也就是說，SpringBoot同所能處理的最大請求數量是max-connections+accept-count，超過該數量的請求直接就會被丟掉。

「紙上得來終覺淺，絕知此事要躬行。」

上面只是理論結果，現在透過一個實際的小例子來演示一下到底是不是這樣：

建立一個SpringBoot的專案，在application.yml裡配置一下這幾個引數，因為預設的數量太大，不好測試，所以配小一點：

server:
  tomcat:
    threads:
      # 最少執行緒數
      min-spare: 10
      # 最多執行緒數
      max: 15
    # 最大連線數
    max-connections: 30
    # 最大等待數
    accept-count: 10

再來寫一個簡單的介面：

    @GetMapping("/test")
    public Response test1(HttpServletRequest request) throws Exception {
        log.info("ip:{},執行緒:{}", request.getRemoteAddr(), Thread.currentThread().getName());
        Thread.sleep(500);
        return Response.buildSuccess();
    }

程式碼很簡單，只是列印了一下執行緒名，然後休眠0.5秒，這樣肯定會導致部分請求處理一次性處理不了而進入到等待佇列。

然後我用Apifox建立了一個測試用例，去模擬100個請求：

觀察一下測試結果：

從結果中可以看出，由於設定的 「max-connections+accept-count」 的和是40，所以有60個請求會被丟棄，這和我們的預期是相符的。由於最大執行緒是15，也就是有25個請求會先等待，等前15個處理完了再處理15個，最後在處理10個，也就是將40個請求分成了15,15,10這樣三批進行處理。

再從控制檯的列印日誌可以看到，執行緒的最大編號是15，這也印證了前面的想法。

「總結一下」：如果併發請求數量低於「server.tomcat.threads.max」，則會被立即處理，超過的部分會先進行等待，如果數量超過max-connections與accept-count之和，則多餘的部分則會被直接丟棄。

延伸：併發問題是如何產生的

到目前為止，就已經搞明白了SpringBoot同時可以處理多少請求的問題。但是在這裡我還想基於上面的例子再延伸一下，就是為什麼併發場景下會出現一些值和我們預期的不一樣？

設想有以下場景：廚師們用一個賬本記錄一共做了多少道菜，每個廚師做完菜都記錄一下，每次記錄都是將賬本上的數字先抄到草稿紙上，計算x+1等於多少，然後將計算的結果寫回到賬本上。

Spring容器中的Bean預設是單例的，也就是說，處理請求的Controller、Service例項就只有一份。在併發場景下，將cookSum定義為全域性變數，是所有執行緒共享的，當一個執行緒讀到了cookSum=20，然後計算，寫回前另一個執行緒也讀到是20，兩個執行緒都加1後寫回，最終cookSum就變成了21，但是實際上應該是22，因為加了兩次。

private int cookSum = 0;

@GetMapping("/test")
public Response test1(HttpServletRequest request) throws Exception {
 // 做菜。。。。。。
 cookSum += 1;
    log.info("做了{}道菜", cookSum);
    Thread.sleep(500);
 return Response.buildSuccess();
}

如果要避免這樣的情況發生，就涉及到加鎖的問題了，就不在這裡討論了。

最後說一句（別白嫖，求關注）

陳某每一篇文章都是精心輸出，如果這篇文章對你有所幫助，或者有所啟發的話，幫忙點贊、在看、轉發、收藏，你的支援就是我堅持下去的最大動力！

關注公眾號：【碼猿技術專欄】，公眾號內有超讚的粉絲福利，回覆：加群，可以加入技術討論群，和大家一起討論技術，吹牛逼！

相關文章