Tomcat 核心参数详解
在 Java Web 开发中，Tomcat 的性能调优往往取决于对底层 IO 模型和线程模型的理解。除了基础的 IO 模式选择外，三个关键配置项直接决定了服务的并发处理能力：maxConnections、maxThreads 和 acceptCount。
为什么需要关注这些配置？
很多开发者在遇到性能瓶颈时，第一反应是增加服务器硬件，其实很多时候调整 Tomcat 的线程池和连接队列就能解决问题。这三个参数分别对应了连接的上限、处理请求的能力以及排队缓冲的大小。
关键参数解析
maxConnections：最大连接数
这是 Tomcat 在同一时刻能够接受的最大连接数。对于 BIO 模式，默认值通常等于 maxThreads；而在 NIO 模式下，默认值通常是 10000。
如果设置为 -1，则不限制连接数。需要注意的是，当连接数达到上限后，系统行为取决于 acceptCount 的设置。在 Windows 上如果使用 APR/native IO 模式，默认值为 8192，且配置值如果不是 1024 的倍数会被自动向下取整。
maxThreads：最大线程数
每个 HTTP 请求到达时，Tomcat 会分配一个线程处理。这个参数限制了容器同时能处理的请求数量。
默认值是 200，但生产环境建议根据内存大小调整。创建线程是有成本的，包括上下文切换开销和 JVM 栈内存（默认 1MB/线程）。经验法则如下：
- 1 核 2G 内存：线程数约 200
- 4 核 8G 内存：线程数约 800
盲目增加线程数会导致频繁的 GC 和 CPU 上下文切换，反而降低吞吐量。
acceptCount：最大等待数
当所有工作线程都在忙碌时，新的请求会被放入等待队列。acceptCount 定义了队列的最大长度，默认值为 100。
一旦队列也满了，新来的请求就会被拒绝，客户端通常会收到 Connection refused 错误。合理设置这个值可以应对突发流量，但过大的队列会掩盖服务过载的问题，导致响应时间过长。
形象化理解：火锅店模型
为了更直观地理解这三者的关系，我们可以把 Tomcat 比作一家火锅店：
- maxConnections（餐桌数）：代表大堂里能坐下的顾客总数。桌子坐满了，就不能再进人了。
- maxThreads（厨师数）：代表后厨炒菜的师傅。每个厨师一次只能忙一道菜，相当于一条线程。顾客再多，厨师不够也得等。
- acceptCount（排号数）：代表门口能拿到的排队号码数量。如果没座位了，还能在外面排队，但排号也有上限。
流程逻辑：
- 如果还有空桌（
maxConnections未满），顾客直接入座点菜。 - 如果桌子满了但没满号（
acceptCount未满），顾客拿号排队，有空桌再叫号。 - 如果号也发完了，服务员会说'客满'，直接拒绝进入（返回 Connection refused）。
- 即使有座位，如果厨师忙不过来（
maxThreads已满），上菜速度就会变慢，体验下降。
配置建议
在 Spring Boot 应用中，可以通过 application.yml 进行配置。以下是一个针对中等规模服务的参考示例：
server:
tomcat:
uri-encoding: UTF-8
# 最大工作线程数，默认 200，根据内存调整
max-threads:
