Tomcat线程池采用“优先扩容、即时就绪”策略，而非先填满队列再创建线程；其核心线程启动即就绪，不依赖任务提交触发，专为Web请求低延迟、高并发、短耗时特性优化。
Tomcat 的线程池不是“先填满队列再扩容”，而是反其道而行之：只要线程资源还没撑到上限，就优先扩容——哪怕队列还空着。这种“逆向优化”本质是为 Web 请求的低延迟、高并发、短耗时特性量身定制的响应逻辑。
核心线程启动即就绪，不等请求来才创建
标准 JDK 线程池采用懒加载：只有提交任务且当前线程数 prestartminSpareThreads=true（配合 minSpareThreads 配置），在服务启动瞬间就拉起全部保底线程。比如设为 25，一启动就有 25 个空闲线程待命，彻底规避首波流量触发的线程创建开销和调度延迟。
队列 offer() 被重写，“假满”即扩容
Tomcat 使用自定义 TaskQueue（继承 LinkedBlockingQueue），其 offer() 方法被改造：
- 若当前活跃线程数
- 这个 false 信号会立刻触发线程池尝试新建非核心线程；
- 仅当线程数已达 maxThreads 且再次 offer 失败，才真正执行拒绝策略。
换句话说，队列在这里不是缓冲区，而是“线程是否够用”的探测器——它用“假装已满”倒逼线程扩容，把扩容决策点从“队列容量耗尽”前移到“请求来了但没人处理”那一刻。
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
立即学习“Java免费学习笔记（深入）”；
扩容有边界，空闲可回收
这种激进扩容不是无节制的：
- minSpareThreads 是下限：低于该值，空闲线程也不会被销毁；
- maxThreads 是硬顶：达到后不再新建任何线程；
- maxIdleTime 控制生命周期：非核心线程空闲超时（如 60 秒）即自动退出，避免长驻浪费资源。
例如配置 minSpareThreads="25"、maxThreads="200"、maxIdleTime="60000"，系统常态维持至少 25 个线程，峰值最多扩至 200，临时线程会在闲置 60 秒后干净退出。
与 JDK 原生逻辑的根本差异
JDK 默认流程是：核心线程 → 队列排队 → 队列满 → 扩容至 maxThreads → 拒绝。Tomcat 把第二步和第三步顺序翻转：核心线程 → 判断“是否还需更多线程” → 扩容（只要没到上限）→ 队列仅作兜底。这使它能更快响应突发请求，尤其适合 I/O 密集、响应时间敏感的 HTTP 场景。
