LinkedBlockingQueue默认构造会OOM，因其容量为Integer.MAX_VALUE，任务积压时内存持续增长直至堆溢出；必须显式指定有依据的容量并配合适当拒绝策略。
为什么 LinkedBlockingQueue 默认构造会 OOM
因为 new LinkedBlockingQueue() 的默认容量是 Integer.MAX_VALUE，不是“真无界”，而是“假装能无限存”——任务提交速度稍快于消费速度，队列就一路狂涨，直到堆内存被占满，直接抛 OutOfMemoryError: Java heap space。
这不是理论风险：电商大促、日志批量推送、下游服务变慢时，几秒内就能复现。你看到线程池里只有 2 个活跃线程，但 executor.getQueue().size() 已经飙到百万级，那就是它在 silently 把内存吃光。
- 错误写法：
Executors.newFixedThreadPool(4)→ 底层用的就是无参LinkedBlockingQueue - 典型症状：JVM 堆内存使用率持续上涨，GC 频繁但回收无效，最终 Full GC 失败
- 关键误区：“无界=不用管” —— 实际上它只是把崩溃时间从“立刻”拖到了“稍后”，而且更难定位
怎么安全地用 LinkedBlockingQueue
必须显式指定容量，且这个值得有业务依据，不能拍脑袋填 1000 或 10000。
- 压测看峰值：比如订单推送在 1 秒内最多积压 3200 条，那就设
new LinkedBlockingQueue(5000)（留 50% 缓冲） - 结合内存算上限：每条任务平均占 1MB，堆内存只给 2GB，那队列最多撑 1000 个对象，再大就得溢出
- 拒绝策略要配对：队列满时别让线程池静默丢任务，用
new ThreadPoolExecutor.AbortPolicy()或自定义策略快速失败
示例：
ThreadPoolExecutor executor = new ThreadPoolExecutor(
2, 4,
60, TimeUnit.SECONDS,
new LinkedBlockingQueue<>(5000), // ← 显式容量
new ThreadPoolExecutor.CallerRunsPolicy() // ← 主动降级，不丢任务也不爆内存
);
ArrayBlockingQueue vs LinkedBlockingQueue 怎么选
如果任务体小、吞吐稳定、能预估峰值，并且你希望“满了就停”，优先选 ArrayBlockingQueue；如果任务大小波动大、偶尔突发、又不想轻易拒绝，才考虑带限的 LinkedBlockingQueue。
-
ArrayBlockingQueue：基于数组，创建即固定大小，size()是 O(1)，内存连续，GC 友好；但扩容不可行，满了就阻塞或触发拒绝策略 -
LinkedBlockingQueue：基于链表，节点分散在堆中，大量小对象易引发碎片和 GC 压力；size()是 O(n)，监控时慎用 - 别混用：比如用
LinkedBlockingQueue却配CallerRunsPolicy，可能因主线程执行慢任务进一步拖垮整个调用链
生产环境真正该禁用的写法
以下三行代码，在上线前必须被人工 review 拦住 —— 它们不是“方便”，是埋雷。
-
Executors.newFixedThreadPool(8)→ 隐含无界队列 -
Executors.newSingleThreadExecutor()→ 同样是无界LinkedBlockingQueue，单点故障+OOM 双重风险 -
new ThreadPoolExecutor(4, 4, 0, TimeUnit.SECONDS, new LinkedBlockingQueue())→ 看似手写，但漏了容量参数，本质还是一样
复杂点在于：有些框架（如 Dubbo 3.2+）已内置 MemorySafeLinkedBlockingQueue 这类增强实现，但它解决的是“按内存用量限流”，不是替代容量配置。别以为用了增强版，就可以回到无参构造的老路。
