tomcat并发能力由connector与线程池分层协作决定：maxconnections是操作系统级最大tcp连接数（建议8000–12000，≤ulimit -n），acceptcount是线程忙时的排队缓冲长度（推荐maxthreads×0.5～1.0），二者层级不同、不可混用。
Tomcat 的并发能力主要由 Connector 和线程池协同决定，二者不是简单“一对一”关系，而是分层协作：Connector 负责接收和排队连接，线程池负责实际处理请求。配置失衡会导致资源浪费或请求拒绝。
maxConnections 与 acceptCount 的区别与配合
这两个参数常被混淆，但作用层级不同：
-
maxConnections：操作系统级最大连接数，表示 Tomcat 允许同时建立的 TCP 连接总数（含已建立、正在握手、等待处理的连接），受系统文件描述符限制（
ulimit -n）约束，建议设为 8000–12000（需 ≤ ulimit 值）。 -
acceptCount：当所有工作线程都忙时，新连接可进入的“等待队列”长度。它不占用线程，只是排队缓冲；超过此值的新连接会被直接拒绝（返回 Connection refused 或 503）。推荐设为
maxThreads × 0.5～1.0，例如 maxThreads=400 时，acceptCount 可设 200–400。
注意：acceptCount 不是“并发请求数”，而是“排队请求数”。真正并发处理的上限取决于 maxThreads。
maxThreads 与 minSpareThreads 的合理取值
线程数不是越多越好，需兼顾 CPU 利用率与上下文切换开销：
- maxThreads：默认 200，生产环境建议按 CPU 核心数估算——4 核配 200～300，8 核配 400～600，16 核及以上可到 800。实测中某电商将 maxThreads 从 200 提至 400，TPS 提升 133%（1200→2800），但继续加到 600 后提升趋缓甚至下降。
- minSpareThreads：保持常驻的空闲线程数，避免突发流量时频繁创建线程。建议设为 maxThreads 的 20%～30%，如 maxThreads=400，则 minSpareThreads=80～120。
- 启用 prestartminsparethreads="true"，让 Tomcat 启动时就预热这些线程，降低首请求延迟。
NIO/NIO2 协议对连接效率的影响
协议选择直接影响连接模型和线程复用效率：
- BIO（已淘汰）：每个连接独占一个线程，无法应对高并发，仅适合调试或极低负载场景。
- NIO：基于 Reactor 模型，少量线程可管理大量连接，适合中高并发（万级以内）。
-
NIO2（推荐）：Java 7+ 引入的异步 I/O，进一步减少阻塞等待，在 10k+ 并发下比 NIO 吞吐量高 15%～30%，内存占用更低。配置 protocol 为
org.apache.coyote.http11.Http11Nio2Protocol即可启用。
搭配 NIO2 使用时，maxConnections 可设更高（如 12000），因连接本身不绑定线程。
线程池任务队列的隐性风险
Tomcat 默认使用无界队列（maxQueueSize=Integer.MAX_VALUE），看似安全，实则危险：
- 请求积压会持续占用内存，可能触发 OOM。
- 长队列导致响应延迟不可控，用户感知为“卡顿”而非失败。
- 生产环境应显式限制队列大小，例如在自定义 Executor 中设置
maxQueueSize="500"，或使用LinkedBlockingQueue限定容量。
若用内置线程池（未声明 Executor），可通过 <connector executor="xxx"></connector> 绑定已配置队列的 Executor，避免默认无界行为。
