关于springboot内置tomcat最大请求数配置的一些问题

前言

springboot内置了tomcat。那么一个springboot web应用，最大的请求链接数是多少呢？很早以前就知道这个是有个配置，需要的时候，百度一下即可。但，事实并非如此，有几个问题我想大多数人还真不知道。比如：

为什么会有最大连接数和等待队列两个配置：要限制最大链接，用一个最大连接数限制即可，搞个等待队列有什么用呢？（我看网上有说，就像是餐厅有在餐厅里等待上菜的（最大链接数），也有在外坐小板凳排队的（等待队列），但，餐厅这么设计，可以说是由于实际场地等因素，那程序呢？它考虑的是什么？）
有两个应用A、B，A调用B的一个接口，A在http请求方法的开始和结尾记录了时间，相减得到值是20s，B方法在controller方法的开头和结尾(或者AOP拦截)也记录了时间是10s，如果认为接口15s以内都是正常的，那么B就会认为自己的接口正常，A认为B的接口不正常。那么这差的10s问题出在哪里？

说明：

有些结论叙述不太准，但是这并不重要，理解所表达的意思即可，不要纠结一个答案；
有些配置的默认值，或者结论现象和网上其他说法不同，不必怀疑，可能大家都是对的，我们的环境不同罢了。

正文

关于spirngboot内置tomcat的最大请求数，大体有如下四个配置：（后续配置中，如不特殊说明，都是按照这个参数值来进行验证）

#最少的工作线程数，默认大小是10
server.tomcat.threads.min-spare=1
#最多的工作线程数，默认大小是200
server.tomcat.threads.max=2
#最大连接数，默认大小是8192。表示Tomcat可以处理的最大请求数量，超过8192的请求就会被放入到等待队列。
server.tomcat.max-connections=2
#等待队列的长度，默认大小是100。
server.tomcat.accept-count=4

结论

先直接上结论，后续一一用代码来实际论证：

最小工作线程数server.tomcat.threads.min-spare是一个优化配置，应用启动就会创建相应数目的线程（不管有没有请求），这些线程是不会被销毁的，而server.tomcat.threads.max是在请求的任务数多的时候，会临时创建的线程，之后这些线程会被销毁；
最大可接受的请求数为：server.tomcat.max-connections + server.tomcat.accept-count,超过该数目会拒绝请求；
最多能同时工作的线程数是：server.tomcat.threads.max
如果配置server.tomcat.max-connections 小于server.tomcat.threads.max，那么实际中创建的任务线程数应该是：server.tomcat.max-connections
最大连接数中的请求没有处理完之前，是不会处理等待队列中的请求的；
假如把最大连接数和等待队列都看作容器：那么
- 并非是要等最大链接数中的链接，全部处理完了，才会处理等待队列中的链接，而是最大链接容器中，有空位了，等待队列中就会有个链接进入最大链接容器，从而又可以接受一个新的链接了（debug源码发现：其实接受最大链接的池子是一个无限队列，但是通过server.tomcat.max-connections来控制这个最多能容纳的链接，当等于max-connections之后，新的链接就会进入等待队列，判断是否拒绝链接，是判断当前请求中，server.tomcat.accept-count的值是否大于等于配置值，如果是就拒绝链接）
- 等待队列的存在是有意义的，特别是在异步请求

论证

这里我准备了一个接口，不考虑其他代码（如拦截器、过滤器之类的）的执行耗时，就认为这个接口的耗时时间为10s：

@GetMapping("/test10")
public String test10() throws InterruptedException {
    log.info("当前线程test10：{}.", Thread.currentThread().getName());
    Thread.sleep(10000);
    return "test10s";
}

应用启动就会创建`min-spare`个线程

依次将server.tomcat.threads.min-spare设置为1、2、3，会发现项目启动后，就会创建对应多个数目的线程数（不要将该数值设置的大于server.tomcat.threads.max），当链接超过了这个最小的线程数之后，就会再创建线程，但是不会超过最大链接数，这些线程最终会被销毁（项目启动时创建的server.tomcat.threads.min-spare的线程却不会被销毁）

最大可接受请求数：server.tomcat.max-connections + server.tomcat.accept-count

现在配置的server.tomcat.max-connections + server.tomcat.accept-count 为7，那么发起7个请求，就应该有6个请求得到正常响应，一个请求被拒绝：

