你好呀，我是歪歪。

這篇文章帶大家盤一個讀者遇到的面試題哈。

根據(jù)讀者轉(zhuǎn)述，面試官的原問題就是：一個 SpringBoot 項目能同時處理多少請求？

不知道你聽到這個問題之后的第一反應(yīng)是什么。

我大概知道他要問的是哪個方向，但是對于這種只有一句話的面試題，我的第一反應(yīng)是：會不會有坑？

所以并不會貿(mào)然答題，先追問一些消息，比如：這個項目具體是干什么的？項目大概進(jìn)行了哪些參數(shù)配置？使用的 web 容器是什么？部署的服務(wù)器配置如何？有哪些接口？接口響應(yīng)平均時間大概是多少？

這樣，在幾個問題的拉扯之后，至少在面試題考察的方向方面能基本和面試官達(dá)成了一致。

比如前面的面試問題，經(jīng)過幾次拉扯之后，面試官可能會修改為：

一個 SpringBoot 項目，未進(jìn)行任何特殊配置，全部采用默認(rèn)設(shè)置，這個項目同一時刻，最多能同時處理多少請求？

能處理多少呢？

我也不知道，但是當(dāng)問題變成上面這樣之后，我找到了探索答案的角度。

既然“未進(jìn)行任何特殊配置”，那我自己搞個 Demo 出來，壓一把不就完事了嗎？

坐穩(wěn)扶好，準(zhǔn)備發(fā)車。

Demo

小手一抖，先搞個 Demo 出來。

這個 Demo 非常的簡單，就是通過 idea 創(chuàng)建一個全新的 SpringBoot 項目就行。

我的 SpringBoot 版本使用的是 2.7.13。

整個項目只有這兩個依賴：

圖片

整個項目也只有兩個類，要得就是一個空空如也，一清二白。

圖片

項目中的 TestController，里面只有一個 getTest 方法，用來測試，方法里面接受到請求之后直接 sleep 一小時。

目的就是直接把當(dāng)前請求線程占著，這樣我們才能知道項目中一共有多少個線程可以使用：

@Slf4j
@RestController
public class TestController {

    @GetMapping("/getTest")
    public void getTest(int num) throws Exception {
        log.info("{} 接受到請求:num={}", Thread.currentThread().getName(), num);
        TimeUnit.HOURS.sleep(1);
    }
}

項目中的 application.properties 文件也是空的：

圖片

這樣，一個“未進(jìn)行任何特殊配置”的 SpringBoot 不就有了嗎？

基于這個 Demo，前面的面試題就要變成了：我短時間內(nèi)不斷的調(diào)用這個 Demo 的 getTest 方法，最多能調(diào)用多少次？

問題是不是又變得更加簡單了一點？

那么前面這個“短時間內(nèi)不斷的調(diào)用”，用代碼怎么表示呢？

很簡單，就是在循環(huán)中不斷的進(jìn)行接口調(diào)用就行了。

public class MainTest {
    public static void main(String[] args) {
        for (int i = 0; i < 1000; i++) {
            int finalI = i;
            new Thread(() -> {
                HttpUtil.get("127.0.0.1:8080/getTest?num=" + finalI);
            }).start();
        }
        //阻塞主線程
        Thread.yield();
    }
}

當(dāng)然了，這個地方你用一些壓測工具，比如 jmeter 啥的，會顯得逼格更高，更專業(yè)。我這里就偷個懶，直接上代碼了。

答案

經(jīng)過前面的準(zhǔn)備工作，Demo 和測試代碼都就緒了。

接下來就是先把 Demo 跑起來：

圖片

然后跑一把 MainTest。

當(dāng) MainTest 跑起來之后，Demo 這邊就會快速的、大量的輸出這樣的日志：

圖片

也就是我前面 getTest 方法中寫的日志：

圖片

好，現(xiàn)在我們回到這個問題：

我短時間內(nèi)不斷的調(diào)用這個 Demo 的 getTest 方法，最多能調(diào)用多少次？

來，請你告訴我怎么得到這個問題的答案？

我這里就是一個大力出奇跡，直接統(tǒng)計“接受到請求”關(guān)鍵字在日志中出現(xiàn)的次數(shù)就行了：

