高并发下应按任务特性选阻塞队列：需严格限流选ArrayBlockingQueue（有界、防OOM）；生产消费不对等选LinkedBlockingQueue（双锁、高吞吐）；需即时交接选SynchronousQueue；延时或优先级任务则用DelayQueue或PriorityBlockingQueue。
高并发下选对阻塞队列，关键不是看“哪个最热门”，而是看任务特性、资源约束和调度意图。选错可能引发内存溢出、线程饥饿或优先级错乱，而不是单纯性能下降。
看任务是否需要严格限流
如果系统资源有限（比如小内存服务器、嵌入式场景），或你明确知道峰值任务量上限，ArrayBlockingQueue 是首选。它强制你指定容量，从源头防止任务无节制堆积。例如订单处理系统要求最多缓存500个待发单，用它就能卡死上限，配合拒绝策略快速失败，避免OOM。
- 必须初始化时传入固定容量，不可扩容
- 支持公平锁（可选），适合对响应顺序敏感的业务
- 单一锁机制，在极高并发写+读混合场景下吞吐略低，但稳定性可控
看生产消费是否频繁且不对等
日志收集、异步通知这类场景，生产速率常远高于消费速率，且任务量波动大。LinkedBlockingQueue 更合适——默认容量为 Integer.MAX_VALUE，实际接近无界，但更关键的是它用两把锁（putLock/takeLock）分离读写操作，生产者和消费者几乎互不干扰。
- 建议显式设置容量（如 new LinkedBlockingQueue(10000)），避免默认无界导致堆内存失控
- 吞吐量通常高于 ArrayBlockingQueue，尤其在读多写少或写多读少的偏态负载下
- 链表结构带来少量对象开销，GC压力略高于数组，但现代JVM影响不大
看任务是否要“立刻转手”或带延迟/优先级
如果任务生命周期极短，目标是让线程间直接交接（比如线程池需快速扩容），SynchronousQueue 没有存储空间，每个 put 必须配一个 take，天然削峰，适合 CachedThreadPool。
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
立即学习“Java免费学习笔记（深入）”；
若任务需按时间触发（如延时发券）或按重要性分级（如VIP消息优先），则跳过 FIFO 队列：DelayQueue 要求元素实现 Delayed 接口；PriorityBlockingQueue 则依赖 Comparable 或自定义 Comparator，但它无界，务必注意内存风险。
- SynchronousQueue：零容量，高吞吐，适合短任务+弹性线程模型
- DelayQueue：内部基于 PriorityQueue，只在 delay ≤ 0 时才可 poll，容量理论无限
- PriorityBlockingQueue：不保证完全 FIFO，相同优先级元素顺序不定
看线程池类型是否已绑定队列习惯
别忽略线程池构造逻辑。FixedThreadPool 默认用 LinkedBlockingQueue（无界），CachedThreadPool 用 SynchronousQueue，ScheduledThreadPool 用 DelayQueue。如果你用 Executors 工具类，其实已经替你做了选择；但自定义 ThreadPoolExecutor 时，必须主动匹配——比如给 FixedThreadPool 换成 ArrayBlockingQueue，就等于改变了它的扩容逻辑（满队列后会新建线程，而非拒绝）。
- 确认线程池运行机制：队列满 → 是否允许新建非核心线程？这决定拒绝策略触发时机
- 避免“默认无界队列 + 大量慢消费任务”组合，这是线上 OOM 的高频原因
- 监控队列 size() 和 rejected count，比压测更能暴露真实瓶颈
