破除“并发死锁”关键在于平衡maxthreads与acceptcount：前者是处理线程上限，后者是tcp连接排队缓冲区长度；需结合maxconnections、超时配置及真实压测反馈调优，避免盲目增大参数导致雪崩。
破除“并发死锁”不是Tomcat本身的死锁，而是因线程池与队列配置失衡导致的请求堆积、超时、拒绝服务等表象。关键不在“解死锁”，而在让连接接纳、线程调度、资源等待三者形成可预期、有缓冲、不雪崩的流水线。maxThreads 和 acceptCount 是这条流水线最前端的两个控制阀。
理解 maxThreads 与 acceptCount 的真实分工
很多人误以为 acceptCount 是“备用线程数”，其实它完全不参与处理——它只是 TCP 连接进入 Tomcat 后、尚未分配到线程前的**排队缓冲区长度**（对应 ServerSocket 的 backlog 队列）。而 maxThreads 才是真正干活的线程上限。
- 当请求数 ≤ maxThreads：直接分配空闲线程或新建线程处理
- 当请求数 ＞ maxThreads 但排队数 ＜ acceptCount：请求进队列，等线程空闲
- 当排队数已达 acceptCount：新连接被内核直接拒绝（RST 包），返回 Connection refused
避免“假性死锁”的配置逻辑
所谓“死锁感”，常出现在压测中响应陡降、大量超时、监控显示线程全忙但 CPU 不高——本质是 I/O 等待长（如数据库慢查、远程调用卡顿），线程被长期占用，新请求在 acceptCount 队列里干等，最终超时或被丢弃。此时调大 maxThreads 并不能解决问题，反而加剧上下文切换和内存争用。
- 先确认瓶颈类型：用 jstack -l
查看线程堆栈，若大量线程处于 BLOCKED 或 WAITING on java.lang.Object，说明是同步锁或外部依赖阻塞；若大量为 TIMED_WAITING (parking) 或 JDBC getConnection，则是资源池/DB 瓶颈 - acceptCount 不宜远大于 maxThreads：设为 maxThreads × 0.8～1.2 较稳妥。例如 maxThreads=200，acceptCount=160～240。设成 10000 只会让请求在队列里“慢性死亡”，掩盖真实问题
- maxThreads 要匹配应用特性：纯计算型服务（如加解密、图像处理）建议 ≤ CPU 核数 × 2；IO 密集型（含 DB、HTTP 调用）可设为 CPU 核数 × 5～10，但必须配合连接池、超时、熔断等下游保护
搭配 maxConnections 实现端到端流控
仅调这两个参数不够。Tomcat 实际承载能力由三者共同决定：maxConnections（NIO 最大连接数） + acceptCount（队列深度） ≈ 系统能持有的总连接态请求数。若 maxConnections 过小（如默认 8192），即使 acceptCount=1000，连接也早在进入队列前就被内核丢弃。
- 对 HTTP/1.1 长连接场景：maxConnections 建议 ≥ maxThreads × 2（考虑连接复用）
- 对 HTTP/2 或短连接高频场景：maxConnections 可接近 maxThreads，但需确保后端（如 DB 连接池）能承接
- 务必同步设置 connectionTimeout="20000" 和 keepAliveTimeout="15000"，防止僵尸连接占满 maxConnections
用压力反馈代替经验公式
不要迷信“CPU 核数 ×（1 + 平均等待时间/平均服务时间）”这类理论公式。生产环境的真实阻塞系数无法静态估算。正确做法是：
- 从默认值起步（maxThreads=200, acceptCount=100）
- 用 wrk 或 JMeter 模拟真实流量（含慢查询、失败重试、混合读写）
- 观察三项指标：线程池活跃线程数是否持续顶格、acceptCount 队列是否频繁打满、错误率是否随并发阶梯上升
- 每次只调一个参数，记录 P95 响应时间与错误率拐点。通常最优解出现在活跃线程稳定在 maxThreads 的 70%～85%，且 acceptCount 使用率＜30%
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
