应优先选择有界队列，因其容量固定、内存可控、能触发线程池扩容和明确背压信号；无界队列仅适用于任务极轻量、处理远快于提交且内存充足并有强监控的少数场景，否则易致OOM。
选有界队列还是无界队列，关键不在“能不能装下”，而在于你愿不愿意为失控承担后果。多数生产系统应该默认倾向有界队列。
有界队列适合这些情况
任务处理节奏相对稳定，比如定时风控校验、支付结果落库；系统内存有限，无法承受任务持续堆积；你希望线程池在压力变大时主动扩容（队列满 + 线程未达 maximumPoolSize → 新建非核心线程）；你需要明确的背压信号——上游提交失败或被阻塞，倒逼限流、降级或重试。
- 常用实现：ArrayBlockingQueue（数组、单锁、容量固定）、带容量参数的 LinkedBlockingQueue（链表、双锁、更抗竞争）
- 必须配套拒绝策略：CallerRunsPolicy（让调用线程自己执行）、DiscardOldestPolicy（丢老任务）、或自定义落盘/发消息队列，避免关键任务静默丢失
- 最大积压量可估算：队列容量 + 最大线程数 × 单任务内存开销，OOM 风险可控
无界队列只在少数场景真合适
它不是“无限”，而是把限制从队列转移到了 JVM 堆内存。默认 Integer.MAX_VALUE 的 LinkedBlockingQueue，表面看永不拒绝，实则掩盖问题——任务持续涌入、消费不及，队列无限膨胀，GC 清不掉强引用的任务对象，最终触发 OutOfMemoryError。
- 仅建议用于：任务极轻量（如日志异步写入）、处理速度远高于提交速度、且内存资源充足并有强监控兜底的后台服务
- 线程数恒等于 corePoolSize：不会因队列满而扩容，调度开销小但弹性差
- 无真实背压：上游完全感知不到压力，等 OOM 报警才察觉，已错过干预窗口
SynchronousQueue 是另一条路
它不是“无界”也不是传统“有界”，而是容量为 0 的直接交接队列。每个 submit 都试图立刻交给空闲线程，失败就新建线程（直到 maximumPoolSize），适合低延迟、高并发敏感场景，比如网关转发、RPC 调用。
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
立即学习“Java免费学习笔记（深入）”；
- 优势：任务不落地、免拷贝、延迟最低
- 风险：拒绝来得快——流量洪峰直接打穿 maximumPoolSize，抛 RejectedExecutionException
- 必须配强拒绝策略：比如记录告警+降级到本地线程执行，不能放任失败
简单判断流程
问自己三个问题：
- 任务平均处理时间是否稳定？波动大 → 优先考虑有界队列 + 合理扩容机制
- 能否接受任务在内存里长期积压？不能 → 排除无界队列
- 延迟是否比吞吐更重要？是 → SynchronousQueue + 严格限流
没想清楚时，从 ArrayBlockingQueue 开始，设一个保守容量（比如 200），再根据压测数据调优，比一开始就用无界队列更安全。