圖片

很顯然，答案就是：

所以，當(dāng)面試官問你：一個 SpringBoot 項目能同時處理多少請求？

你裝作仔細(xì)思考之后，篤定的說：200 次。

面試官微微點頭，并等著你繼續(xù)說下去。

你也暗自歡喜，幸好看了歪歪歪師傅的文章，背了個答案。然后等著面試官繼續(xù)問其他問題。

氣氛突然就尷尬了起來。

接著，你就回家等通知了。

200 次，這個回答是對的，但是你只說 200 次，這個回答就顯得有點尬了。

重要的是，這個值是怎么來的？

所以，下面這一部分，你也要背下來。

怎么來的？

在開始探索怎么來的之前，我先問你一個問題，這個 200 個線程，是誰的線程，或者說是誰在管理這個線程？

是 SpringBoot 嗎？

肯定不是，SpringBoot 并不是一個 web 容器。

應(yīng)該是 Tomcat 在管理這 200 個線程。

這一點，我們通過線程 Dump 也能進(jìn)行驗證：

圖片

圖片

通過線程 Dump 文件，我們可以知道，大量的線程都在 sleep 狀態(tài)。而點擊這些線程，查看其堆棧消息，可以看到 Tomcat、threads、ThreadPoolExecutor 等關(guān)鍵字：

at org.apache.Tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1791)
at org.apache.Tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:52)
at org.apache.Tomcat.util.threads.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1191)
at org.apache.Tomcat.util.threads.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:659)
at org.apache.Tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)

基于“短時間內(nèi)有 200 個請求被立馬處理的”這個現(xiàn)象，結(jié)合你背的滾瓜爛熟的、非常扎實的線程池知識，你先大膽的猜一個：Tomcat 默認(rèn)核心線程數(shù)是 200。

接下來，我們就是要去源碼里面驗證這個猜測是否正確了。

我之前分享過閱讀源碼的方式，《我試圖通過這篇文章，教會你一種閱讀源碼的方式。》，其中最重要的一條就是打一個有效的斷點，然后基于斷點處的調(diào)用棧去定位源碼。

這里我再教你一個不用打斷點也能獲取到調(diào)用棧的方法。

在前面已經(jīng)展示過了，就是線程 Dump。

右邊就是一個線程完整的調(diào)用棧：

圖片

從這個調(diào)用棧中，由于我們要找的是 Tomcat 線程池相關(guān)的源碼，所以第一次出現(xiàn)相關(guān)關(guān)鍵字的地方就是這一行：

org.apache.Tomcat.util.threads.ThreadPoolExecutor.Worker#run

圖片

然后我們在這一行打上斷點。

重啟項目，開始調(diào)試。

進(jìn)入 runWorker 之后，這部分代碼看起來就非常眼熟了：

圖片

簡直和 JDK 里面的線程池源碼一模一樣。

如果你熟悉 JDK 線程池源碼的話，調(diào)試 Tomcat 的線程池，那個感覺，就像是回家一樣。

如果你不熟悉的話，我建議你盡快去熟悉熟悉。

隨著斷點往下走，在 getTask 方法里面，可以看到關(guān)于線程池的幾個關(guān)鍵參數(shù)：

org.apache.Tomcat.util.threads.ThreadPoolExecutor#getTask

圖片

corePoolSize，核心線程數(shù)，值為 10。

maximumPoolSize，最大線程數(shù)，值為 200。

而且基于 maximumPoolSize 這個參數(shù)，你往前翻代碼，會發(fā)現(xiàn)這個默認(rèn)值就是 200：

圖片

好，到這里，你發(fā)現(xiàn)你之前猜測的“Tomcat 默認(rèn)核心線程數(shù)是 200”是不對的。

但是你一點也不慌，再次結(jié)合你背的滾瓜爛熟的、非常扎實的線程池知識。

并在心里又默念了一次：當(dāng)線程池接受到任務(wù)之后，先啟用核心線程數(shù)，再使用隊列長度，最后啟用最大線程數(shù)。

