阿里禁止使用executors创建线程池，因其默认的无界队列（linkedblockingqueue容量为integer.max_value）会导致任务持续堆积、内存耗尽并引发oom；同时cachedthreadpool等允许线程数达integer.max_value，易致资源耗尽。

Executors.newFixedThreadPool 创建的线程池，表面看是“固定线程数”，但真正决定它行为上限的，其实是背后那个默认的 LinkedBlockingQueue——它不是“大”，而是“几乎无界”。

默认构造即无界：Integer.MAX_VALUE 不等于无限，但足够危险

LinkedBlockingQueue 无参构造器源码就是：new LinkedBlockingQueue<runnable>()</runnable>，内部等价于 new LinkedBlockingQueue<runnable>(Integer.MAX_VALUE)</runnable>。这不是理论上的无限，而是约 21 亿个任务容量。在实际业务中，只要任务提交速度持续高于处理速度，队列就会不断膨胀，内存迟早被吃光。

• 比如线程池大小为 4，每个任务平均耗时 1 秒，但每毫秒提交 10 个任务 → 每秒积压 9990 个 → 2 分钟后队列就超百万
• JVM 堆内存若设为 1GB，存几百万 Runnable 实例（含闭包、上下文对象）极易触发 OOM

无界 ≠ 可靠：它不拒绝，也不限流，只默默堆积

有界队列（如 ArrayBlockingQueue）会在满时触发拒绝策略（如抛异常、丢弃、调用者运行），而 LinkedBlockingQueue 的 put() 方法会一直阻塞，offer() 在无界下永远返回 true。这意味着：系统不会主动告诉你“我撑不住了”，只会安静地走向崩溃。

• FixedThreadPool 的拒绝策略（如 AbortPolicy）根本不会被触发——因为队列永不“满”
• 监控指标里可能只看到队列 size 持续上涨，CPU 和线程数却稳定，误判为“系统健康”

为什么设计成无界？历史权衡与现实陷阱

早期 Java 并发库倾向于“先接住再处理”，避免因队列满导致上游调用失败。但这个设计假设了任务执行足够快、提交节奏可控。如今微服务高频调用、异步日志、批量导入等场景，让“提交远快于消费”成为常态。

• 它适合低频、稳态、可预测的任务（如后台定时清理）
• 不适合流量突增、IO 阻塞长、或上游不可控的场景（如 Web 请求转异步处理）

怎么安全用？别依赖默认，显式控制边界

真要保留 FixedThreadPool 的稳定性，又不想埋 OOM 隐患，就得绕过 Executors 工厂方法，手写 ThreadPoolExecutor 构造：

• 用 new LinkedBlockingQueue<runnable>(1000)</runnable> 替代无界队列，配合 AbortPolicy 或自定义拒绝逻辑
• 或换用 SynchronousQueue（零容量），逼迫线程池在 corePoolSize 耗尽后立即扩容（但 FixedThreadPool 的 max=core，所以这招对 newFixedThreadPool 无效——正说明它天生不适合弹性）
• 更务实的做法：改用 new ThreadPoolExecutor(n, n, 0L, ...) + 有界队列 + 拒绝策略，把“隐式无界”变成“显式可控”