SpringBoot能同時處理多少請求

正文

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

關於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();
}

以上是SpringBoot能同時處理多少請求的詳細內容。更多資訊請關注PHP中文網其他相關文章！