SpringBoot可以同時處理多少請求？詳情 - springboot,spring-mvc,微服務,spring 碼猿技術專欄動態日志

大家好，我是不才陳某~

我們都知道，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();
}