Java线程池工作队列选型需匹配负载特征与风险承受力：LinkedBlockingQueue（推荐有界）适合稳定负载；ArrayBlockingQueue适用于资源敏感场景；SynchronousQueue适合短平快任务；PriorityBlockingQueue用于优先级调度。
Java 线程池的工作队列是任务缓冲的关键环节，直接影响线程创建行为、内存占用、响应延迟和系统稳定性。选错队列，轻则性能下降，重则 OOM 或任务丢失。核心不在于“有多少种”，而在于“哪种匹配你的负载特征和风险承受力”。
LinkedBlockingQueue（无界/有界链表队列）
最常用，默认容量为 Integer.MAX_VALUE，实际视为“无界”。它按 FIFO 顺序排队，线程安全，适合大多数后台异步场景。
- 用无界版（
new LinkedBlockingQueue()）时，maximumPoolSize 失效，线程数永远卡在 corePoolSize；拒绝策略也基本无效——任务只管往里塞，直到内存撑爆 - 生产环境建议显式指定容量（
new LinkedBlockingQueue(200)），变成有界队列，配合合理的拒绝策略（如CallerRunsPolicy），才能真正控住风险 - 适用：任务执行时间较稳定、提交速率与处理能力大致平衡的场景，比如日志落盘、消息投递
ArrayBlockingQueue（有界数组队列）
必须指定固定容量，底层用数组实现，FIFO，支持公平/非公平锁模式（构造时传 boolean 参数）。
- 容量不可变，队列满时 put 操作会阻塞调用线程，这本身是一种背压信号，能自然抑制上游过快提交
- 内存占用可控、缓存局部性好，比链表队列更省内存；但扩容需重建数组，所以容量要预估合理
- 适用：资源敏感型服务，例如网关、API 限流后端，需要明确限制待处理任务上限
SynchronousQueue（同步移交队列）
没有内部存储空间，不保存任何任务。每次 put() 必须等待另一个线程执行 take()，反之亦然。本质是“任务直交空闲线程”。
立即学习“Java免费学习笔记（深入）”；
- 搭配
corePoolSize=0, maximumPoolSize=Integer.MAX_VALUE就是CachedThreadPool的底座，适合短平快任务 - 优势是响应极快、无队列堆积；但风险极高：若并发突增而线程创建跟不上，会触发大量线程创建，极易引发 OOM
- 适用：任务生命周期极短（毫秒级）、且能容忍线程数剧烈波动的场景，如 RPC 客户端请求分发
PriorityBlockingQueue（优先级队列）
无界队列，基于堆实现，按任务实现的 Comparable 或外部 Comparator 排序，高优先级任务先执行。
- 不保证 FIFO，也不保证相同优先级任务的执行顺序；低优先级任务可能长期饥饿
- 不能直接用于普通
Runnable，需包装成可比较对象（如带 priority 字段的自定义任务类） - 适用：存在明确优先级分级的调度系统，比如订单履约中“退款优先于发货”、“VIP 订单优先于普通单”
