线程池任务等待队列选型需平衡吞吐、内存、响应和可控性；LinkedBlockingQueue因双锁机制适合高并发写多读少场景，但必须显式设界防OOM，配合限流与合理拒绝策略。
线程池任务等待队列选型，本质是平衡吞吐、内存、响应和可控性。链表结构的队列（如 LinkedBlockingQueue）在高并发架构中被广泛采用，但它的“无界”特性不是默认优势，而是需要明确约束的风险点。
LinkedBlockingQueue 不是真正无界，而是受内存限制
它底层用链表节点动态分配内存，默认容量为 Integer.MAX_VALUE，看起来“无限”，实际取决于 JVM 堆大小和 GC 能力。当任务提交速度持续高于消费速度，队列会不断增长，最终触发 OutOfMemoryError。
- 监控关键指标：队列 size、GC 频率、老年代使用率
- 生产环境务必显式设置容量，例如
new LinkedBlockingQueue(1000)，避免失控膨胀 - 不建议依赖“默认无界”做流量兜底，应配合限流（如 Sentinel）或降级策略
对比 ArrayBlockingQueue：链表更适合写多读少、突发流量场景
ArrayBlockingQueue 是定长数组，入队出队都需加锁并复制/移动元素；LinkedBlockingQueue 分离 head/tail 锁（takeLock/putLock），读写可并发进行，吞吐更高。
- 适合日志异步刷盘、消息广播、库存预扣等短任务+高提交频次场景
- 不适合任务执行时间长、队列长期积压的场景——此时链表节点碎片多，GC 压力大
- 若业务对延迟敏感且任务量稳定，ArrayBlockingQueue 的确定性（固定容量、可控阻塞）反而更稳妥
链表队列在并发安全上的隐含成本
虽然 LinkedBlockingQueue 内部用双锁机制提升并发度，但链表节点本身是堆上对象，频繁创建/销毁会加剧 GC 压力；且在极端争用下（如大量线程同时 put/take），仍存在锁竞争和条件等待开销。
- 避免在高频小任务场景中反复 new Runnable 匿名类——改用对象池或复用任务对象
- 注意线程池拒绝策略与队列行为的配合：用
AbortPolicy+ 有界 LinkedBlockingQueue，比无界队列 +CallerRunsPolicy更易观测和干预 - 若追求极致性能且任务极轻（纳秒级），可考虑
SynchronousQueue，它不存储任务，直接移交，但要求线程必须“即时可用”
真实业务中的链表队列配置建议
以电商秒杀后的订单异步落库为例：任务轻、瞬时峰值高、允许少量延迟，但不可丢、不可 OOM。
- 选用
LinkedBlockingQueue<Runnable>(5000)，容量根据单机 QPS × 平均处理延迟 × 安全系数估算 - 搭配
corePoolSize=8、maximumPoolSize=16，避免临时线程泛滥 - 拒绝策略用
RejectedExecutionHandler记录告警 + 推入 Kafka 备份，实现柔性失败 - 定期采样队列头尾任务时间戳，判断是否出现“任务陈旧化”，及时扩容或调优线程数
