前言

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

正文

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

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

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

• server.tomcat.threads.min-spare：最少的工作線程數(shù)，默認(rèn)大小是10。該參數(shù)相當(dāng)于長(zhǎng)期工，如果并發(fā)請(qǐng)求的數(shù)量達(dá)不到10，就會(huì)依次使用這幾個(gè)線程去處理請(qǐng)求。

• server.tomcat.threads.max：最多的工作線程數(shù)，默認(rèn)大小是200。該參數(shù)相當(dāng)于臨時(shí)工，如果并發(fā)請(qǐng)求的數(shù)量在10到200之間，就會(huì)使用這些臨時(shí)工線程進(jìn)行處理。

• server.tomcat.max-connections：最大連接數(shù)，默認(rèn)大小是8192。表示Tomcat可以處理的最大請(qǐng)求數(shù)量，超過(guò)8192的請(qǐng)求就會(huì)被放入到等待隊(duì)列。

• server.tomcat.accept-count：等待隊(duì)列的長(zhǎng)度，默認(rèn)大小是100。

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

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

也就是說(shuō)，SpringBoot同時(shí)所能處理的最大請(qǐng)求數(shù)量是max-connections+accept-count，超過(guò)該數(shù)量的請(qǐng)求直接就會(huì)被丟掉。

紙上得來(lái)終覺(jué)淺，絕知此事要躬行。

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

創(chuàng)建一個(gè)SpringBoot的項(xiàng)目，在application.yml里配置一下這幾個(gè)參數(shù)，因?yàn)槟J(rèn)的數(shù)量太大，不好測(cè)試，所以配小一點(diǎn)：

yaml復(fù)制代碼?server: ? ?tomcat: ? ? ?threads: ? ? ? ?# 最少線程數(shù) ? ? ? ?min-spare: 10 ? ? ? ?# 最多線程數(shù) ? ? ? ?max: 15 ? ? ?# 最大連接數(shù) ? ? ?max-connections: 30 ? ? ?# 最大等待數(shù) ? ? ?accept-count: 10

再來(lái)寫(xiě)一個(gè)簡(jiǎn)單的接口：

scss復(fù)制代碼? ? ?@GetMapping("/test") ? ? ?public Response test1(HttpServletRequest request) throws Exception { ? ? ? ? ?log.info("ip:{},線程:{}", request.getRemoteAddr(), Thread.currentThread().getName()); ? ? ? ? ?Thread.sleep(500); ? ? ? ? ?return Response.buildSuccess(); ? ? ?}

代碼很簡(jiǎn)單，只是打印了一下線程名，然后休眠0.5秒，這樣肯定會(huì)導(dǎo)致部分請(qǐng)求處理一次性處理不了而進(jìn)入到等待隊(duì)列。

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

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

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

再?gòu)目刂婆_(tái)的打印日志可以看到，線程的最大編號(hào)是15，這也印證了前面的想法。

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

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

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

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

Spring容器中的Bean默認(rèn)是單例的，也就是說(shuō)，處理請(qǐng)求的Controller、Service實(shí)例就只有一份。在并發(fā)場(chǎng)景下，將cookSum定義為全局變量，是所有線程共享的，當(dāng)一個(gè)線程讀到了cookSum=20，然后計(jì)算，寫(xiě)回前另一個(gè)線程也讀到是20，兩個(gè)線程都加1后寫(xiě)回，最終cookSum就變成了21，但是實(shí)際上應(yīng)該是22，因?yàn)榧恿藘纱巍?/p>

java復(fù)制代碼?private int cookSum = 0; ? ?@GetMapping("/test") ?public Response test1(HttpServletRequest request) throws Exception { ? ? ?// 做菜。。。。。。 ? ? ?cookSum += 1; ? ? ?log.info("做了{(lán)}道菜", cookSum); ? ? ?Thread.sleep(500); ? ? ?return Response.buildSuccess(); ?}

如果要避免這樣的情況發(fā)生，就涉及到加鎖的問(wèn)題了，就不在這里討論了。