17370845950

newFixedThreadPool适合负载稳定、任务执行时间均匀的场景，如日志批量落库和定时报表生成；因使用无界队列，任务积压易致OOM，且线程数需据CPU核心数与I/O特性合理设置。

newFixedThreadPool 适合什么场景？为什么别乱设线程数

它创建的是固定大小的线程池，核心线程数 = 最大线程数 = nThreads，任务队列是无界的 LinkedBlockingQueue。适用于负载稳定、任务执行时间较均匀的后台服务，比如日志批量落库、定时报表生成。

• 线程数建议用 Runtime.getRuntime().availableProcessors() 作基准，再根据任务 I/O 密集程度微调（I/O 多可略高，CPU 密集建议 ≤ 核心数）
• 队列无界 → 一旦任务提交速度持续大于消费速度，LinkedBlockingQueue 会无限堆积，最终 OOM（堆内存耗尽）
• 不支持自定义拒绝策略，溢出时直接抛 RejectedExecutionException，但实际发生前队列早已吃光内存

ExecutorService pool = Executors.newFixedThreadPool(4);

newCachedThreadPool 看似灵活，但为什么生产环境慎用

它用的是 SynchronousQueue（容量为 0 的阻塞队列），没有空闲线程就新建，60 秒空闲自动回收。表面看“按需伸缩”，实则隐患明显。

• 突发流量下可能瞬间创建成百上千线程，压垮 JVM 或系统（线程栈内存 + 上下文切换开销）
• maximumPoolSize 被设为 Integer.MAX_VALUE，等于放弃对并发上限的控制
• 任务若长期阻塞（如等待 DB 响应），线程不会被及时回收，缓存失效机制形同虚设

ExecutorService pool = Executors.newCachedThreadPool(); // 等价于 new ThreadPoolExecutor(0, Integer.MAX_VALUE, 60L, TimeUnit.SECONDS, new SynchronousQueue())

newSingleThreadExecutor 和 newScheduledThreadPool 的真实用途

前者本质是单线程 + 无界队列的 ThreadPoolExecutor 包装，保证任务串行、FIFO 执行；后者专用于延迟/周期任务，底层是 ScheduledThreadPoolExecutor。

• newSingleThreadExecutor 不等于“只用一个线程安全”，它无法防止任务内部多线程污染（比如任务里自己 new Thread）
• newScheduledThreadPool 的核心线程不会被回收（keepAliveTime=0），适合长期运行的定时作业，但要注意：如果任务执行时间 > 周期间隔，后续任务会排队，不跳过也不并行
• 两者都不可配置拒绝策略，且无法获取底层 ThreadPoolExecutor 实例做监控或动态调参

ExecutorService single = Executors.newSingleThreadExecutor();
ScheduledExecutorService scheduler = Executors.newScheduledThreadPool(2);

为什么不推荐直接用 Executors？该用什么替代

所有 Executors 工厂方法都隐藏了关键参数，掩盖了线程池真正行为，尤其在错误处理、资源边界、可观测性上留了坑。阿里 Java 开发手册、Spring 官方文档、JDK 注释都明确建议：生产环境应直接使用 ThreadPoolExecutor 构造器。

• 必须显式指定：核心线程数、最大线程数、空闲存活时间、任务队列（建议有界，如 ArrayBlockingQueue）、拒绝策略（如 ThreadPoolExecutor.CallerRunsPolicy）
• 线程工厂应命名线程（便于排查日志），例如用 ThreadFactoryBuilder（Guava）或自定义实现
• 务必调用 shutdown() 或 shutdownNow()，避免线程池长期持有线程导致应用无法优雅退出

ThreadPoolExecutor pool = new ThreadPoolExecutor(
    2, 8,
    60L, TimeUnit.SECONDS,
    new ArrayBlockingQueue(100),
    new ThreadFactoryBuilder().setNameFormat("biz-task-%d").build(),
    new ThreadPoolExecutor.CallerRunsPolicy()
);

线程池不是“拿来即用”的黑盒，每个参数都在回答一个问题：当系统压力变化时，你希望它怎么妥协——是丢任务、等队列、还是拉新线程？漏掉任何一个，就等于把决策权交给了默认值。