maximumpoolsize仅在核心线程满、任务队列满、当前线程数未达上限三条件同时满足时触发扩容；jdk execute()按空闲核心线程→队列offer→扩容顺序严格判断。
maximumPoolSize 不是“一设就涨”的开关，它只在特定临界条件下才真正触发扩容——核心线程已满、任务队列已满、且当前线程数尚未达到上限。跳过这个前提直接调大数值，线上几乎零效果。
触发扩容的三个硬性条件必须同时满足
线程池不会因为流量变大就自动多开线程。JDK 的 execute() 方法严格按顺序判断：
- 先看是否还有空闲核心线程：有则直接执行，不进队列也不扩容；
- 没有空闲核心线程时，尝试把任务塞进 workQueue：成功则排队等待，仍不扩容；
- 只有当队列 offer 失败（即已满），且当前线程数 addWorker(command, false) 创建非核心线程。
为什么改了 maximumPoolSize 却没扩容？常见陷阱
多数失败扩容都卡在队列设计上：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 用了
LinkedBlockingQueue（默认无界）：任务永远能入队，never 触发扩容逻辑； - 队列容量设得过大（如 10000）：日常流量根本填不满，max 值形同虚设；
- corePoolSize 过低（比如设为 2），但日常均值已达 15：前 2 个线程+大队列就把活干完，其余线程压根没机会创建。
让 maximumPoolSize “真正生效”的配套动作
单改一个参数毫无意义，必须同步调整：
-
换用有界队列：推荐
ArrayBlockingQueue，容量设为日常峰值任务积压量的 1.2～1.5 倍（例如 300）； - 合理设置 corePoolSize：建议为稳定期平均并发线程数的 1.5～2 倍，确保基础负载由常驻线程消化；
- 收紧 keepAliveTime：从默认 60 秒降至 10～20 秒，避免秒级扩容后线程刚建好就销毁，造成震荡。
线上热扩时的校验与防护要点
动态调用 setMaximumPoolSize() 是安全的，但需前置控制：
- 新值不能小于当前
getActiveCount()，否则可能丢任务； - 应设硬性安全上限（如 200），防止误配导致线程爆炸；
- 调整后立即检查
getPoolSize() == getMaximumPoolSize()并结合队列积压数，持续 30 秒即告警——说明已打满，需人工介入或启动降级。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
