arrayblockingqueue通过有界容量实现可控背压：核心线程空闲时直接处理，忙且队列未满则入队等待，满时触发拒绝或调用线程执行；其容量需基于qps、耗时与排队容忍度权衡设定。
Java线程池的任务调度行为，很大程度上由所选的BlockingQueue决定。队列不是被动容器，而是直接参与线程创建、任务缓冲和背压控制的关键环节。不同队列类型会触发线程池完全不同的扩容逻辑和资源响应模式。
ArrayBlockingQueue：有界队列带来可控的背压
基于数组、容量固定，是生产环境最推荐的默认选择。它强制系统在队列满时做出明确决策——要么拒绝任务，要么让调用线程兜底执行。
- 当任务提交时，若核心线程空闲，直接交由核心线程处理
- 核心线程全忙，且队列未满 → 任务入队等待
- 队列已满，但当前线程数
- 队列满 + 线程数已达 maximumPoolSize → 触发拒绝策略（如
CallerRunsPolicy）
这种“先排队、再扩容、最后兜底”的三级缓冲机制，能清晰暴露系统瓶颈，便于容量规划与监控告警。
LinkedBlockingQueue：无界队列隐藏内存风险
底层是链表，理论上可无限增长（默认容量为Integer.MAX_VALUE）。表面看“永不拒绝”，实则将压力转嫁到JVM堆内存。
- 只要核心线程忙，新任务就持续入队，不触发线程扩容
- 大量慢任务或下游延迟会导致队列持续膨胀，最终引发
OutOfMemoryError - 线程池永远停留在
corePoolSize规模，无法利用更多CPU资源应对突发负载
适合内部低频、确定性高的后台任务，**绝不适用于处理外部不可控请求**（如HTTP接口、消息队列消费）。
SynchronousQueue：零存储，强调即时传递
不保存任务，每个put()必须等待对应take()，本质是“手递手”交接。它迫使线程池跳过排队阶段，直奔线程扩容。
- 提交任务时，若存在空闲线程 → 立即交接执行
- 无空闲线程 → 直接创建新线程（直到达
maximumPoolSize） - 线程数已达上限 → 立即触发拒绝策略
适合短平快、高并发、对延迟敏感的场景（如RPC调用响应、实时事件分发），但要求corePoolSize设置合理，避免频繁创建销毁线程。
如何匹配业务特征选队列
关键看任务的不确定性程度和系统容忍边界：
-
CPU密集型：选
ArrayBlockingQueue，容量设为1–2倍核心线程数，防止上下文切换恶化 -
IO密集型（如DB/HTTP）：可选
SynchronousQueue配较高maximumPoolSize，或ArrayBlockingQueue配较大容量（如50–200） - 需强稳定性保障：必须用有界队列 + 显式拒绝策略（如记录日志+降级），杜绝静默失败
-
已有监控告警能力：可结合
ArrayBlockingQueue的队列使用率指标（如>80%触发扩容或限流）
记住：队列不是越大越好，也不是越小越稳。它的容量和类型，本质上是你对“多少任务可以等、等多久、谁来承担等待成本”的业务判断。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