因為我們前面驗證了，Tomcat 可以同時間處理 200 個請求，而它的線程池核心線程數(shù)只有 10，最大線程數(shù)是 200。

這說明，我前面這個測試用例，把隊列給塞滿了，從而導(dǎo)致 Tomcat 線程池啟用了最大線程數(shù)：

圖片

嗯，一定是這樣的！

那么，現(xiàn)在的關(guān)鍵問題就是：Tomcat 線程池默認(rèn)的隊列長度是多少呢？

在當(dāng)前的這個 Debug 模式下，隊列長度可以通過 Alt+F8 進(jìn)行查看：

圖片

wc，這個值是 Integer.MAX_VALUE，這么大？

我一共也才 1000 個任務(wù)，不可能被占滿??？

一個線程池：

• 核心線程數(shù)，值為 10。
• 最大線程數(shù)，值為 200。
• 隊列長度，值為 Integer.MAX_VALUE。

1000 個比較耗時的任務(wù)過來之后，應(yīng)該是只有 10 個線程在工作，然后剩下的 990 個進(jìn)隊列才對??？

難道我八股文背錯了？

這個時候不要慌，嗦根辣條冷靜一下。

目前已知的是核心線程數(shù)，值為 10。這 10 個線程的工作流程是符合我們認(rèn)知的。

但是第 11 個任務(wù)過來的時候，本應(yīng)該進(jìn)入隊列去排隊。

現(xiàn)在看起來，是直接啟用最大線程數(shù)了。

所以，我們先把測試用例修改一下：

圖片

那么問題就來了：最后一個請求到底是怎么提交到線程池里面的？

前面說了，Tomcat 的線程池源碼和 JDK 的基本一樣。

往線程池里面提交任務(wù)的時候，會執(zhí)行 execute 這個方法：

org.apache.Tomcat.util.threads.ThreadPoolExecutor#execute(java.lang.Runnable)

圖片

對于 Tomcat 它會調(diào)用到 executeInternal 這個方法：

org.apache.Tomcat.util.threads.ThreadPoolExecutor#executeInternal

圖片

這個方法里面，標(biāo)號為 ① 的地方，就是判斷當(dāng)前工作線程數(shù)是否小于核心線程數(shù)，小于則直接調(diào)用 addWorker 方法，創(chuàng)建線程。

標(biāo)號為 ② 的地方主要是調(diào)用了 offer 方法，看看隊列里面是否還能繼續(xù)添加任務(wù)。

如果不能繼續(xù)添加，說明隊列滿了，則來到標(biāo)號為 ③ 的地方，看看是否能執(zhí)行 addWorker 方法，創(chuàng)建非核心線程，即啟用最大線程數(shù)。

把這個邏輯捋順之后，接下來我們應(yīng)該去看哪部分的代碼，就很清晰了。

主要就是去看 workQueue.offer(command) 這個邏輯。

如果返回 true 則表示加入到隊列，返回 false 則表示啟用最大線程數(shù)嘛。

這個 workQueue 是 TaskQueue，看起來一點也不眼熟：

圖片

當(dāng)然不眼熟了，因為這個是 Tomcat 自己基于 LinkedBlockingQueue 搞的一個隊列。

圖片

問題的答案就藏在 TaskQueue 的 offer 方法里面。

所以我重點帶你盤一下這個 offer 方法：

org.apache.Tomcat.util.threads.TaskQueue#offer

圖片

標(biāo)號為 ① 的地方，判斷了 parent 是否為 null，如果是則直接調(diào)用父類的 offer 方法。說明要啟用這個邏輯，我們的 parent 不能為 null。

那么這個 parent 是什么玩意，從哪里來的呢？

圖片

parent 就是 Tomcat 線程池，通過其 set 方法可以知道，是在線程池完成初始化之后，進(jìn)行了賦值。

也就是說，你可以理解為，在 Tomcat 的場景下，parent 不會為空。

標(biāo)號為 ② 的地方，調(diào)用了 getPoolSizeNoLock 方法：

圖片

這個方法是獲取當(dāng)前線程池中有多個線程。

所以如果這個表達(dá)式為 true：

parent.getPoolSizeNoLock() == parent.getMaximumPoolSize()

