SpringBoot可以同時(shí)處理多少請求流程分析
前言
前兩天面試的時(shí)候,面試官問我:一個(gè)ip發(fā)請求過來,是一個(gè)ip對應(yīng)一個(gè)線程嗎?我突然愣住了,對于SpringBoot如何處理請求好像從來沒仔細(xì)思考過,所以面試結(jié)束后就仔細(xì)研究了一番,現(xiàn)在就來探討一下這個(gè)問題。
正文
我們都知道,SpringBoot默認(rèn)的內(nèi)嵌容器是Tomcat,也就是我們的程序?qū)嶋H上是運(yùn)行在Tomcat里的。所以與其說SpringBoot可以處理多少請求,到不如說Tomcat可以處理多少請求。
關(guān)于Tomcat的默認(rèn)配置,都在spring-configuration-metadata.json
文件中,對應(yīng)的配置類則是org.springframework.boot.autoconfigure.web.ServerProperties
。
和處理請求數(shù)量相關(guān)的參數(shù)有四個(gè):
- server.tomcat.threads.min-spare:最少的工作線程數(shù),默認(rèn)大小是10。該參數(shù)相當(dāng)于長期工,如果并發(fā)請求的數(shù)量達(dá)不到10,就會(huì)依次使用這幾個(gè)線程去處理請求。server.tomcat.threads.max:最多的工作線程數(shù),默認(rèn)大小是200。該參數(shù)相當(dāng)于臨時(shí)工,如果并發(fā)請求的數(shù)量在10到200之間,就會(huì)使用這些臨時(shí)工線程進(jìn)行處理。server.tomcat.max-connections:最大連接數(shù),默認(rèn)大小是8192。表示Tomcat可以處理的最大請求數(shù)量,超過8192的請求就會(huì)被放入到等待隊(duì)列。
- server.tomcat.accept-count:等待隊(duì)列的長度,默認(rèn)大小是100。
舉個(gè)例子說明一下這幾個(gè)參數(shù)之間的關(guān)系:
如果把Tomcat比作一家飯店的話,那么一個(gè)請求其實(shí)就相當(dāng)于一位客人。min-spare就是廚師(長期工);max是廚師總數(shù)(長期工+臨時(shí)工);max-connections就是飯店里的座位數(shù)量;accept-count是門口小板凳的數(shù)量。來的客人優(yōu)先坐到飯店里面,然后廚師開始忙活,如果長期工可以干的完,就讓長期工干,如果長期工干不完,就再讓臨時(shí)工干。圖中畫的廚師一共15人,飯店里有30個(gè)座位,也就是說,如果現(xiàn)在來了20個(gè)客人,那么就會(huì)有5個(gè)人先在飯店里等著。如果現(xiàn)在來了35個(gè)人,飯店里坐不下,就會(huì)讓5個(gè)人先到門口坐一下。如果來了50個(gè)人,那么飯店座位+門口小板凳一共40個(gè),所以就會(huì)有10人離開。
也就是說,SpringBoot同時(shí)所能處理的最大請求數(shù)量是max-connections+accept-count
,超過該數(shù)量的請求直接就會(huì)被丟掉。
紙上得來終覺淺,絕知此事要躬行。
上面只是理論結(jié)果,現(xiàn)在通過一個(gè)實(shí)際的小例子來演示一下到底是不是這樣:
創(chuàng)建一個(gè)SpringBoot的項(xiàng)目,在application.yml里配置一下這幾個(gè)參數(shù),因?yàn)槟J(rèn)的數(shù)量太大,不好測試,所以配小一點(diǎn):
server: tomcat: threads: # 最少線程數(shù) min-spare: 10 # 最多線程數(shù) max: 15 # 最大連接數(shù) max-connections: 30 # 最大等待數(shù) accept-count: 10
再來寫一個(gè)簡單的接口:
@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秒,這樣肯定會(huì)導(dǎo)致部分請求處理一次性處理不了而進(jìn)入到等待隊(duì)列。
然后我用Apifox創(chuàng)建了一個(gè)測試用例,去模擬100個(gè)請求:
觀察一下測試結(jié)果:
從結(jié)果中可以看出,由于設(shè)置的 max-connections+accept-count 的和是40,所以有60個(gè)請求會(huì)被丟棄,這和我們的預(yù)期是相符的。由于最大線程是15,也就是有25個(gè)請求會(huì)先等待,等前15個(gè)處理完了再處理15個(gè),最后在處理10個(gè),也就是將40個(gè)請求分成了15,15,10這樣三批進(jìn)行處理。
再從控制臺的打印日志可以看到,線程的最大編號是15,這也印證了前面的想法。
總結(jié)一下:如果并發(fā)請求數(shù)量低于server.tomcat.threads.max,則會(huì)被立即處理,超過的部分會(huì)先進(jìn)行等待,如果數(shù)量超過max-connections與accept-count之和,則多余的部分則會(huì)被直接丟棄。
延伸:并發(fā)問題是如何產(chǎn)生的
到目前為止,就已經(jīng)搞明白了SpringBoot可以同時(shí)處理多少請求的問題。但是在這里我還想基于上面的例子再延伸一下,就是為什么并發(fā)場景下會(huì)出現(xiàn)一些值和我們預(yù)期的不一樣?
設(shè)想有以下場景:廚師們用一個(gè)賬本記錄一共做了多少道菜,每個(gè)廚師做完菜都記錄一下,每次記錄都是將賬本上的數(shù)字先抄到草稿紙上,計(jì)算x+1等于多少,然后將計(jì)算的結(jié)果寫回到賬本上。
Spring容器中的Bean默認(rèn)是單例的,也就是說,處理請求的Controller、Service實(shí)例就只有一份。在并發(fā)場景下,將cookSum定義為全局變量,是所有線程共享的,當(dāng)一個(gè)線程讀到了cookSum=20,然后計(jì)算,寫回前另一個(gè)線程也讀到是20,兩個(gè)線程都加1后寫回,最終cookSum就變成了21,但是實(shí)際上應(yīng)該是22,因?yàn)榧恿藘纱巍?/p>
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ā)生,就涉及到加鎖的問題了,就不在這里討論了。
到此這篇關(guān)于SpringBoot可以同時(shí)處理多少請求的文章就介紹到這了,更多相關(guān)SpringBoot同時(shí)處理多少請求內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家!
相關(guān)文章
SpringBoot整合MyBatis實(shí)現(xiàn)樂觀鎖和悲觀鎖的示例
這篇文章主要介紹了SpringBoot整合MyBatis實(shí)現(xiàn)樂觀鎖和悲觀鎖的示例,文中通過示例代碼介紹的非常詳細(xì),對大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值,需要的朋友們下面隨著小編來一起學(xué)習(xí)學(xué)習(xí)吧2019-09-09Java Web實(shí)現(xiàn)添加定時(shí)任務(wù)的方法示例
這篇文章主要介紹了Java Web實(shí)現(xiàn)添加定時(shí)任務(wù)的方法,涉及java web定時(shí)任務(wù)控制類定義、調(diào)用及監(jiān)聽器定義、添加等相關(guān)操作技巧,需要的朋友可以參考下2018-01-01基于idea解決springweb項(xiàng)目的Java文件無法執(zhí)行問題
這篇文章給大家介紹了基于idea解決springweb項(xiàng)目的Java文件無法執(zhí)行問題,文中通過圖文結(jié)合的方式給大家介紹的非常詳細(xì),對大家的學(xué)習(xí)或工作有一定的幫助,需要的朋友可以參考下2024-02-02