秒杀场景下LinkedBlockingQueue易OOM，因其默认无界（Integer.MAX_VALUE）、消费跟不上生产、缺乏容量兜底机制三者叠加导致内存失控；应显式设限并配拒绝策略。
秒杀场景下用 LinkedBlockingQueue 容易导致 OOM，核心原因不是它本身有缺陷，而是**默认无界 + 消费跟不上生产 + 缺乏容量兜底机制**三者叠加造成的内存失控。
默认容量是 Integer.MAX_VALUE，不是“真无界”，而是“假宽松”
很多人以为 new LinkedBlockingQueue() 是“弹性队列”，其实它内部用链表节点（Node）存储元素，每个节点至少包含一个引用 + next 指针（约 24–32 字节），加上业务对象本身（比如一个订单 POJO 可能几百字节）。当秒杀流量突增，而下游消费线程处理不过来时，任务持续堆积，队列长度轻松突破百万级——这时光是 Node 对象就可能吃掉数 GB 堆内存。
- 例如：100 万订单对象 × 平均 500 字节 = 500 MB；再加 100 万个
Node开销 ≈ 30 MB；实际 GC 压力远高于此 - 堆 dump 中常见现象：
LinkedBlockingQueue$Node占比极高，数量达千万甚至上亿级别
秒杀的典型失衡：提交快、处理慢、拒绝策略缺失
秒杀请求在极短时间内爆发（如 1 秒涌入 5 万请求），但库存校验、扣减、落库等操作需 IO 或锁竞争，单线程吞吐往往只有几百 TPS。若线程池配了 8 个核心线程 + 默认无界队列，所有请求全塞进队列，等于把瞬时压力平铺成持续内存压力。
- 没有显式设置队列容量 → 不触发拒绝策略（如
AbortPolicy或CallerRunsPolicy） - 线程池不拒绝，应用层也不做限流（如 Sentinel / RateLimiter），等于放行所有请求到队列
- 结果：队列越积越长，JVM 堆撑爆，直接
OutOfMemoryError: Java heap space
对比 ArrayBlockingQueue 更可控
ArrayBlockingQueue 必须指定容量，本质是“硬闸门”：
- 队列满时，
put()阻塞或抛异常，倒逼上游做降级（如返回“秒杀已结束”） - 配合
ThreadPoolExecutor.CallerRunsPolicy，能让调用线程自己执行任务，天然限速 - 内存占用可预估：数组大小 × 元素引用（不额外产生 Node 对象）
真正安全的用法不是不用 LinkedBlockingQueue，而是“有界化”
如果业务确实需要链表队列的动态扩容能力（比如任务对象大小差异极大），必须显式设容量，并与压测峰值对齐：
- 根据历史秒杀峰值 QPS 和平均处理耗时，估算最大堆积量（例：峰值 2 万 QPS × 处理延时 1.5s ≈ 3 万待处理任务）
- 队列容量设为该值的 1.5–2 倍（如 5 万），并搭配
CallerRunsPolicy或自定义拒绝逻辑 - 代码示例：
new LinkedBlockingQueue(50000)，而非无参构造