就表明當(dāng)前線程池的線程數(shù)已經(jīng)是配置的最大線程數(shù)了，那就調(diào)用 offer 方法，把當(dāng)前請求放到到隊列里面去。

標(biāo)號為 ③ 的地方，是判斷已經(jīng)提交到線程池里面待執(zhí)行或者正在執(zhí)行的任務(wù)個數(shù)，是否比當(dāng)前線程池的線程數(shù)還少。

如果是，則說明當(dāng)前線程池有空閑線程可以執(zhí)行任務(wù)，則把任務(wù)放到隊列里面去，就會被空閑線程給取走執(zhí)行。

然后，關(guān)鍵的來了，標(biāo)號為 ④ 的地方。

如果當(dāng)前線程池的線程數(shù)比線程池配置的最大線程數(shù)還少，則返回 false。

前面說了，offer 方法返回 false，會出現(xiàn)什么情況？

圖片

是不是直接開始到上圖中標(biāo)號為 ③ 的地方，去嘗試添加非核心線程了？

也就是啟用最大線程數(shù)這個配置了。

所以，朋友們，這個是什么情況？

這個情況確實就和我們背的線程池的八股文不一樣了啊。

JDK 的線程池，是先使用核心線程數(shù)配置，接著使用隊列長度，最后再使用最大線程配置。

Tomcat 的線程池，就是先使用核心線程數(shù)配置，再使用最大線程配置，最后才使用隊列長度。

所以，以后當(dāng)面試官給你說：我們聊聊線程池的工作機(jī)制吧？

你就先追問一句：你是說的 JDK 的線程池呢還是 Tomcat 的線程池呢，因為這兩個在運行機(jī)制上有一點差異。

然后，你就看他的表情。

如果透露出一絲絲遲疑，然后輕描淡寫的說一句：那就對比著說一下吧。

那么恭喜你，在這個題目上開始掌握了一點主動權(quán)。

最后，為了讓你更加深刻的理解到 Tomcat 線程池和 JDK 線程池的不一樣，我給你搞一個直接復(fù)制過去就能運行的代碼。

當(dāng)你把 taskqueue.setParent(executor) 這行代碼注釋掉的時候，它的運行機(jī)制就是 JDK 的線程池。

當(dāng)存在這行代碼的時候，它的運行機(jī)制就變成了 Tomcat 的線程池。

玩去吧。

import org.apache.tomcat.util.threads.TaskQueue;
import org.apache.tomcat.util.threads.TaskThreadFactory;
import org.apache.tomcat.util.threads.ThreadPoolExecutor;

import java.util.concurrent.TimeUnit;

public class TomcatThreadPoolExecutorTest {

    public static void main(String[] args) throws InterruptedException {
        String namePrefix = "歪歪歪-exec-";
        boolean daemon = true;
        TaskQueue taskqueue = new TaskQueue(300);
        TaskThreadFactory tf = new TaskThreadFactory(namePrefix, daemon, Thread.NORM_PRIORITY);
        ThreadPoolExecutor executor = new ThreadPoolExecutor(5,
                150, 60000, TimeUnit.MILLISECONDS, taskqueue, tf);
        taskqueue.setParent(executor);
        for (int i = 0; i < 300; i++) {
            try {
                executor.execute(() -> {
                    logStatus(executor, "創(chuàng)建任務(wù)");
                    try {
                        TimeUnit.SECONDS.sleep(2);
                    } catch (InterruptedException e) {
                        e.printStackTrace();
                    }
                });
            } catch (Exception e) {
                e.printStackTrace();
            }
        }
        Thread.currentThread().join();
    }

    private static void logStatus(ThreadPoolExecutor executor, String name) {
        TaskQueue queue = (TaskQueue) executor.getQueue();
        System.out.println(Thread.currentThread().getName() + "-" + name + "-:" +
                "核心線程數(shù):" + executor.getCorePoolSize() +
                "\t活動線程數(shù):" + executor.getActiveCount() +
                "\t最大線程數(shù):" + executor.getMaximumPoolSize() +
                "\t總?cè)蝿?wù)數(shù):" + executor.getTaskCount() +
                "\t當(dāng)前排隊線程數(shù):" + queue.size() +
                "\t隊列剩余大小:" + queue.remainingCapacity());
    }
}

