1. 为什么Executors工厂类存在OOM风险先讲个真实案例去年我们团队有个新同事接手了一个老项目在某个促销活动日突然出现服务崩溃。排查日志发现是newFixedThreadPool创建的线程池导致内存溢出。这让我意识到很多开发者并不清楚Executors工具类的潜在风险。Executors提供的四种线程池实现本质上都是ThreadPoolExecutor的包装但参数设置存在严重隐患FixedThreadPool/SingleThreadPool使用无界队列LinkedBlockingQueue最大堆积Integer.MAX_VALUE个任务CachedThreadPool/ScheduledThreadPool允许创建Integer.MAX_VALUE个线程我做过一个极端测试用8MB堆内存运行newFixedThreadPool提交无限任务5分钟后就出现OOM。而同样的场景使用合理配置的ThreadPoolExecutor虽然会拒绝任务但系统保持稳定。2. 从源码看线程池设计差异打开JDK源码会发现关键差异在构造方法// FixedThreadPool源码 public static ExecutorService newFixedThreadPool(int nThreads) { return new ThreadPoolExecutor(nThreads, nThreads, 0L, TimeUnit.MILLISECONDS, new LinkedBlockingQueueRunnable()); } // 推荐的手动创建方式 new ThreadPoolExecutor( 10, // 核心线程 50, // 最大线程 60L, TimeUnit.SECONDS, new ArrayBlockingQueue(100) // 有界队列 );阻塞队列的选择是核心问题LinkedBlockingQueue默认构造器会创建容量为Integer.MAX_VALUE的队列ArrayBlockingQueue必须显式指定容量否则编译报错这就像去银行办业务无界队列相当于不限制排队人数最终大厅挤爆OOM有界队列相当于取号机满员后拒绝新客户RejectedExecutionException3. ThreadPoolExecutor的7大核心参数面试时被问到线程池参数怎么设置很多人只能答出前三个。其实完整的参数体系包含参数名作用设置建议corePoolSize常驻核心线程数CPU密集型N1IO密集型2NmaximumPoolSize最大线程数corePoolSize ≤ max ≤ 2NkeepAliveTime空闲线程存活时间默认60秒IO密集型可缩短unit时间单位推荐TimeUnit.SECONDSworkQueue任务队列根据业务特点选择- ArrayBlockingQueue固定容量- SynchronousQueue无缓冲- PriorityBlockingQueue优先级threadFactory线程工厂建议自定义命名规则handler拒绝策略根据业务选择- AbortPolicy默认抛异常- CallerRunsPolicy回退到调用线程- DiscardOldestPolicy丢弃最老任务特别强调线程工厂的重要性线上排查问题时规范的线程命名能快速定位问题源。推荐使用Guava的ThreadFactoryBuilderThreadFactory namedThreadFactory new ThreadFactoryBuilder() .setNameFormat(order-process-%d) .setDaemon(true) .build();4. 最佳实践与避坑指南结合多年踩坑经验分享几个实用技巧1. 监控与动态调整Spring Boot项目可以使用ThreadPoolTaskExecutor通过/actuator/metrics暴露指标executor.active.count活跃线程数executor.queue.remaining.capacity队列剩余容量2. 合理设置队列容量计算公式参考队列容量 峰值QPS × 平均处理时间(s) × 容忍时间(s)例如QPS100平均处理100ms希望容忍10秒积压100 × 0.1 × 10 1003. 优雅关闭策略executor.shutdown(); // 停止接收新任务 if (!executor.awaitTermination(60, SECONDS)) { executor.shutdownNow(); // 强制终止 }4. 异常处理规范任务内部必须捕获异常实现Thread.UncaughtExceptionHandler使用Future获取执行异常曾经遇到过一个线上事故某个定时任务抛出NPE后线程终止由于使用ScheduledThreadPool最终导致所有定时任务瘫痪。这就是未处理运行时异常的典型后果。5. 面试深度问题准备当面试官追问为什么不用Executors时可以这样分层回答表面现象可能引发OOM直接原因使用无界队列或无限线程设计哲学隐藏关键参数不符合显式优于隐式原则最佳实践需要根据业务特征精细化配置对于如何确定线程数这个问题要分场景CPU密集型N1避免上下文切换损耗IO密集型2N利用等待时间混合型N*(1WT/ST)最后记住没有放之四海而皆准的配置必须通过压测验证。我在电商项目中就遇到过同样的配置在订单服务和库存服务表现截然不同最终订单服务采用SynchronousQueue而库存服务用ArrayBlockingQueue才达到最优性能。