线程池任务堆积风险与OOM问题解析

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 这类增强实现，但它解决的是“按内存用量限流”，不是替代容量配置。别以为用了增强版，就可以回到无参构造的老路。