等等

如果你之前確實沒了解過 Tomcat 線程池的工作機(jī)制，那么看到這里的時候也許你會覺得確實是有一點點收獲。

但是，注意我要說但是了。

還記得最開始的時候面試官的問題嗎？

面試官的原問題就是：一個 SpringBoot 項目能同時處理多少請求？

那么請問，前面我講了這么大一坨 Tomcat 線程池運行原理，這個回答，和這個問題匹配嗎？

是的，除了最開始提出的 200 這個數(shù)值之外，并不匹配，甚至在面試官的眼里完全是答非所問了。

所以，為了把這兩個“并不匹配”的東西比較順暢的鏈接起來，你必須要先回答面試官的問題，然后再開始擴(kuò)展。

比如這樣答：一個未進(jìn)行任何特殊配置，全部采用默認(rèn)設(shè)置的 SpringBoot 項目，這個項目同一時刻最多能同時處理多少請求，取決于我們使用的 web 容器，而 SpringBoot 默認(rèn)使用的是 Tomcat。

Tomcat 的默認(rèn)核心線程數(shù)是 10，最大線程數(shù) 200，隊列長度是無限長。但是由于其運行機(jī)制和 JDK 線程池不一樣，在核心線程數(shù)滿了之后，會直接啟用最大線程數(shù)。所以，在默認(rèn)的配置下，同一時刻，可以處理 200 個請求。

在實際使用過程中，應(yīng)該基于服務(wù)實際情況和服務(wù)器配置等相關(guān)消息，對該參數(shù)進(jìn)行評估設(shè)置。

這個回答就算是差不多了。

但是，如果很不幸，如果你遇到了我，為了驗證你是真的自己去摸索過，還是僅僅只是看了幾篇文章，我可能還會追問一下：

那么其他什么都不動，如果我僅僅加入 server.tomcat.max-cnotallow=10 這個配置呢，那么這個時候最多能處理多少個請求？

你可能就要猜了：10 個。

是的，我重新提交 1000 個任務(wù)過來，在控制臺輸出的確實是 10 個，

圖片

那么 max-connections 這個參數(shù)它怎么也能控制請求個數(shù)呢？

為什么在前面的分析過程中我們并沒有注意到這個參數(shù)呢？

首先我們看一下它的默認(rèn)值：

圖片

因為它的默認(rèn)值是 8192，比最大線程數(shù) 200 大，這個參數(shù)并沒有限制到我們，所以我們沒有關(guān)注到它。

當(dāng)我們把它調(diào)整為 10 的時候，小于最大線程數(shù) 200，它就開始變成限制項了。

那么 max-connections 這個參數(shù)到底是干啥的呢？

你先自己去摸索摸索吧。

同時，還有這樣的一個參數(shù)，默認(rèn)是 100：

server.tomcat.accept-count=100

圖片

它又是干什么的呢？

“和連接數(shù)有關(guān)”，我只能提示到這里了，自己去摸索吧。

再等等

通過前面的分析，我們知道了，要回答“一個 SpringBoot 項目默認(rèn)能處理的任務(wù)數(shù)”，這個問題，得先明確其使用的 web 容器。

那么問題又來了：SpringBoot 內(nèi)置了哪些容器呢？

Tomcat、Jetty、Netty、Undertow

圖片

前面我們都是基于 Tomcat 分析的，如果我們換一個容器呢？

比如換成 Undertow，這個玩意我只是聽過，沒有實際使用過，它對我來說就是一個黑盒。

管它的，先換了再說。

從 Tomcat 換成 Undertow，只需要修改 Maven 依賴即可，其他什么都不需要動：

圖片

再次啟動項目，從日志可以發(fā)現(xiàn)已經(jīng)修改為了 Undertow 容器：

圖片

此時我再次執(zhí)行 MainTest 方法，還是提交 1000 個請求：

圖片

從日志來看，發(fā)現(xiàn)只有 48 個請求被處理了。

