maximumpoolsize触发扩容需满足“队列已满且当前线程数＜maximumpoolsize”，若队列实际无界（如linkedblockingqueue默认构造）、或核心线程被阻塞无法消费任务，扩容将永不发生。
maximumPoolSize 不是“设了就起作用”的参数，它的触发完全依赖线程池的三级任务处理流程是否走到“扩容分支”。很多线上问题表现为：明明设置了 corePoolSize=4、maximumPoolSize=20、队列用的是 ArrayBlockingQueue(100)，但高并发时活跃线程数始终卡在 4，队列 size 却涨到 80+，任务严重积压——这说明扩容根本没发生。关键难点不在参数本身，而在于你是否看清了“队列未满”这个表象背后的执行逻辑断点。
先确认队列类型和实际容量是否真“有界”
这是最容易被忽略的第一关。很多团队以为用了 LinkedBlockingQueue 就是“有界”，结果构造时写的是 new LinkedBlockingQueue() ——它默认容量是 Integer.MAX_VALUE（约21亿），逻辑上无限，实践中就是无界。此时无论 maximumPoolSize 设成多少，都永远不会触发扩容。
- 检查代码中 workQueue 的实例化方式：是否显式传入容量？比如
new ArrayBlockingQueue(200)或new LinkedBlockingQueue(500) - 用 Arthas 或 JMX 查看运行时队列的
remainingCapacity()和size()，验证是否真的存在“满”的可能 - 注意：SynchronousQueue 虽然不存任务，但它“容量为0”，每次提交都必须立刻有空闲线程承接，也属于“有界”语义，能触发 maximumPoolSize 扩容
盯住三个实时指标，定位扩容卡点在哪一步
线程池扩容只在满足“队列已满 + 当前线程数
- executor.getActiveCount()：当前正在干活的线程数。如果长期 ≈ corePoolSize，说明新任务没被消费，不是线程不够，而是任务根本没分发出去
-
executor.getQueue().size()：队列中等待的任务数。若持续增长且
size ，说明队列还没满 → 扩容条件不满足 → 问题出在“为什么任务不被消费” - executor.getPoolSize()：当前已创建的总线程数。如果一直等于 corePoolSize，且队列 size 高但未达上限，基本可断定：线程池卡在“队列未满”阶段，不会往下走扩容逻辑
排查任务消费阻塞：队列“没满”但任务不动
队列 size 持续上涨却不下降，往往不是扩容失效，而是核心线程被卡住了——它们没空闲出来取任务。常见原因包括：
- 业务逻辑中存在同步阻塞调用：比如 JDBC 直连数据库、HTTP 同步请求、文件 IO 等，导致线程长时间占用，无法返回队列取新任务
- 线程池被多个模块共用：例如定时任务（耗时长）和接口请求（耗时短）混用同一池子，长任务把核心线程全占满，短任务只能排队
- 线程内发生死锁或无限等待：比如 synchronized 锁竞争、CountDownLatch.await() 未被触发、Future.get() 长时间阻塞
建议用 Arthas 的 thread -n 10 查看 top 10 线程栈，重点关注处于 WAITING 或 TIME_WAITING 状态的核心线程在等什么。
验证扩容机制是否真正生效的实操方法
别等线上出事才验证。上线前做一次轻量压测，主动触发扩容路径：
- 构造一个明确会“填满队列”的场景：提交
queue.capacity + 1个慢任务（如TimeUnit.SECONDS.sleep(30)），观察线程数是否从 corePoolSize 增长到 corePoolSize+1 - 用 JConsole 或 Prometheus + Micrometer 拉取
poolSize、activeCount、queueSize三条曲线，确认三者变化是否符合预期流程 - 故意把队列容量设得很小（如 2），再快速提交 10 个任务，看是否在第 3 个任务开始就创建非核心线程，而不是全部进队列
