任务队列大小需结合线程数、任务类型与系统承载力科学设定：CPU密集型建议32–128，I/O密集型可设200–1000，突发流量场景≤200；推荐ArrayBlockingQueue，禁用无界队列；须配拒绝策略、命名规范及监控指标。
任务队列大小不是拍脑袋定的，它得和线程数、任务特征、系统承载力一起算。设太大，内存撑爆；设太小，任务直接被拒或频繁触发拒绝策略，影响可用性。
先看任务类型和执行节奏
队列容量必须匹配任务的“到达速度”和“处理速度”。如果每秒来 100 个任务，每个平均耗时 200ms，那理论并发需求是 100 × 0.2 = 20。若你线程池只有 8 个核心线程，那队列至少要能缓冲其余任务——否则一压测就满。
- CPU 密集型任务：执行快、几乎不等待，队列建议设小（如 32–128），靠线程数扛并发，避免任务积压
- I/O 密集型任务（如 DB 查询、HTTP 调用）：单任务耗时长、大量时间在等，队列可适当放大（如 200–1000），但必须配合有界队列 + 合理拒绝策略
- 突发流量场景（如秒杀）：不能依赖大队列“消化”峰值，应前置限流（如 Sentinel），队列只做短时缓冲（建议 ≤ 200），防雪崩
用公式粗估，再靠压测验证
一个实用的起点公式：队列容量 ≈ 每秒任务数 × 平均响应时间 × 缓冲系数。其中缓冲系数通常取 1.5–3，代表你想容忍的瞬时堆积倍数。
- 例：QPS=50，平均 RT=100ms，取系数 2 → 队列 ≈ 50 × 0.1 × 2 = 10
- 注意：这只是初始值。上线后必须观察
getQueue().size()—— 若长期 > 队列容量的 70%，说明要么队列太小，要么线程数不足，或下游瓶颈了 - 别用
LinkedBlockingQueue默认无界队列（容量 Integer.MAX_VALUE），那是把 OOM 风险留给 GC
选对队列类型比调数字更重要
ArrayBlockingQueue 是最稳妥的选择：有界、FIFO、内存占用可控。SynchronousQueue 适合高吞吐低延迟场景（如 Netty），但它不存任务，全靠线程“一手交一手”，要求 maximumPoolSize 必须足够且 keepAliveTime 合理。
立即学习“Java免费学习笔记（深入）”；
- 避免 PriorityBlockingQueue：排序开销大，且优先级逻辑易引发饥饿，业务中极少真正需要
- 禁用无界队列做生产配置：哪怕你设了 maximumPoolSize，只要队列无界，线程数就永远涨不到 max，等于废掉了弹性扩容能力
- 若需区分任务优先级，应在业务层做路由（如分两个线程池），而不是靠队列排序
配套动作不能少
光调队列大小没用，必须同步落实三件事：
- 配明确的拒绝策略：不要用默认的
AbortPolicy（直接抛异常），推荐CallerRunsPolicy（让调用方自己执行，自然降速）或自定义记录+告警 - 给线程池起有意义的名字：用
ThreadFactory加业务前缀（如 “order-async-pool”），排查线程堆栈时一眼定位 - 暴露监控指标：队列长度、活跃线程数、拒绝任务数、完成任务数，接入 Prometheus 或通过 JMX 实时查看
