maximumPoolSize仅在核心线程全忙、队列已满且当前线程数小于该值时触发，需三者同时满足；使用无界队列或队列未满时它不会启用，应配以有界队列并压测验证。
maximumPoolSize 不是“一有压力就开新线程”，而是线程池在核心线程全忙、队列也塞满后的最后一道弹性防线。它只在特定组合条件下才被触发，理解这个时机，比盲目调大数值更重要。
触发 maximumPoolSize 的三个硬性前提
它不会单独起作用，必须同时满足以下三点：
- 当前活跃线程数已达到 corePoolSize（所有核心线程都在干活）
- 提交的新任务无法进入 workQueue（队列已满，无处排队）
- 当前总线程数（核心 + 已创建的非核心）仍 小于 maximumPoolSize
只有这三者全部成立，线程池才会新建一个非核心线程来顶上。缺一不可。
常见误解：什么情况下它根本不会启动？
很多问题出在误判了触发条件。以下情况，maximumPoolSize 就是“摆设”：
- 任务量不大，核心线程就能处理完 → 新任务直接由空闲核心线程执行，不走扩容逻辑
- 队列还有空位（比如用了
LinkedBlockingQueue且容量极大）→ 任务全进队列等着，永远不触发新线程 - 线程数已达 maximumPoolSize，但仍有新任务涌入 → 直接走拒绝策略，不再尝试创建
- 用的是无界队列（如默认
Executors.newFixedThreadPool背后的队列）→ 队列永远不会满，maximumPoolSize 彻底失效
怎么验证它是否真被用上了？
光看配置没用，得靠运行时指标确认：
- 监控
getPoolSize()：持续接近或等于maximumPoolSize，说明扩容频繁启用 - 观察
getActiveCount()和getQueue().size()：两者长期双高 → 队列积压 + 线程全忙，正是 maximumPoolSize 发挥作用的典型状态 - 查拒绝率（如
RejectedExecutionException日志）：如果拒绝率高，但getPoolSize()远低于 maximumPoolSize → 很可能是队列太大或 corePoolSize 设置不合理，而非 maximumPoolSize 不够
实战建议：让 maximumPoolSize “该出手时才出手”
它本质是应对短时脉冲的缓冲带，不是常态承载主力：
- 务必搭配 有界队列（如
ArrayBlockingQueue），否则它永无用武之地 - 避免
corePoolSize == maximumPoolSize→ 失去弹性，等于放弃缓冲能力 - 非核心线程空闲后需及时回收：确保
allowCoreThreadTimeOut = false（默认），并合理设置keepAliveTime，防止救急线程变成常驻负担 - 上线前做压测：模拟突发流量，观察
getPoolSize()是否如期增长、有无 OOM 或上下文切换飙升
