选对等待队列取决于任务节奏、资源底线和失败容忍度，核心是“要不要排队、能排多少、排久了谁兜底”：SynchronousQueue适合低延迟场景，ArrayBlockingQueue适合控内存防堆积，LinkedBlockingQueue（需设容量）适合吞吐优先但堆内存充足的情况。
选对等待队列不是看哪个“高级”，而是看你的任务节奏、资源底线和失败容忍度。核心就三点：要不要排队、能排多少、排久了谁来兜底。
任务来了必须立刻执行？用 SynchronousQueue
它不存任务，只做“交接”——提交任务时，必须有空闲线程当场接住；没有，就触发扩容（直到达 maximumPoolSize）。适合低延迟场景，比如实时通知、RPC 响应。
- 搭配 corePoolSize > 0，避免冷启动时全靠新建线程扛压
- maximumPoolSize 要设合理上限（如 20–50），否则突发流量可能瞬间拉起几百线程，OOM 或上下文切换雪崩
- 不适合任务执行时间波动大或偶发慢查询的场景，容易线程数失控
要控内存、防堆积？优先 ArrayBlockingQueue
容量固定，强制你面对真实负载：每秒进多少任务？平均耗时多久？能接受最长排队几秒？比如 QPS 300、平均耗时 40ms，理论缓冲约 12 个，设成 200 是常见安全余量。
Java Maven Common
下载
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
- 构造时必须指定容量，编译期就卡住“随便填”的侥幸心理
- 单锁设计，高并发下吞吐略低于 LinkedBlockingQueue，但行为可预测、GC 压力小
- 队列满即触发拒绝策略，是暴露瓶颈最直接的信号——不是故障，是告警
吞吐优先且堆内存充足？用带容量的 LinkedBlockingQueue
默认无界（Integer.MAX_VALUE）是陷阱，线上出过太多因未设限导致堆打满、Full GC 卡死的案例。真要用，必须显式传参，比如 new LinkedBlockingQueue(5000)。
立即学习“Java免费学习笔记（深入）”；
- 双锁机制，put 和 take 可并行，高频 submit + execute 场景吞吐更稳
- 每个任务额外包装为 Node 对象，1 万个任务比 Array 多占 2–3MB 内存，Android 或容器环境需谨慎
- 若代码里频繁调用 remove() 或 contains()，反而比 Array 更慢，因为要抢两把锁
别忽略拒绝策略与队列的配合逻辑
队列类型决定了“什么情况下会拒绝”，而拒绝策略决定“拒绝后怎么收场”：
- ArrayBlockingQueue 满 + 线程达上限 → AbortPolicy 抛异常，适合强一致性服务，上游需重试或降级
- SynchronousQueue 本质无排队 → 拒绝只发生在 maximumPoolSize 耗尽时，此时 CallerRunsPolicy 让调用方自己执行，天然削峰，但慎用于 Web 入口（会拖慢用户请求）
- LinkedBlockingQueue（设了容量）满后行为同 Array，但因容量极大，往往等不到满就先 OOM，所以设容量是底线要求
