前言
- hello，大家好，我是你们的老朋友 Lorin，最近逛帖子看到一个面试题：SpringBoot 应用可以同时并发处理多少请求？看到这个问题大多数朋友也许都会回答 200，这样你也许第二天就会收到如下拒信：
- 你可能会很难疑惑，面试都答上了为什么没有通过呢？因为这个答案在一定程度上是正确的，但却不是面试官想听到的答案，看完这篇文章，你应该就知道答案了。
构建测试 SpringBoot 应用看看 200 来自哪里
- 下面我们写一个简单的 demo 测试一把，这里为了压测简单，我们收到请求后直接把线程睡眠2分钟，通过日志打印观察应用能够同时处理的请求数。
java
/**
* @description: 测试 Controller
* @author: Lorin
* @create: 2023-08-27 07:46
**/
@RestController
public class TestController {
/**
* 并发测试
* 接受并发请求，接受请求后睡眠 2 分钟阻塞线程，用于判断实例可以处理多少请求
*
* @param num 请求ID 表示已经收到多少个请求
*/
@GetMapping("/test-with-sleep")
public void testWithSleep(@RequestParam Integer num) throws InterruptedException {
System.out.println("接受到请求: " + num);
Thread.sleep(1000 * 120);
System.out.println("请求执行完成");
}
/**
* http test with no sleep
*
* @param num
*/
@GetMapping("/test1")
public void test1(@RequestParam Integer num) {
System.out.println("接受到请求: " + num);
System.out.println("请求执行完成");
}
}
/**
* @description: 并发测试
* @author: Lorin
* @create: 2023-08-27
**/
class TestControllerTest {
/**
* 为了方便测试直接起多线程并发请求测试 当然也可以用 jmeter 等压测工具
*/
@Test
void test1() {
for (int i = 0; i < 1000; i++) {
int num = i;
new Thread(() -> {
try {
URL url = new URL("http://localhost:8080/test1?num=" + num);
HttpURLConnection connection = (HttpURLConnection) url.openConnection();
connection.connect();
System.out.println(connection.getResponseCode());
connection.disconnect();
} catch (Exception exception) {
System.out.println(exception);
}
}).start();
}
}
}运行结果
-
你仔细一看200，这不正是我们需要的答案？但是我们作为一个程序员一定要知其然然后知其所以然。
-
比如面试官会接着问：
这里并发为什么是200，我们可以调整？
如果并发数小于200或者大于200是如何表现？ -
这时候也许就触及到了你的知识盲区了，不要慌马上发车，大家一起来刨根问底来知其所以然：
什么影响了 SpringBoot 应用并发处理请求数
- 先说结论：应用并发请求数主要由两个因素影响，使用的 Servlet容器（默认使用 Tomcat，常用的还有 jetty、undertow） 和 配置项。
- 所以在开头的答案我们可以优化一下：在默认配置下，SprigBoot 应用可以并发处理 200 请求。
- 这就是终极答案吗？不不不，这才是开始，继续发车接下来我们要告诉面试官，不同的 Servlet 容器的工作原理以及配置项，相信下面这些内容回答完，面试官心里的 OS 肯定是：哎哟，这小伙子懂得挺多，不错不错！！
Tomcat
原理
- 现在我们断点看一下应用的执行流程：
- 咋一看是不是很眼熟，这不是有点我们线程池的运行逻辑:任务数小于核心数，创建核心线程执行，任务数大于核心线程数，将任务放到任务队列中，任务队列满后创建非核心线程数执行。那么我们来看看几个参数的配置是多少：
vbnet
核心线程数：10
非核心线程数：200
任务队列长度：2147483647 Integer.MAX_VALUE
- 怎么肥事？我们任务队列为 Integer.MAX_VALUE ，我们才 1000 个请求，怎么创建了非核心线程，难道和 Java 的线程池不一样，回到源码中，我们再看看怎么回事：
- 这个时候我们需要看看任务是如何提交到线程池的，既然都是线程池，那么猜测 提交应该也是一样使用 execute 方法，我们断点试一下发现猜测正确：
arduino
org.apache.tomcat.util.threads.ThreadPoolExecutor#execute(java.lang.Runnable)
Java
private void executeInternal(Runnable command) {
if (command == null) {
throw new NullPointerException();
}
/*
* Proceed in 3 steps:
*
* 1. If fewer than corePoolSize threads are running, try to
* start a new thread with the given command as its first
* task. The call to addWorker atomically checks runState and
* workerCount, and so prevents false alarms that would add
* threads when it shouldn't, by returning false.
*
* 2. If a task can be successfully queued, then we still need
* to double-check whether we should have added a thread
* (because existing ones died since last checking) or that
* the pool shut down since entry into this method. So we
* recheck state and if necessary roll back the enqueuing if
* stopped, or start a new thread if there are none.
*
* 3. If we cannot queue task, then we try to add a new
* thread. If it fails, we know we are shut down or saturated
* and so reject the task.
*/
int c = ctl.get();
// 判断是否小于核心线程数 小于则创建核心线程处理任务
if (workerCountOf(c) < corePoolSize) {
if (addWorker(command, true)) {
return;
}
c = ctl.get();
}
// 判断任务是否可以放入队列中
if (isRunning(c) && workQueue.offer(command)) {
int recheck = ctl.get();
if (! isRunning(recheck) && remove(command)) {
reject(command);
} else if (workerCountOf(recheck) == 0) {
addWorker(null, false);
}
}
// 尝试创建非核心线程
else if (!addWorker(command, false)) {
reject(command);
}
}
// 既然没有放入队列中 那么我们看看为什么没有放入队列中
public class TaskQueue extends LinkedBlockingQueue<Runnable> {
@Override
public boolean offer(Runnable o) {
//we can't do any checks
if (parent==null) {
return super.offer(o);
}
//we are maxed out on threads, simply queue the object
if (parent.getPoolSize() == parent.getMaximumPoolSize()) {
return super.offer(o);
}
//we have idle threads, just add it to the queue
if (parent.getSubmittedCount()<=(parent.getPoolSize())) {
return super.offer(o);
}
//if we have less threads than maximum force creation of a new thread
if (parent.getPoolSize()<parent.getMaximumPoolSize()) {
return false;
}
//if we reached here, we need to add it to the queue
return super.offer(o);
}
}
// parent 就是我们的 tomcat 线程池，parent.getPoolSize() 返回当前线程池中的数量
// 关键在这段代码，若当前当前线程数小于最大线程数，则不放入队列中，结合上文逻辑，则进入创建非核心线程逻辑
// if we have less threads than maximum force creation of a new thread
if (parent.getPoolSize()<parent.getMaximumPoolSize()) {
return false;
}- 看完上文的代码豁然开朗，原来 Tomcat 线程池和 Java 线程池的执行逻辑并不一致，Tomcat 线程池会先创建非核心线程，当已创建线程池数量大于最大线程时才会将任务放入队列中。
配置项
- 看完 Tomcat 的原理，我们来看看 Tomacat 的常用配置是否会影响并发请求的数量，有了上面的基础，我们来看一下常用的配置项：
ini
# 非核心线程数
server.tomcat.threads.max=200
# 核心线程数
server.tomcat.threads.min-spare=10
----------------------------------
# 在拒绝连接之前可排队的连接数
server.tomcat.accept-count=100
# 非核心线程空闲时间 1 分钟
# 同时处理最大接收连接数
# maxConnections和accept-count的关系为：当连接数达到最大值maxConnections后，系统会继续接收连接，但不会超过acceptCount的值
# 当该值小于 server.tomcat.threads.max 时会影响最大可并发处理请求数
server.tomcat.max-connections=8192
# 每个连接可以处理的最大请求数
server.tomcat.max-keep-alive-requests=100
# 连接存活时间 默认使用 connection-timeout
server.tomcat.keep-alive-timeout=-1
# 连接超时时间 默认 20s
server.tomcat.connection-timeout=20000- 除 server.tomcat.threads.max 会影响并发数以外，其实 server.tomcat.max-connections 也会影响并发请求数，比如将该参数设置为 20：
- 然后回答上面的补充问题：
diff
这里并发为什么是 200，我们可以调整？
- 因为 tomcat 线程池类似 Java 线程池，但有一定区别，会先创建非核心线程后再放入队列中。
- 我们可以通过调整 最大线程数来 控制并发数量
如果并发数小于 200 或者大于 200 是如何表现？（默认配置下）
- 小于 200 会创建核心线程和非核心线程立即处理任务，大于 200 的任务会放入等待队列中undertow
如何切换 undertow 容器
- 很简单，我们只需要将原有的 tomcat 容器移除，然后引入 undertow 容器即可
xml
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
<exclusions>
<exclusion>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-tomcat</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-undertow</artifactId>
</dependency>
// 观察启动日志可以看到我们已经成功启动
2023-08-27 20:56:29.531 INFO 2618 --- [ main] org.jboss.threads : JBoss Threads version 3.1.0.Final
2023-08-27 20:56:29.575 INFO 2618 --- [ main] o.s.b.w.e.undertow.UndertowWebServer : Undertow started on port(s) 8080 (http)并发处理请求数
- 老规矩先并发请求压测一把：
- 可以看到我们同时并发处理的请求为 64，那么这个 64 是从什么地方的呢，接着往下面看，和上面 Tomcat 的思路一样先断点查看堆栈信息定位：
- org.jboss.threads.EnhancedQueueExecutor.Builder 找到创建线程池的地方：
-
可以看到 maxSize、coreSize 来自于 Builder 这个对象，我们回到 Builder 看看这两个参数来自哪里：
-
org.jboss.threads.EnhancedQueueExecutor.Builder
-
我们看到 maxSize、coreSize 原始值为 64、16，那么是在哪里改变的呢？接着往下断点，我们可以找到：
-
org.xnio.XnioWorker#XnioWorker 中创建了 修改了 Builder 创建了 EnhancedQueueExecutorTaskPool：
- 那么这里的值又是从哪里来的呢？继续往上找 io.undertow.Undertow#start 发现在这里调用
- io.undertow.Undertow.Builder#Builder 构建
- 可以看到默认会根据机器可用的 CPU 数 * 8 计算一个 workerThreads 作为最大线程数和核心线程数，我电脑的 CPU 数为 8，因此最大线程数和核心线程数都为 64。
- 同时，线程池基于 Java 线程池实现，因此当等待队列未满时使用仅使用核心线程池。
配置项
ini
# 线程数 核心线程和非核心线程都使用该值
server.undertow.threads.worker=5你以为这就结束了？
- 也许这才是下一个问题的开始，面试官会问你几种 Servlet 容器的优缺点、IO 实现是否一致，以及各自的适用场景、如何进行参数调优等等，后面的内容我们下期见吧。