Java并发编程中的线程池使用与优化策略

Executors.newFixedThreadPool() 因使用无界队列易致OOM,应改用显式配置的ThreadPoolExecutor,配ArrayBlockingQueue、合理拒绝策略及监控;shutdown()需配合awaitTermination(),keepAliveTime默认不作用于核心线程,allowCoreThreadTimeOut(true)可启用动态伸缩。

为什么 Executors.newFixedThreadPool() 在生产环境要慎用

它底层直接使用 LinkedBlockingQueue 且容量为 Integer.MAX_VALUE,任务持续提交时队列无限增长,极易引发 OOM。这不是线程不够用的问题,而是背压机制缺失导致的内存失控。

  • 替代方案优先选 ThreadPoolExecutor 手动构造,显式控制 corePoolSizemaximumPoolSizeworkQueue(如 ArrayBlockingQueue)和 RejectedExecutionHandler
  • 若必须用 Executors 工厂方法,至少搭配自定义 ThreadFactory(用于命名线程)和 RejectedExecutionHandler(如 CallerRunsPolicy
  • 监控队列长度:通过 getQueue().size() 定期采样,结合 Prometheus 暴露为指标,避免“等发现时已挂了”

如何正确处理线程池拒绝策略(RejectedExecutionHandler)

默认的 AbortPolicy 直接抛 RejectedExecutionException,但很多业务代码没做 try-catch,结果异常吞掉、任务静默丢失。这比慢一点更危险——你根本不知道任务没执行。

  • DiscardPolicy:静默丢弃,适合日志、埋点等非关键任务
  • DiscardOldestPolicy:丢弃队列头任务,再尝试提交当前任务;注意它不保证 FIFO,且可能反复挤掉同一任务
  • CallerRunsPolicy

    由提交线程自己执行任务,可自然降速,但会阻塞调用方,需评估调用链是否允许
  • 自定义策略推荐:记录被拒任务的 toString() + 当前时间戳 + 线程池状态(getActiveCount()getQueue().size()),方便事后回溯

线程池 shutdown() 和 shutdownNow() 的真实行为差异

shutdown() 只是停止接收新任务,已提交任务(包括队列中等待的)仍会执行完;shutdownNow() 尝试中断所有正在运行的线程,并返回队列中未执行的任务列表——但它不能保证线程真的停止,因为中断只是“建议”。

  • 调用 shutdown() 后务必配合 awaitTermination(long, TimeUnit) 等待结束,超时后才考虑 shutdownNow()
  • RunnableCallable 中必须响应中断:检查 Thread.currentThread().isInterrupted(),或捕获 InterruptedException 并恢复中断状态(Thread.currentThread().interrupt()
  • 常见陷阱:JDBC 查询、OkHttp 请求、文件读写等阻塞操作不会自动响应中断,需主动设置超时(如 socketTimeoutconnectTimeout)或使用可中断 API(如 FileChannel.lock() 的带 interrupt 版本)

ThreadPoolExecutor 的 keepAliveTime 对核心线程是否生效

默认情况下,keepAliveTime 只对非核心线程有效;但如果你调用了 allowCoreThreadTimeOut(true),那么核心线程空闲超过该时间也会被回收。这是动态伸缩的关键开关,但多数人忽略它。

  • 适用场景:流量波峰波谷明显的服务(如定时报表生成),避免低峰期空耗线程资源
  • 副作用:频繁创建/销毁线程有开销,且线程重建后 TLS(ThreadLocal)变量需重新初始化,可能引发 NPE 或脏数据
  • 建议搭配 ThreadFactory 使用:在 newThread() 中预设好关键 ThreadLocal 初始值,避免首次执行时判空逻辑出错
public class CustomThreadFactory implements ThreadFactory {
    private final AtomicInteger threadNumber = new AtomicInteger(1);
    private final String namePrefix;

    public CustomThreadFactory(String namePrefix) {
        this.namePrefix = namePrefix + "-thread-";
    }

    @Override
    public Thread newThread(Runnable r) {
        Thread t = new Thread(r, namePrefix + threadNumber.getAndIncrement());
        t.setDaemon(false);
        // 预设关键 ThreadLocal
        MyContext.initForThread(t);
        return t;
    }
}
线程池不是配置完就高枕无忧的组件,它的健康度取决于你是否真正理解每个参数在 GC、中断、阻塞 I/O、队列溢出等边界场景下的联动反应。尤其当服务接入分布式追踪或异步日志时,线程复用可能导致 MDC 透传失效、上下文污染——这些细节往往比“怎么建池”更决定线上稳定性。