就很懵逼，48 是怎么回事兒，怎么都不是一個整數(shù)呢，這讓強(qiáng)迫癥很難受啊。

這個時候你的想法是什么，是不是想要看看 48 這個數(shù)字到底是從哪里來的？

怎么看？

之前找 Tomcat 的 200 的時候不是才教了你的嘛，直接往 Undertow 上套就行了嘛。

打線程 Dump，然后看堆棧消息：

圖片

發(fā)現(xiàn) EnhancedQueueExecutor 這個線程池，接著在這個類里面去找構(gòu)建線程池時的參數(shù)。

很容易就找到了這個構(gòu)造方法：

圖片

所以，在這里打上斷點，重啟項目。

通過 Debug 可以知道，關(guān)鍵參數(shù)都是從 builder 里面來的。

而 builder 里面，coreSize 和 maxSize 都是 48，隊列長度是 Integer.MAX_VALUE。

圖片

所以看一下 Builder 里面的 coreSize 是怎么來的。

點過來發(fā)現(xiàn) coreSize 的默認(rèn)值是 16：

圖片

不要慌，再打斷點，再重啟項目。

然后你會在它的 setCorePoolSize 方法處停下來，而這個方法的入?yún)⒕褪俏覀円业?48：

圖片

順藤摸瓜，重復(fù)幾次打斷點、重啟的動作之后，你會找到 48 是一個名為 WORKER_TASK_CORE_THREADS 的變量，是從這里來的：

圖片

而 WORKER_TASK_CORE_THREADS 這個變量設(shè)置的地方是這樣的：

io.undertow.Undertow#start

圖片

而這里的 workerThreads 取值是這樣的：

io.undertow.Undertow.Builder#Builder

圖片

取的是機(jī)器的 CPU 個數(shù)乘以 8。

圖片

所以我這里是 6*8=48。

哦，真相大白，原來 48 是這樣來的。

沒意思。

確實沒意思，但是既然都已經(jīng)替換為 Undertow 了，那么你去研究一下它的 NIO ByteBuffer、NIO Channel、BufferPool、XNIO Worker、IO 線程池、Worker 線程池...

然后再和 Tomcat 對比著學(xué)，

就開始有點意思了。

最后再等等

這篇文章是基于“一個 SpringBoot 項目能同時處理多少請求？”這個面試題出發(fā)的。

但是經(jīng)過我們前面簡單的分析，你也知道，這個問題如果在沒有加一些特定的前提條件的情況下，答案是各不一樣的。

比如我再給你舉一個例子，還是我們的 Demo，只是使用一下 @Async 注解，其他什么都不變：

圖片

再次啟動項目，發(fā)起訪問，日志輸出變成了這樣：

圖片

同時能處理的請求，直接從 Tomcat 的默認(rèn) 200 個變成了 8 個？

因為 @Async 注解對應(yīng)的線程池，默認(rèn)的核心線程數(shù)是 8。

之前寫過這篇文章《別問了，我真的不喜歡@Async這個注解！》分析過這個注解。

所以你看，稍微一變化，答案看起來又不一樣了，同時這個請求在內(nèi)部流轉(zhuǎn)的過程也不一樣了，又是一個可以鋪開談的點。

在面試過程中也是這樣的，不要急于答題，當(dāng)你覺得面試官問題描述的不清楚的地方，你可以先試探性的問一下，看看能不能挖掘出一點他沒有說出來的默認(rèn)條件。

當(dāng)“默認(rèn)條件”挖掘的越多，你的回答就會更容易被面試官接受。而這個挖掘的過程，也是面試過程中一個重要的表現(xiàn)環(huán)節(jié)。

而且，有時候，面試官就喜歡給出這樣的“模糊”的問題，因為問題越模糊，坑就越多，當(dāng)面試者跳進(jìn)自己挖好的坑里面的時候，就是結(jié)束一次交鋒的時候；當(dāng)面試者看出來自己挖好的坑，并繞過去的時候，也是結(jié)束一輪交鋒的時候。

所以，不要急于答題，多想，多問。不管是對于面試者還是面試官，一個好的面試體驗，一定不是沒有互動的一問一答，而是一個相互拉鋸的過程。