Tomcat线程池通过预启动核心线程、队列满即拒绝、扩容逻辑前移三处定制适配Web高并发短任务场景：启动时即预热minSpareThreads个线程，TaskQueue重写offer方法使线程数未达maxThreads且任务超当前线程数时立即扩容，而非先填满队列。
Tomcat 的线程池不是简单套用 JDK 的 ThreadPoolExecutor，而是围绕 Web 请求“短、快、高并发”的特性做了三处关键定制——核心线程预启动、队列满即拒、以及扩容逻辑前移。理解它的扩容策略，关键在于跳出 JDK 原生“先填队列、再扩线程”的惯性思维，转而关注 Tomcat 如何在请求洪峰到来前就做好准备、又如何在队列看似“无限”时仍能动态扩容。
核心线程默认就“热着”，不等请求来才创建
JDK 线程池默认采用懒加载：只有任务提交且当前线程数 corePoolSize 时，才新建核心线程。这对后台批处理尚可，但对 Web 场景致命——刚启动就遭遇流量高峰，大量请求会在无可用线程时直接排队或被拒。
Tomcat 通过 prestartminSpareThreads=true（配合 minSpareThreads 参数）在启动时就预先拉起全部核心线程。比如配置 minSpareThreads="25"，服务一启动就有 25 个空闲线程 ready to go，省去首次建线程的延迟和上下文开销。
队列不是“缓冲区”，而是“扩容触发器”
Tomcat 默认使用自定义的 TaskQueue（继承 LinkedBlockingQueue），其 offer() 方法被重写：当队列未满时，行为同原生；但一旦发现当前活跃线程数 maxThreads，它会主动返回 false —— 即使队列还有空间。
立即学习“Java免费学习笔记（深入）”；
这个“假满”信号会触发线程池尝试创建新线程，而不是把任务塞进队列等调度。也就是说：
- 任务提交 → 先尝试加队列
- 若
offer()返回 false（哪怕队列远未满）→ 立即走“创建非核心线程”路径 - 仅当线程数已达
maxThreads且offer()再次失败 → 才真正执行拒绝策略
这本质是把扩容判断从“队列容量耗尽”提前到了“线程资源是否充足”，更契合 I/O 密集型请求需要即时响应的特点。
扩容上限受控，且空闲线程可回收
Tomcat 并非无节制扩容。它严格遵循 minSpareThreads ≤ 当前线程数 ≤ maxThreads 的区间约束：
-
minSpareThreads：保底存活线程数，低于此值时即使空闲也不销毁 -
maxThreads：硬性上限，达到后不再新建任何线程 -
maxIdleTime：非核心线程空闲超时后会被回收（单位毫秒），避免长期占用资源
例如配置 minSpareThreads="25"、maxThreads="200"、maxIdleTime="60000"，意味着系统常态维持至少 25 个线程，峰值最多撑到 200 个，而临时创建的线程若 60 秒内无任务，就会自动退出。
拒绝策略发生在“最后防线”，而非“第一反应”
当线程已达 maxThreads 且 TaskQueue.offer() 再次失败（即队列真满或拒绝逻辑触发），Tomcat 才抛出 RejectedExecutionException。但它在 execute(Runnable, timeout, unit) 中做了兜底：
- 捕获拒绝异常后，调用
queue.force(command, timeout, unit) -
force方法会绕过常规 offer 逻辑，强制入队（类似阻塞式 put），并等待指定超时 - 若 force 也失败，才最终抛异常
这相当于给突发流量多一次“挤进队列”的机会，比 JDK 默认的立即拒绝更柔性，也更贴近 Web 场景中“宁可稍慢，不可丢请求”的诉求。
