快捷導(dǎo)航

SpringBoot可以同時處理多少請求流程分析

更新時間：2023年02月27日 08:48:33 作者：Robod

SpringBoot默認的內(nèi)嵌容器是Tomcat，也就是我們的程序?qū)嶋H上是運行在Tomcat里的，所以與其說SpringBoot可以處理多少請求，到不如說Tomcat可以處理多少請求，這篇文章主要介紹了SpringBoot可以同時處理多少請求,需要的朋友可以參考下

前言

前兩天面試的時候，面試官問我：一個ip發(fā)請求過來，是一個ip對應(yīng)一個線程嗎？我突然愣住了，對于SpringBoot如何處理請求好像從來沒仔細思考過，所以面試結(jié)束后就仔細研究了一番，現(xiàn)在就來探討一下這個問題。

正文

我們都知道，SpringBoot默認的內(nèi)嵌容器是Tomcat，也就是我們的程序?qū)嶋H上是運行在Tomcat里的。所以與其說SpringBoot可以處理多少請求，到不如說Tomcat可以處理多少請求。

關(guān)于Tomcat的默認配置，都在spring-configuration-metadata.json文件中，對應(yīng)的配置類則是org.springframework.boot.autoconfigure.web.ServerProperties。

和處理請求數(shù)量相關(guān)的參數(shù)有四個：

server.tomcat.threads.min-spare：最少的工作線程數(shù)，默認大小是10。該參數(shù)相當(dāng)于長期工，如果并發(fā)請求的數(shù)量達不到10，就會依次使用這幾個線程去處理請求。server.tomcat.threads.max：最多的工作線程數(shù)，默認大小是200。該參數(shù)相當(dāng)于臨時工，如果并發(fā)請求的數(shù)量在10到200之間，就會使用這些臨時工線程進行處理。server.tomcat.max-connections：最大連接數(shù)，默認大小是8192。表示Tomcat可以處理的最大請求數(shù)量，超過8192的請求就會被放入到等待隊列。
server.tomcat.accept-count：等待隊列的長度，默認大小是100。

舉個例子說明一下這幾個參數(shù)之間的關(guān)系：

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

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

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

上面只是理論結(jié)果，現(xiàn)在通過一個實際的小例子來演示一下到底是不是這樣：

創(chuàng)建一個SpringBoot的項目，在application.yml里配置一下這幾個參數(shù)，因為默認的數(shù)量太大，不好測試，所以配小一點：

server:
  tomcat:
    threads:
      # 最少線程數(shù)
      min-spare: 10
      # 最多線程數(shù)
      max: 15
    # 最大連接數(shù)
    max-connections: 30
    # 最大等待數(shù)
    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秒，這樣肯定會導(dǎo)致部分請求處理一次性處理不了而進入到等待隊列。

然后我用Apifox創(chuàng)建了一個測試用例，去模擬100個請求：

觀察一下測試結(jié)果：

從結(jié)果中可以看出，由于設(shè)置的 max-connections+accept-count 的和是40，所以有60個請求會被丟棄，這和我們的預(yù)期是相符的。由于最大線程是15，也就是有25個請求會先等待，等前15個處理完了再處理15個，最后在處理10個，也就是將40個請求分成了15,15,10這樣三批進行處理。

再從控制臺的打印日志可以看到，線程的最大編號是15，這也印證了前面的想法。

總結(jié)一下：如果并發(fā)請求數(shù)量低于server.tomcat.threads.max，則會被立即處理，超過的部分會先進行等待，如果數(shù)量超過max-connections與accept-count之和，則多余的部分則會被直接丟棄。

延伸：并發(fā)問題是如何產(chǎn)生的

到目前為止，就已經(jīng)搞明白了SpringBoot可以同時處理多少請求的問題。但是在這里我還想基于上面的例子再延伸一下，就是為什么并發(fā)場景下會出現(xiàn)一些值和我們預(yù)期的不一樣？

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

Spring容器中的Bean默認是單例的，也就是說，處理請求的Controller、Service實例就只有一份。在并發(fā)場景下，將cookSum定義為全局變量，是所有線程共享的，當(dāng)一個線程讀到了cookSum=20，然后計算，寫回前另一個線程也讀到是20，兩個線程都加1后寫回，最終cookSum就變成了21，但是實際上應(yīng)該是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();
}