最多能同时工作的线程数是：server.tomcat.threads.max

同样，用上面的验证结果，看响应时间：

我配置的server.tomcat.threads.max为2，意味着同时有两个线程会执行请求。那么，接口耗时10s，每两个线程的响应时间是相同的，两两之间相差10秒。

想一下开头说的：A、B两应用接口调用有10s的时间对不上，也许有一种可能就是这里：从接口打印的时间来看，是10秒，但是实际的响应却是10s、20s、30s。

由此可见：有些项目所谓的接口响应时间的记录，其实仅仅是记录的业务代码的执行时间。对于请求方而言，并非接口的响应时间。知道这个，对于分析问题，又多了一种思路了。

如果配置`server.tomcat.max-connections` 小于`server.tomcat.threads.max`，那么实际中创建的任务线程数应该是：`server.tomcat.max-connections`

这种配置法，在实际中是不存在的，我想，应该不会有人这么干吧！！！

server.tomcat.threads.min-spare=1
server.tomcat.threads.max=3
server.tomcat.max-connections=2
server.tomcat.accept-count=4

依然是7个请求并发，结果一个失败，6个成功，耗时30秒：

看这个图，时间依旧是两两一组，说明虽然允许最多创建3个任务线程，但是实际最大链接有2个，那么也认为只有两个任务要执行，而不会管等待队列中的任务。只有等最大链接池中的任务有执行完的了，才会让等待队列中的任务进来。
如果把server.tomcat.threads.min-spare设置为3，结果也是一样的。

最大连接数中的请求没有处理完之前，是不会处理等待队列中的请求的

这个结论是在其他地方看到的，当时一直不理解：假如最大链接数中有10个请求，等待有2个，那么必须要等到这10个请求全部完成了，才会处理等待队列的两个吗？其实，这句话的意思应该是，创建出的线程只会处理最大连接数中的请求，当有一个请求完了之后，才会让等待队列中的请求进来，然后然后又被任务线程处理。即便有空余的任务线程，也不会处理等待队列中的请求。在：

如果配置server.tomcat.max-connections 小于server.tomcat.threads.max，那么实际中创建的任务线程数应该是：server.tomcat.max-connections

已经论证了。

等待队列存在的作用

虽然之前也有说了，最大连接数中的请求没有处理完之前，是不会处理等待队列中的请求的，但这个作用意义不大，毕竟在实际中，不会有人配置工作线程数小于最大线程数。
所以，从以上现象中看，这个等待队列的意义不大（从我的测试结果看，这个确实没有啥意义，但是如果看源码，它还是有作用的，但我认为按照官方指导数来配置就可以了，理解它的作用比较抽象），除非————使用异步请求。

之前的接口，都是同步请求的：工作线程从最大链接容器中拿取一个人请求处理，处理完之后，再拿取下一个，它所针对的是最大链接，和等待队列没有关系，但等待队列看到最大链接中有空位了，就安排它的一个链接请求去补位，所以，从这里看它的存在意义不大。

但如果是异步请求中，这个等待队列就有意义了：如之前所说，工作线程只管最大请求链接中的请求。那么如果我允许项目的最大链接说是10，只有一个参数控制这个值的话，在异步线程中几乎可以认为会同时处理10个请求，但有了等待队列，则可以控制同时处理的请求数了。描述的不是很准确，直接看结果：增加一个异步请求接口和之前的同步请求逻辑一样，从客户端的角度看，这两个接口都是耗时10s：

@GetMapping("/testCallAble")
public Callable<String> testCallAble(){
    return () -> {
        log.info("当前线程：{}.", Thread.currentThread().getName());
        Thread.sleep(10000);
        return "hello";
    };
}

使用如下配置参数，依次请求两个接口：7个并发请求：

server.tomcat.threads.min-spare=1
server.tomcat.threads.max=2
server.tomcat.max-connections=4
server.tomcat.accept-count=2

异步请求结果：1个请求失败，总耗时20秒：有4个请求（server.tomcat.max-connections的值）是同一时间返回的：说明任务线程由于异步请求，它空闲出来之后会处理最大链接数中的其他请求，但是不会处理等待队列中的请求。如果没有等待队列，那么就会造成这个异步线程会一下处理6(server.tomcat.max-connections+server.tomcat.accept-count)个请求链接的业务方法,这个时候可能服务器没有足够的资源。