面经策

SpringBoot 默认同时可以处理的最大请求数是多少？ ​

  • 标签：Spring Boot、后端

🏛 业务架构师 ​

这道题要拆成两层回答，因为它问的其实是"瓶颈在哪"：

1. Web 容器层（真正约束并发的是连接与线程）：

  • Tomcat 默认 max-connections=8191、accept-count=100、最大工作线程 200；
  • 同步阻塞模型下，同时在处理的请求上限 ≈ 200——注意不是"8191 个都能处理"，超过 200 的排队等线程。

2. 业务吞吐的真实天花板：

  • 假设平均 RT 50ms，200 线程理论上限约 4000 QPS；依赖变慢（RT 500ms）时瞬间跌到 400 QPS——慢依赖才是压垮吞吐的主因，线程参数只是放大器；
  • 再往下还有数据库连接池（默认 Hikari 10 个连接）、下游服务、Redis 的限制，整条链路取最小值。

架构师视角，我的容量规划方法论：

  1. 从业务峰值倒推：大促目标 QPS → 除以可接受 RT → 得到需要的线程数与连接数，逐层配置（Tomcat 线程、Hikari 池、下游连接池），容量设计是端到端的，单点调优无意义；
  2. 线程不是越大越好：过多线程带来上下文切换和内存开销，RT 恶化的系统加线程等于加速雪崩——先治慢（SQL、外部调用超时控制）再加线程；
  3. 2026 的关键选项：JDK 21+ 虚拟线程（spring.threads.virtual.enabled=true）让"一请求一虚拟线程"成为默认，阻塞模型下的线程焦虑大幅缓解——升级 JDK 的收益可能超过一切参数调优。

🏗 系统架构师 ​

结论先行：没有单一「最大请求数」，由三层参数共同决定（默认 Tomcat）：

  • server.tomcat.threads.max=200：并发处理线程上限——真正同时处理请求的最大并发；
  • server.tomcat.max-connections=8191：可接受的连接数；
  • server.tomcat.accept-count=100：连接满后的排队 backlog。

默认下「正在处理」不超过 200，等待连接最多 8191 加 100。

容量推导（我按 Little's Law 教团队）：吞吐 = 并发线程数 ÷ 平均响应时间。200 线程、50ms 响应，理论上限约 4000 QPS；下游劣化到 2s 时吞吐塌到 100 QPS 且线程打满。线程数不是越大越好——受 CPU 核数与下游约束（Hikari 默认只有 10 个连接！）。

架构动作：压测得出真实水位；线程数与下游容量（连接池、缓存、下游服务）联动规划；超载行为显式设计——快速拒绝 429 优于排队雪崩；JDK 21 虚拟线程开启后模型改变（并发不再被 200 线程卡住，瓶颈转移到下游）。

💻 全栈开发专家 ​

这题不是单值，要拆成 Tomcat 的流水线三参数：

yaml
server:
  tomcat:
    threads:
      max: 200              # 工作线程池上限（默认 200）
    max-connections: 8192   # 同时可接受的最大连接数（默认 8192）
    accept-count: 100       # 连接满后的等待队列（默认 100）

含义链：accept-count 排队 → max-connections 握上 → threads.max 个线程处理。所以"同时在处理"的上限是 200，瞬时排队容量约 max-connections + accept-count，超出直接拒绝连接。

三个现实补充：

  1. 虚拟线程（Boot 3.2+）：spring.threads.virtual.enabled=true 后请求由虚拟线程承载，线程数不再是 200 这种小数字，吞吐约束转移到下游（DB 连接池 HikariCP 的 maximum-pool-size 才是新瓶颈）——压测重点随之前移
  2. 参数怎么定：k6/wrk 阶梯加压，盯 tomcat.threads.busy 指标和下游 RT；盲目调大线程只会把压力打到数据库
  3. 排查"请求挂起"：/actuator/metrics/tomcat.threads.busy + threaddump，绝大多数是慢 SQL 拖住工作线程——先治下游再谈容器参数