章
目
录
Executors工厂方法为开发者提供了一种看似便捷的创建线程池的方式，不少开发人员在实现并发任务处理时，会习惯性地使用Executors.newFixedThreadPool() 或者Executors.newCachedThreadPool()。但这种做法，实则隐藏着巨大的风险。
想象一下，你的应用在业务高峰期突然崩溃，日志里还出现大量OOM（内存溢出）异常，说不定罪魁祸首就是那几行使用Executors的代码。这也正是《阿里巴巴Java开发手册》将“禁止使用Executors创建线程池”列为强制规范的原因。接下来，我们深入分析一下这背后的原因。
一、Executors工厂方法的风险
（一）newFixedThreadPool和newSingleThreadExecutor的内存隐患
Executors中的newFixedThreadPool和newSingleThreadExecutor这两个方法，内部使用的是无界的LinkedBlockingQueue。这意味着请求队列可以无限制地增长，一旦任务数量过多，就极有可能引发OOM异常，把系统的内存“撑爆”。
（二）newCachedThreadPool和newScheduledThreadPool的线程危机
newCachedThreadPool和newScheduledThreadPool则允许创建的线程数量达到Integer.MAX_VALUE这么多。在实际运行中，如果系统负载较高，这就可能导致创建大量线程，从而耗尽系统资源，最终让系统不堪重负而崩溃。
（三）缺乏精细控制
Executors工厂方法采用预设参数，这种方式虽然简单，但却存在很大弊端。在实际业务场景中，每个项目的需求都各不相同，这些预设参数无法满足精细化调整的需求。而且，它还隐藏了线程池的实际运行机制，使得开发人员很难察觉到其中潜在的风险。
二、实际案例分析
（一）电商系统订单处理服务的OOM问题
在电商系统的秒杀活动期间，订单量会在短时间内暴增。假设订单处理服务使用Executors.newFixedThreadPool(10)来创建线程池，当大量请求涌入时，由于newFixedThreadPool内部使用的LinkedBlockingQueue没有设置容量上限，任务就会不断堆积，内存占用也会持续增加，最终引发内存溢出问题。
// 以下是存在问题的代码示例
// 创建一个固定线程数为10的线程池
ExecutorService executorService = Executors.newFixedThreadPool(10);
// 循环提交大量订单处理任务
for (Order order : orders) {
// 提交任务到线程池进行处理
executorService.submit(() -> processOrder(order));
}
要解决这个问题，可以使用ThreadPoolExecutor手动创建线程池，并设置合理的队列大小和拒绝策略。
// 优化后的代码
// 创建一个线程池，核心线程数为5，最大线程数为10，
// 线程空闲60秒后会被回收，使用容量为1000的有界队列，
// 并自定义线程工厂和拒绝策略
ThreadPoolExecutor executor = new ThreadPoolExecutor(
5, // 核心线程数
10, // 最大线程数
60L, TimeUnit.SECONDS, // 线程空闲超时时间
new LinkedBlockingQueue<>(1000), // 有界队列，容量为1000
new ThreadFactory() {
@Override
public Thread newThread(Runnable r) {
// 创建线程并设置名称
Thread t = new Thread(r);
t.setName("order-process-thread-" + t.getId());
return t;
}
},
new ThreadPoolExecutor.CallerRunsPolicy() // 拒绝策略：由调用线程执行
);
// 提交订单处理任务
for (Order order : orders) {
executor.submit(() -> processOrder(order));
}
通过这种方式，设置了队列的容量上限，能有效防止内存溢出；明确了线程数上限，避免线程过多导致系统资源耗尽。而且，使用CallerRunsPolicy拒绝策略，在系统超负荷时，能让调用线程来执行任务，从而自动降低系统处理速度，起到保护系统的作用。同时，自定义线程名称也方便在排查问题时快速定位。
（二）定时任务系统的线程爆炸问题
在企业内部的定时任务系统中，如果使用Executors.newCachedThreadPool()来处理各类定时任务，随着业务量的不断增长，可能会出现严重问题。
// 存在问题的代码
// 创建一个可缓存线程池
ExecutorService executor = Executors.newCachedThreadPool();
// 循环添加各种定时任务
for (Task task : tasks) {
// 提交任务到线程池执行
executor.submit(() -> executeTask(task));
}
由于newCachedThreadPool允许创建的最大线程数是Integer.MAX_VALUE，当系统负载升高时，会创建过多的线程。大量线程之间的上下文切换会产生巨大开销，最终导致系统崩溃，无法正常响应任务。
为了解决这个问题，同样需要手动创建线程池，限制最大线程数，并增加监控机制。
// 优化后的代码
// 创建一个线程池，核心线程数为10，最大线程数为50，
// 非核心线程存活时间为3分钟，使用容量为2000的有界队列，
// 自定义线程工厂和拒绝策略
ThreadPoolExecutor executor = new ThreadPoolExecutor(
10, // 核心线程数
50, // 最大线程数（明确上限）
3, TimeUnit.MINUTES, // 非核心线程存活时间
new ArrayBlockingQueue<>(2000), // 有界队列
new ThreadFactory() {
@Override
public Thread newThread(Runnable r) {
// 创建线程，设置名称并设为守护线程
Thread t = new Thread(r);
t.setName("scheduled-task-" + t.getId());
t.setDaemon(true);
return t;
}
},
new ThreadPoolExecutor.AbortPolicy() // 任务拒绝时抛出异常，便于及时发现问题
);
// 添加监控逻辑
executor.setRejectedExecutionHandler((r, e) -> {
// 记录任务被拒绝的日志信息
log.error("任务队列已满，任务被拒绝执行");
// 触发告警通知
alertService.sendAlert("线程池队列已满，请检查系统负载！");
// 抛出异常，提示线程池任务队列已满
throw new RejectedExecutionException("线程池任务队列已满");
});
// 提交定时任务
for (Task task : tasks) {
executor.submit(() -> executeTask(task));
}
这样一来，明确限制了最大线程数，避免了线程爆炸的问题，减少了线程上下文切换的开销。同时，添加的监控和告警逻辑，能在任务队列满时及时发现问题并发出通知，便于开发人员快速处理，保障系统稳定运行。
三、手动创建线程池的好处
（一）资源可控性显著提升
手动创建线程池时，可以明确指定线程数上限和任务队列容量。这样就能有效避免因资源耗尽而导致的系统故障，无论是防止OOM异常，还是避免线程过多引发的系统崩溃，都能让系统资源的使用更加稳定、可预测。
（二）业务适配性更佳
不同的业务场景对线程池的需求不同。手动创建线程池，可以根据业务特点精确调整参数。比如，对于IO密集型任务，可以设置较高的线程数，充分利用系统资源；对于CPU密集型任务，则设置相对较少的线程数，避免线程过多反而降低性能。通过这种方式，可以为不同业务场景定制最合适的线程池配置。
（三）异常处理更显优雅
手动创建线程池时，可以自定义拒绝策略。当系统超负荷时，能够选择合适的策略进行优雅降级。既可以让调用线程执行任务，也可以选择丢弃任务、丢弃最老的任务，或者抛出异常。甚至还能根据业务需求，实现更复杂的拒绝处理逻辑，比如将任务存入数据库，以便后续处理。
（四）监控能力大幅增强
手动创建线程池，为添加自定义监控和告警逻辑提供了便利。通过这些逻辑，可以实时监控线程池的状态，比如活跃线程数、队列深度等关键指标。一旦出现异常情况，能够及时触发告警，避免系统因问题未及时发现而崩溃。
（五）问题排查更为便捷
通过自定义ThreadFactory，可以给线程池中的线程合理命名。这样在查看日志和进行线程转储分析时，能够快速定位问题。而且，还可以添加额外的线程元数据，如线程所属的业务模块、优先级等，进一步提高问题排查的效率。
四、总结
《阿里巴巴Java开发手册》禁止使用Executors创建线程池，这可不是无端规定，而是从大量实际生产经验中总结出来的。在高并发场景下，如果线程池配置不当，引发的问题往往很突然，而且后果严重，可能在系统稳定运行很久后的业务高峰期瞬间爆发。
所以，正确的做法是遵循“自定义线程池参数、限制资源上限、设置拒绝策略、加强监控告警”的原则，根据具体业务特性，仔细调整线程池的配置。只有这样，才能让系统在高并发环境下稳定运行，避免因线程池问题导致的系统故障。
