WorkQueue大小需匹配任务到达节奏与处理能力差值：有界队列容量决定缓冲上限，过小引发抖动，过大导致延迟升高，无界队列易OOM；应结合QPS与耗时估算，并通过queue.size和拒绝计数动态调优。
WorkQueue 的大小直接影响线程池应对瞬时压力的能力——它不是越大越好，也不是越小越稳，关键在于匹配任务到达节奏与处理能力的差值。
有界队列容量决定缓冲上限
使用 ArrayBlockingQueue 等有界队列时，队列容量（capacity）就是缓冲能力的硬边界。比如设为 100，意味着最多缓存 100 个待执行任务；超出部分会触发扩容逻辑（若线程数未达 maximumPoolSize）或拒绝策略。这个数值需结合业务峰值 QPS 和平均任务耗时估算：若每秒进 20 个任务、单任务平均耗时 500ms，理论积压速率约 10 个/秒，那么 100 容量可支撑约 10 秒突发而不立即拒绝。
- 容量过小（如设为 10）：轻微流量波动就触发扩容或拒绝，线程数频繁变动，系统抖动明显
- 容量过大（如设为 10000）：掩盖线程数不足问题，任务长期堆积在队列中，响应延迟肉眼可见升高
- 无界队列（如 LinkedBlockingQueue 默认构造）：等于放弃缓冲控制权，所有任务全入堆内存，极易 OOM，且 corePoolSize 永远不会触发扩容
队列大小与线程数协同影响响应曲线
队列不是独立参数，它和 corePoolSize、maximumPoolSize 构成“缓冲-执行”两级调节机制。例如：
- 小队列 + 合理线程数：适合对延迟敏感的场景（如实时接口），靠快速扩容消化压力，避免任务滞留
- 中等队列 + 稳定线程数：适合吞吐优先的后台任务，用队列平滑毛刺，减少线程创建开销
- 大队列 + 小线程数：表面缓解压力，实则把问题转移到 GC 和内存占用上，监控指标常表现为 queue.size 持续增长、activeCount 长期低位
动态观察比静态设定更可靠
线上真实压力往往偏离预估，建议通过两个指标持续验证队列设置是否合理：
立即学习“Java免费学习笔记（深入）”；
- ThreadPoolExecutor.getQueue().size()：稳定运行时应长期趋近于 0 或小幅波动；若持续 > 20% 容量，说明处理能力跟不上，需调高 corePoolSize 或优化单任务耗时
- 拒绝任务计数（配合自定义 RejectedExecutionHandler）：若频繁触发拒绝，先看是队列满还是线程满——前者说明队列太小或线程太少，后者说明 maximumPoolSize 已到瓶颈或任务本身阻塞严重
常见误配与修正方向
很多团队踩过的坑，本质是把队列当“保险箱”而非“节流阀”：
- 用无界队列 + 固定大小线程池 → 改为 ArrayBlockingQueue，容量设为 200~500，并启用 CallerRunsPolicy 缓冲尖峰
- 队列设得极大（如 10000）但 corePoolSize 仅 2 → 调整 corePoolSize 至 CPU 核心数 × (1.5～2)，让核心线程承担主要负载
- 完全忽略队列监控，只盯着线程数 → 在健康检查接口中暴露 queue.size、queue.remainingCapacity、getActiveCount() 三个值，形成可观测闭环
