Spring Boot 中 server.tomcat.accept-count 控制 Tomcat 内核 TCP 等待队列（backlog）长度，默认 100；当 max-threads 线程全忙时，新请求入队，队满则内核拒绝连接（RST），实际值受 OS net.core.somaxconn 限制。
Spring Boot 中通过 server.tomcat.accept-count 配置项可直接控制 Tomcat 内嵌容器的等待队列长度，该值对应底层 `StandardServer` 中 `Connector` 的 acceptCount 属性，本质是操作系统 TCP 连接等待队列（即 `backlog`）的上限。
理解 accept-count 的实际作用
它不是 Spring Boot 自定义的抽象概念，而是直译 Tomcat 原生配置：当所有工作线程（server.tomcat.max-threads）都在忙时，新连接请求会被放入等待队列；队列满后，后续连接将被内核拒绝（RST 包），客户端收到 “Connection refused”。该值默认为 100，但生产环境常需根据并发模型和 SLA 调整。
在 application.yml 中设置
只需在配置文件中声明：
server:
tomcat:
accept-count: 200
max-threads: 200
min-spare-threads: 20
注意：accept-count 必须配合 max-threads 协同评估。例如设为 200 时，理论最大待处理连接 = 工作线程数 + 等待队列长度 = 200 + 200 = 400（不含已建立但未 dispatch 的连接）。但真实吞吐还受 I/O 模型、业务耗时、GC 等影响，不能简单线性叠加。
立即学习“Java免费学习笔记（深入）”；
避免常见误配陷阱
- 不要盲目调大：过大的 accept-count 会延长请求排队时间，掩盖线程瓶颈，导致平均延迟上升甚至雪崩；尤其在响应慢的服务中，积压队列反而加剧资源争用。
-
注意 OS 层限制：Linux 的
net.core.somaxconn默认常为 128，若accept-count > somaxconn，Tomcat 启动时会自动截断并打印 WARN 日志（如 “acceptCount value of 512 is greater than max value of 128”），实际生效值仍为 128。 -
不适用于 NIO/NIO2 连接器的“队列”语义：Tomcat 8.5+ 默认使用 NIO，此时
accept-count控制的是内核 listen queue 长度，而非 Java 层队列；Java 层无独立等待队列，连接由 poller 线程快速 dispatch 给 executor，因此该参数更偏向系统级调优而非应用层缓冲。
验证与观测建议
启动后可通过 Actuator 的 /actuator/metrics/tomcat.connections.active 和 /actuator/metrics/tomcat.connections.current 对比观察活跃连接与总连接趋势；若发现 connections.rejected 指标持续增长，说明队列已满或线程不足，需结合线程池监控（如 tomcat.threads.busy）综合判断瓶颈所在。
