ArrayBlockingQueue作为有界队列，在线程池中是实现高并发稳健性的关键一环。它通过显式容量限制，从根源上防止任务无限堆积和内存溢出（OOM），特别适合流量可预期、系统资源需严格管控的生产场景。
为什么选ArrayBlockingQueue而不是无界队列
LinkedBlockingQueue默认无界（容量为Integer.MAX_VALUE），在突发流量下极易导致任务持续入队、内存飙升、GC频繁甚至OOM；SynchronousQueue虽零存储，但要求线程数能即时匹配任务提交节奏，否则会频繁扩容缩容，加重CPU与调度负担。ArrayBlockingQueue以“确定容量+阻塞等待”机制，在二者间取得平衡：
- 容量固定，内存占用可预估，便于JVM堆规划
- 满时生产者线程阻塞，天然形成背压信号，避免下游过载
- 配合合理拒绝策略，可主动控制失败边界，而非被动崩溃
容量设置的实战依据
队列大小不能拍脑袋定。应基于业务平均QPS、单任务处理耗时、可接受排队时长三者推算：
- 若平均每秒进100个任务，平均处理耗时200ms，则理论并发任务数 ≈ 100 × 0.2 = 20
- 为应对3倍峰均比（即300 QPS），预留缓冲空间，队列容量建议设为60~100
- 厨房订单系统类场景（如每工位限5单），直接按物理资源瓶颈设为5或10，更贴近真实约束
与线程池参数的协同调优
ArrayBlockingQueue必须和corePoolSize、maximumPoolSize、拒绝策略联动，才能发挥稳健性：
- corePoolSize建议设为略高于平均并发线程需求（如计算得需20线程，则设24），保障常态响应
- maximumPoolSize不宜过大（如不超过corePoolSize的1.5倍），避免突发时创建过多线程引发上下文切换风暴
- 拒绝策略推荐使用CallerRunsPolicy：当队列满且线程达上限时，由提交任务的线程自己执行，既不丢任务也不抛异常，还能自然降速上游，是一种温和的自我保护
监控与动态反馈的关键点
有界不是一劳永逸。需持续观察运行态指标来验证配置合理性：
- queueSize长期 > 容量70%，说明队列常饱和，可能需扩容或优化任务耗时
- activeCount持续 > corePoolSize，且completedTaskCount增长缓慢，提示处理能力不足，应检查IO或锁竞争
- 拒绝任务数非零，需结合日志判断是偶发峰值还是常态超载，再决定调参或限流
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
