workqueue容量应合理配合maximumpoolsize，避免过大导致线程不扩容、响应变慢；推荐使用有界队列（如arrayblockingqueue），容量按“qps×耗时×缓冲倍数”估算，io密集型可稍大（100–500），cpu密集型宜小（≤32）或用synchronousqueue。
WorkQueue 容量设得太大，会让线程池“永远用不上最大线程数”——任务全堆在队列里等，线程不扩容，系统响应变慢、堆积风险升高，而 maximumPoolSize 形同虚设。关键不是单纯调小数字，而是让队列容量和线程数形成合理配合。
明确队列的定位：它只是缓冲，不是存储
队列不是用来“存住所有请求”的，而是为短时流量波动提供弹性缓冲。一旦容量远超业务实际吞吐能力，任务就会在队列中长时间等待，CPU 空转，延迟飙升。比如设置一个 10000 容量的 ArrayBlockingQueue，而每秒只能消费 50 个任务，不到 3 分钟队列就满，后续任务直接触发拒绝策略或卡死。
- 估算合理容量：用「平均 QPS × 平均处理耗时 × 缓冲倍数」粗略计算。例如 QPS=100、平均耗时 200ms、希望缓冲 3 秒，则建议队列容量 ≈ 100 × 0.2 × 3 = 60，再向上取整到 100 或 200 即可
- 避免无界队列：LinkedBlockingQueue() 默认无界，极易引发 OOM；必须显式指定容量，如 new LinkedBlockingQueue
(200) - 优先选 ArrayBlockingQueue：有界、内存可控、性能稳定；SynchronousQueue 适合高并发短任务（要求立即执行或拒绝），能真正迫使线程数扩展
让 maximumPoolSize 有机会被触发
线程池只有在「队列已满 + 当前线程数
- 队列容量建议 ≤ maximumPoolSize × 2～5 倍。例如 maximumPoolSize=20，队列设 50～100 比较合理；若设成 2000，那得持续压测十几秒才能填满，日常流量根本触不到扩容逻辑
- 配合拒绝策略倒逼行为：用 CallerRunsPolicy 或 AbortPolicy，而不是默默丢弃或无限排队。当队列满、线程也到上限时，让提交方自己执行任务或快速失败，反而能暴露配置问题、触发告警或降级
- 观察活跃线程数：运行中监控 executor.getActiveCount() 和 executor.getQueue().size()。如果长期 activeCount ≈ corePoolSize 且 queue.size 持续 >80% 容量，说明队列过大、线程没起来——该调小队列或调大 corePoolSize
结合任务类型动态匹配
IO 密集型任务等待时间长，容易让线程“挂起”，此时队列可以稍大些（比如 500），但必须配足够多的核心线程来“接力”；CPU 密集型任务几乎不等待，队列应极小（如 16～32），甚至用 SynchronousQueue，靠线程数直接扛压。
- CPU 密集型：corePoolSize ≈ CPU 核心数 + 1，maximumPoolSize ≈ corePoolSize，workQueue 用 SynchronousQueue 或容量 ≤ 32 的 ArrayBlockingQueue
- IO 密集型（如 HTTP 调用、DB 查询）：corePoolSize 可设为 CPU 核数 × 2～4，maximumPoolSize 设为 corePoolSize × 1.5～2，workQueue 容量控制在 100～500，视单任务平均等待时长调整
- 混合型任务：按 IO 占比加权估算，或通过压测确定拐点——当增加线程数不再提升吞吐、反而延迟上升时，就是队列与线程数失衡的信号
本质上，队列和 maximumPoolSize 是一对协同参数，不是孤立指标。设大了队列，等于主动放弃弹性扩容能力；设小了，又可能频繁触发拒绝。平衡点就在“让线程数在真实压力下自然伸缩”，而不是靠队列把压力吞下去。
