SpringBoot可以同時處理多少請求流程分析
前言
前兩天面試的時候,面試官問我:一個ip發(fā)請求過來,是一個ip對應(yīng)一個線程嗎?我突然愣住了,對于SpringBoot如何處理請求好像從來沒仔細(xì)思考過,所以面試結(jié)束后就仔細(xì)研究了一番,現(xiàn)在就來探討一下這個問題。
正文
我們都知道,SpringBoot默認(rèn)的內(nèi)嵌容器是Tomcat,也就是我們的程序?qū)嶋H上是運行在Tomcat里的。所以與其說SpringBoot可以處理多少請求,到不如說Tomcat可以處理多少請求。
關(guān)于Tomcat的默認(rèn)配置,都在spring-configuration-metadata.json
文件中,對應(yīng)的配置類則是org.springframework.boot.autoconfigure.web.ServerProperties
。
和處理請求數(shù)量相關(guān)的參數(shù)有四個:
- server.tomcat.threads.min-spare:最少的工作線程數(shù),默認(rèn)大小是10。該參數(shù)相當(dāng)于長期工,如果并發(fā)請求的數(shù)量達不到10,就會依次使用這幾個線程去處理請求。server.tomcat.threads.max:最多的工作線程數(shù),默認(rèn)大小是200。該參數(shù)相當(dāng)于臨時工,如果并發(fā)請求的數(shù)量在10到200之間,就會使用這些臨時工線程進行處理。server.tomcat.max-connections:最大連接數(shù),默認(rèn)大小是8192。表示Tomcat可以處理的最大請求數(shù)量,超過8192的請求就會被放入到等待隊列。
- server.tomcat.accept-count:等待隊列的長度,默認(rèn)大小是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ù),因為默認(rèn)的數(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默認(rèn)是單例的,也就是說,處理請求的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(); }
如果要避免這樣的情況發(fā)生,就涉及到加鎖的問題了,就不在這里討論了。
到此這篇關(guān)于SpringBoot可以同時處理多少請求的文章就介紹到這了,更多相關(guān)SpringBoot同時處理多少請求內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家!
相關(guān)文章
SpringBoot整合MyBatis實現(xiàn)樂觀鎖和悲觀鎖的示例
這篇文章主要介紹了SpringBoot整合MyBatis實現(xiàn)樂觀鎖和悲觀鎖的示例,文中通過示例代碼介紹的非常詳細(xì),對大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價值,需要的朋友們下面隨著小編來一起學(xué)習(xí)學(xué)習(xí)吧2019-09-09Java Web實現(xiàn)添加定時任務(wù)的方法示例
這篇文章主要介紹了Java Web實現(xiàn)添加定時任務(wù)的方法,涉及java web定時任務(wù)控制類定義、調(diào)用及監(jiān)聽器定義、添加等相關(guān)操作技巧,需要的朋友可以參考下2018-01-01基于idea解決springweb項目的Java文件無法執(zhí)行問題
這篇文章給大家介紹了基于idea解決springweb項目的Java文件無法執(zhí)行問題,文中通過圖文結(jié)合的方式給大家介紹的非常詳細(xì),對大家的學(xué)習(xí)或工作有一定的幫助,需要的朋友可以參考下2024-02-02