经典面试题：SpringBoot 应用可以同时并发处理多少请求

最新推荐文章于 2024-04-22 13:56:50 发布

Lorin 洛林

最新推荐文章于 2024-04-22 13:56:50 发布

阅读量267

点赞数 3

分类专栏： Spring Java 后端经典面试题文章标签：后端 java spring 面试

本文链接：https://blog.csdn.net/qq_35578171/article/details/133523006

版权

Java 后端经典面试题同时被 2 个专栏收录

30 篇文章 0 订阅

订阅专栏

Spring

5 篇文章 0 订阅

订阅专栏

文章目录

前言
构建测试 SpringBoot 应用看看 200 来自哪里
- 运行结果
什么影响了 SpringBoot 应用并发处理请求数
你以为这就结束了？

前言

hello，大家好，我是你们的老朋友 Lorin，最近逛帖子看到一个面试题：SpringBoot 应用可以同时并发处理多少请求？看到这个问题大多数朋友也许都会回答 200，这样你也许第二天就会收到如下拒信：

面试拒信.png

你可能会很难疑惑，面试都答上了为什么没有通过呢？因为这个答案在一定程度上是正确的，但却不是面试官想听到的答案，看完这篇文章，你应该就知道答案了。

构建测试 SpringBoot 应用看看 200 来自哪里

下面我们写一个简单的 demo 测试一把，这里为了压测简单，我们收到请求后直接把线程睡眠2分钟，通过日志打印观察应用能够同时处理的请求数。

/**
 * @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是如何表现？

这时候也许就触及到了你的知识盲区了，不要慌马上发车，大家一起来刨根问底来知其所以然：

一切正常马上发车.jpg

什么影响了 SpringBoot 应用并发处理请求数

先说结论：应用并发请求数主要由两个因素影响，使用的 Servlet容器（默认使用 Tomcat，常用的还有 jetty、undertow）和配置项。
所以在开头的答案我们可以优化一下：在默认配置下，SprigBoot 应用可以并发处理 200 请求。
这就是终极答案吗？不不不，这才是开始，继续发车接下来我们要告诉面试官，不同的 Servlet 容器的工作原理以及配置项，相信下面这些内容回答完，面试官心里的 OS 肯定是：哎哟，这小伙子懂得挺多，不错不错！！

听到了引擎声.jpg

Tomcat

原理

现在我们断点看一下应用的执行流程：

在这里插入图片描述

咋一看是不是很眼熟，这不是有点我们线程池的运行逻辑:任务数小于核心数，创建核心线程执行，任务数大于核心线程数，将任务放到任务队列中，任务队列满后创建非核心线程数执行。那么我们来看看几个参数的配置是多少：

核心线程数：10
非核心线程数：200
任务队列长度：2147483647  Integer.MAX_VALUE

怎么肥事？我们任务队列为 Integer.MAX_VALUE ，我们才 1000 个请求，怎么创建了非核心线程，难道和 Java 的线程池不一样，回到源码中，我们再看看怎么回事：
这个时候我们需要看看任务是如何提交到线程池的，既然都是线程池，那么猜测提交应该也是一样使用 execute 方法，我们断点试一下发现猜测正确：

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

在这里插入图片描述

    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 的常用配置是否会影响并发请求的数量，有了上面的基础，我们来看一下常用的配置项：

# 非核心线程数
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：

然后回答上面的补充问题：

这里并发为什么是 200，我们可以调整？
- 因为 tomcat 线程池类似 Java 线程池，但有一定区别，会先创建非核心线程后再放入队列中。
- 我们可以通过调整 最大线程数来 控制并发数量

如果并发数小于 200 或者大于 200 是如何表现？（默认配置下）
- 小于 200 会创建核心线程和非核心线程立即处理任务，大于 200 的任务会放入等待队列中

undertow

如何切换 undertow 容器

很简单，我们只需要将原有的 tomcat 容器移除，然后引入 undertow 容器即可

        <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 线程池实现，因此当等待队列未满时使用仅使用核心线程池。

配置项

# 线程数 核心线程和非核心线程都使用该值
server.undertow.threads.worker=5

你以为这就结束了？

也许这才是下一个问题的开始，面试官会问你几种 Servlet 容器的优缺点、IO 实现是否一致，以及各自的适用场景、如何进行参数调优等等，后面的内容我们下期见吧。

Lorin 洛林

关注

3
点赞
踩
3

收藏

觉得还不错? 一键收藏
打赏
0
评论
经典面试题：SpringBoot 应用可以同时并发处理多少请求

hello，大家好，我是你们的老朋友 Lorin，最近逛帖子看到一个面试题：SpringBoot 应用可以同时并发处理多少请求？看到这个问题大多数朋友也许都会回答 200，这样你也许第二天就会收到如下拒信
复制链接

扫一扫