Tomcat 从 Socket 到 Servlet：机制主线、参数调优与线上排障（实战）

目标你能把 Tomcat 的请求链路、线程模型、关键参数、常见故障串成一套可解释、可排障、可背诵的完整体系。1. 先建立一张“主线地图”一次 HTTP 请求进入 Tomcat大体走这条链路Connector对外提供协议入口HTTP/1.1、AJP 等Endpoint网络模型与 I/O 事件循环NIO/NIO2/APRProcessor协议解析把字节流解析成 request/response 语义AdapterCoyoteAdapter把 Coyote Request 适配成 Catalina 的 Request进入容器ContainerEngine/Host/Context/Wrapper定位到目标 Servlet走 Filter/Servlet你把这条链路讲清楚面试和排障基本都能兜住。2. Connector协议入口 线程模型的外壳Connector 不只是“端口监听”。它管理监听端口与协议org.apache.coyote.http11.Http11NioProtocol等Endpoint网络 I/O 与 acceptor/pollerProcessor协议解析器面试重点Connector 是网络层与容器层的桥梁网络事件由 Endpoint 驱动协议解析由 Processor 完成3. EndpointNIO 模型里最关键的三类线程以 NIO 为例你通常会看到Acceptoraccept()新连接Pollerselect()监听可读/可写事件Executor/Worker业务线程池真正执行请求处理容器链路直觉Poller 负责“发现有哪些 socket 可读”Worker 负责“读数据、解析协议、执行业务、写回响应”实际实现可能分配在不同阶段但从排障看这样理解最稳4. Processor把字节流变成 HTTP 语义Processor 主要做解析请求行/请求头method、uri、headers处理 keep-alive、chunked生成内部的 Request/Response 对象Coyote 层常见现象与原因请求头过大/行过长触发 400/连接被关闭看maxHttpHeaderSize等限制keep-alive 连接堆积连接多但 QPS 不高关注 keepAliveTimeout、maxKeepAliveRequests5. AdapterCoyote - Catalina 的关键“转接”当 Processor 解析完协议会通过CoyoteAdapter进入容器构造/复用 Catalina Request/Response调用容器 pipelineEngine-Host-Context-Wrapper从排障角度如果你看到 Tomcat 线程栈卡在容器 pipeline/Filter/Servlet就说明“网络层已完成”瓶颈在应用层6. 线程模型与容量模型三段式理解对典型 NIO Connector可以用“3 段”理解吞吐上限连接建立accept backlog排队等 accept请求处理排队worker 线程池执行 servlet下游瓶颈DB/缓存/HTTP 调用决定平均处理时长核心公式直觉版吞吐 ≈ 线程数 / 平均处理时长平均处理时长由应用与下游决定不是靠 Tomcat 魔法消失。7. 关键参数maxThreads、acceptCount、connectionTimeout、keepAlive7.1 maxThreads不是越大越好maxThreads业务线程池上限请求真正执行的线程风险太小线程池满 - 排队变长 - RT 上升太大上下文切换、GC 压力、下游被打爆 - 反而更慢建议先测出你的“单机可用 CPU”与“下游承载”把maxThreads定在“让 CPU 接近但不打满、且下游不崩”的区间7.2 acceptCount队列满了会怎样acceptCount当所有处理线程忙时新连接/新请求的等待队列长度不同版本/实现细节略有差异但排队含义成立现象队列满客户端看到连接失败/超时/502/503取决于前置网关与客户端对照组错只调大acceptCount让请求在 Tomcat 堆很久RT 爆炸对把排队控制在合理范围配合上游限流/快速失败7.3 connectionTimeout别把“慢”变成“永远不释放”connectionTimeout读取请求行/首包等待超时常被误用典型坑设太大慢客户端/攻击连接占用资源slowloris 类问题设太小弱网/大请求容易误杀7.4 keepAliveTimeout / maxKeepAliveRequests连接多但 QPS 不高的根因keep-alive 的收益复用连接减少握手成本但也会带来大量空闲连接占用 fd 与内存建议连接多但 QPS 低重点看 keepAliveTimeout 是否过大和上游Nginx/网关的 keep-alive 策略对齐8. 可复现实验用线程栈看你卡在网络层还是业务层实验 A业务慢线程栈卡在你的 Controller/DAO现象RT 高、Tomcathttp-nio-...-exec-*线程大量 RUNNABLE/BLOCKED线程栈在业务方法/锁/DB 调用处实验 B连接堆积线程栈更多在 Poller/Socket read现象连接数高但 QPS 不高线程栈大量线程在 socket read/select不同版本栈细节不同9. 对照组线程数调大就一定能抗更多并发吗错直觉maxThreads越大越好正确理解线程太多会增加上下文切换如果瓶颈在 DB/下游线程越多只会把压力放大并堆积正确做法用压测找到 CPU/GC/DB 的瓶颈让 Tomcat 线程池大小与下游能力匹配10. 连接器NIO vs NIO2 vs APR 的区别10.1 差异集中在 Endpoint 层Connector 结构里协议HTTP/1.1与容器链路基本一致差异主要体现在Endpoint的 I/O 模型你可以把它理解为NIO/NIO2/APR 都是在“怎么收发字节”上不同上层 Processor/Adapter/Container 的主线不变10.2 NIOSelector 驱动成熟且默认特征使用 selector 监听读写事件acceptor poller worker 这套模型清晰适用绝大多数场景默认就够用常见坑误以为 NIO 就不会阻塞业务线程依旧可能阻塞在 DB/下游盲目提高线程导致上下文切换10.3 NIO2异步 IO但不等于“必然更快”特征基于 NIO.2 的异步通道更偏“回调/异步完成”模型注意点业务处理仍然需要线程最终还是要执行 servlet是否更快取决于具体负载、JDK 实现、线程配置实战建议如果没有明确证据与收益预期优先使用 NIO10.4 APR本地库 OpenSSL收益与成本并存可能收益TLS/加密相关性能更好尤其是某些版本/配置下成本与风险需要安装 Tomcat Native环境差异更大Windows/Linux、lib 版本、权限出问题更难排查native 层适用对 TLS 性能/特性有明确诉求且有能力维护本地依赖10.5 对照组你应该怎么选追求“稳定与可维护”选 NIO默认有明确 async io 收益评估再尝试 NIO2有明确 TLS 诉求且能维护 native考虑 APR11. 类加载机制与热部署为什么会内存泄漏11.1 Tomcat 的类加载是“隔离 可卸载”的设计Tomcat 需要同时运行多个 web 应用多个 war因此需要应用之间类隔离应用 reload/undeploy 后尽量能卸载 class 与相关资源核心实现每个 Web 应用有自己的WebAppClassLoader或相关实现11.2 类加载层级文字版常见层级不同版本细节略有差异但逻辑一致Bootstrap / Platform / SystemJDKCommonTomcat 公共库Catalina容器WebAppClassLoader每个应用一份关键点Web 应用的 class 通常优先从自己的 classpathWEB-INF/classes、WEB-INF/lib加载这样同名类不会互相污染11.3 热部署/重载是怎么工作的直觉版当你 reload/重新部署Tomcat 创建新的 WebAppClassLoader新请求走新 classloader旧 classloader 如果没有任何引用才能被 GC 回收所以“能不能卸载”取决于有没有从容器/全局/线程指向旧 classloader 的强引用11.4 典型泄漏根因线程与静态引用最常见11.4.1 线程泄漏你创建了线程池/定时任务但应用 stop 时没有 shutdown线程的 contextClassLoader 指向旧应用 classloader导致旧 classloader 被引用无法回收11.4.2 静态缓存/单例static Map 缓存类/反射对象/driver或第三方库在静态变量里持有 class/资源11.4.3 JDBC Driver / ThreadLocalDriverManager 注册的 driverThreadLocal 没清理持有业务对象11.5 可复现示例一个忘记 shutdown 的定时任务// 伪代码应用启动时创建定时任务Executors.newSingleThreadScheduledExecutor().scheduleAtFixedRate(()-{// do something},0,1,TimeUnit.SECONDS);如果 stop 时不 shutdown线程还在跑引用仍在reload 越多泄漏越大11.6 对照组正确的资源生命周期管理错在静态块/启动时创建线程池但不释放对使用容器管理的线程池JNDI/ManagedExecutorService或在应用关闭时 shutdownSpring 用PreDestroy/DisposableBean12. 线上排障 checklist从现象到定位12.1 先定性是“业务慢”还是“连接/协议层问题”业务慢线程栈在业务代码/DB协议层关注 header 限制、keep-alive、连接堆积12.2 看指标RT/QPS/错误码线程池是否打满活跃线程 vs maxThreads连接数与 fd12.3 抓线程栈取 Top 5 栈判断卡点业务/锁/DB/网络12.4 决定动作业务慢SQL/锁/下游连接堆积超时、限流、keepAlive 参数内存泄漏多次 redeploy 后内存持续上升抓 heap dump 看 WebAppClassLoader13. 面试背诵稿60 秒Tomcat 一次请求的主线是Connector 对外提供协议入口内部由 Endpoint 负责 accept/select 等 I/O 事件驱动当 socket 可读时交给 Processor 做 HTTP 协议解析把字节流解析成请求语义随后通过 CoyoteAdapter 把 Coyote Request 适配到 Catalina 容器进入 Engine/Host/Context/Wrapper最终执行 Filter/Servlet。调优上我会用容量模型解释吞吐近似等于线程数除以平均处理时长所以 maxThreads 不是越大越好太大只会增加上下文切换并把压力打到 DBacceptCount 是线程池满时的排队长度队列太大等于把请求在 Tomcat 里堆着导致 RT 爆炸应该配合上游限流与快速失败。connectionTimeout 和 keepAliveTimeout 影响连接占用与慢连接风险需要和网关的 keep-alive 策略对齐。热部署时 Tomcat 为每个 Web 应用创建独立的 WebAppClassLoaderreload 会创建新 classloader旧的是否能回收取决于是否还有强引用最常见的泄漏来源是应用自己创建的线程池/定时任务没有在 stop 时 shutdown线程会持有旧 classloader其次是 ThreadLocal、JDBC driver 注册、以及 static 缓存持有 class/资源。排障时我会先看线程池是否打满再抓线程栈定位到底卡在 DB、锁还是外部调用然后再决定是扩容/限流还是调整参数。