在 SpringBoot 项目中，线程池（ThreadPoolTaskExecutor）是处理并发任务的核心组件，常用于异步处理、批量操作、定时任务等场景。但很多开发者在使用线程池时，总会遇到各种报错，导致并发任务执行失败、服务卡顿：
✅ 线程池提交任务报 RejectedExecutionException（任务被拒绝）； ✅ 线程池执行任务报 NullPointerException（线程安全问题）； ✅ 线程池耗尽，任务堆积，服务响应超时； ✅ 异步任务执行完成后，结果无法获取、回调失败； ✅ 线程池配置不合理，导致资源浪费或并发瓶颈。
今天这篇，把 SpringBoot 整合 ThreadPoolTaskExecutor 的6大高频报错一次性讲透，结合并发实战场景，每个报错都给「报错信息+根因分析+解决方案+可复制代码」，从配置到使用、从排查到优化全覆盖，新手也能轻松避坑，建议收藏，并发开发时直接查！
一、先搞懂：线程池报错核心逻辑
SpringBoot 中 ThreadPoolTaskExecutor 报错，本质围绕「线程池生命周期」「任务提交规则」「线程安全」三大核心，常见问题方向：
配置错误：核心线程数、最大线程数、队列容量配置不合理，导致任务拒绝、线程耗尽；
使用错误：任务提交方式不当、异步任务无返回值处理、线程安全问题（如共享变量未加锁）；
资源问题：线程泄漏、线程池未关闭、资源耗尽，导致服务卡顿、OOM。
排查优先级：先检查线程池配置 → 再排查任务提交和执行逻辑 → 最后检查线程安全和资源释放，高效定位问题。
二、6大高频线程池报错场景+解决方案（按出现概率排序）
场景1：最经典——任务被拒绝，报 RejectedExecutionException
1. 典型报错信息
java.util.concurrent.RejectedExecutionException: Task java.util.concurrent.FutureTask@12345678 rejected from org.springframework.scheduling.concurrent.ThreadPoolTaskExecutor@87654321[Running, pool size = 10, active threads = 10, queued tasks = 20, completed tasks = 0]
2. 错误原因（3种高频情况）
线程池达到最大线程数（maxPoolSize），且任务队列已满（queueCapacity），无法接收新任务（核心原因）；
线程池已被关闭（shutdown），仍提交新任务；
拒绝策略配置不合理（如默认AbortPolicy，直接拒绝并抛异常），未做降级处理。
3. 解决方案
方案1：优化线程池配置（根据业务调整，核心公式：核心线程数 = CPU核心数 * 2 + 1）
@Configuration public class ThreadPoolConfig { @Bean public ThreadPoolTaskExecutor threadPoolTaskExecutor() { ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor(); // 核心线程数（默认5），根据CPU核心数调整 int corePoolSize = Runtime.getRuntime().availableProcessors() * 2 + 1; executor.setCorePoolSize(corePoolSize); // 最大线程数，核心线程数的2倍，避免线程过多导致上下文切换 executor.setMaxPoolSize(corePoolSize * 2); // 任务队列容量，核心线程数*10，避免队列过大导致任务堆积 executor.setQueueCapacity(corePoolSize * 10); // 线程空闲时间（秒），超过该时间，非核心线程会被销毁 executor.setKeepAliveSeconds(60); // 线程名称前缀，方便日志排查 executor.setThreadNamePrefix("task-thread-"); // 拒绝策略（关键：避免直接抛异常） // CallerRunsPolicy：当前线程（提交任务的线程）直接执行该任务，降级处理 executor.setRejectedExecutionHandler(new ThreadPoolExecutor.CallerRunsPolicy()); // 初始化线程池 executor.initialize(); return executor; } }
方案2：避免线程池关闭后提交任务
@Autowired private ThreadPoolTaskExecutor threadPoolTaskExecutor; public void submitTask() { // 提交任务前，判断线程池是否处于运行状态 if (!threadPoolTaskExecutor.isRunning()) { log.error("线程池已关闭，无法提交任务"); return; } // 提交任务 threadPoolTaskExecutor.submit(() -> { // 任务逻辑 System.out.println("执行异步任务"); }); }
方案3：选择合适的拒绝策略（根据业务场景）
CallerRunsPolicy（推荐）：提交任务的线程自己执行任务，避免任务丢失，适合非核心任务；
DiscardPolicy：静默丢弃任务，不抛异常，适合可丢失的任务（如日志收集）；
DiscardOldestPolicy：丢弃队列中最老的任务，提交新任务，适合任务有先后顺序但可丢弃老任务的场景；
AbortPolicy（默认）：直接抛异常，适合核心任务，需及时感知问题。
场景2：最头疼——线程安全问题，报 NullPointerException/数据错乱
1. 典型报错信息
java.lang.NullPointerException at com.xxx.servkService.lambda$submitTask$0(TaskService.java:25) java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) t java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) a at ice.Tas
2. 错误原因（2种高频情况）
线程池中执行的任务，引用了外部非线程安全的对象（如ArrayList、HashMap），多线程并发修改导致数据错乱、空指针；
任务中使用了未初始化的变量，或变量被其他线程修改，导致线程执行时变量为null。
3. 解决方案
@Service public class TaskService { @Autowired private ThreadPoolTaskExecutor threadPoolTaskExecutor; // 错误示例：使用非线程安全的ArrayList private List<String> taskList = new ArrayList<>(); // 正确示例：使用线程安全的集合 private List<String> safeTaskList = new CopyOnWriteArrayList<>(); public void submitTask(String task) { // 错误：多线程并发修改ArrayList，会导致数据错乱、空指针 threadPoolTaskExecutor.submit(() -> { taskList.add(task); // 非线程安全 }); // 正确：使用线程安全集合，或加锁 threadPoolTaskExecutor.submit(() -> { // 方式1：线程安全集合 safeTaskList.add(task); // 方式2：对非线程安全对象加锁 synchronized (taskList) { taskList.add(task); } }); } }
补充：常见线程安全集合：CopyOnWriteArrayList、ConcurrentHashMap；非线程安全集合：ArrayList、HashMap、HashSet，多线程环境下避免直接使用。
场景3：线程池耗尽，任务堆积，服务响应超时
1. 典型现象
线程池核心线程数、最大线程数全部占满，任务队列堆积严重，新提交的任务无法及时执行，服务接口响应超时，日志中出现大量“任务等待执行”的记录。
2. 错误原因（3种高频情况）
线程池配置过小（核心线程数、最大线程数、队列容量不足），无法承载并发任务；
任务执行时间过长（如数据库慢查询、远程调用超时），导致线程长期被占用，无法释放；
任务提交频率过高，超过线程池的处理能力，导致任务堆积。
3. 解决方案
优化线程池配置：根据业务并发量，调整核心线程数、最大线程数、队列容量（参考场景1的配置公式）；
优化任务执行逻辑：排查任务中耗时操作（如慢SQL、远程调用），进行优化（如加索引、异步调用）；
监控线程池状态，及时扩容：通过SpringBoot Actuator监控线程池运行状态。
// 1. 引入Actuator依赖，监控线程池 <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-actuator</artifactId> </dependency> // 2. yml配置，暴露线程池监控端点 management: endpoints: web: exposure: include: threadpool # 暴露线程池监控端点 endpoint: threadpool: enabled: true // 3. 代码中监控线程池状态（可选） public void monitorThreadPool() { int activeCount = threadPoolTaskExecutor.getActiveCount(); // 活跃线程数 long completedTaskCount = threadPoolTaskExecutor.getCompletedTaskCount(); // 已完成任务数 int queueSize = threadPoolTaskExecutor.getQueueSize(); // 队列中等待的任务数 log.info("线程池状态：活跃线程数={}, 已完成任务数={}, 等待任务数={}", activeCount, completedTaskCount, queueSize); // 当等待任务数超过阈值，触发告警或扩容 if (queueSize > 100) { log.error("线程池任务堆积严重，等待任务数：{}", queueSize); // 此处可添加告警逻辑（如钉钉、邮件告警） } }
场景4：异步任务无返回值，执行失败无法感知
1. 典型现象
使用 threadPoolTaskExecutor.submit(Runnable) 提交异步任务，任务执行过程中抛异常，但控制台无报错日志，无法感知任务执行失败，排查困难。
2. 错误原因
Runnable 接口的 run() 方法无返回值、不抛异常，线程池执行过程中若出现异常，会被线程池内部捕获，不会主动输出日志，导致无法感知失败。
3. 解决方案
方案1：使用 Callable 接口（有返回值、可抛异常），配合 Future 获取执行结果
public void submitCallableTask() { // 提交Callable任务，有返回值、可抛异常 Future<String> future = threadPoolTaskExecutor.submit(() -> { // 任务逻辑，可抛异常 if (true) { throw new RuntimeException("任务执行失败"); } return "任务执行成功"; }); // 获取任务执行结果，捕获异常 try { String result = future.get(); // 阻塞等待任务执行完成 log.info("任务执行结果：{}", result); } catch (InterruptedException e) { log.error("任务被中断", e); } catch (ExecutionException e) { log.error("任务执行失败", e.getCause()); // 获取真实异常信息 } }
方案2：使用 ThreadPoolTaskExecutor 的 execute() 方法，配合全局异常处理
// 1. 自定义线程工厂，捕获线程执行异常 public class CustomThreadFactory implements ThreadFactory { private final ThreadFactory defaultFactory = Executors.defaultThreadFactory(); @Override public Thread newThread(Runnable r) { Thread thread = defaultFactory.newThread(r); // 捕获线程执行异常 thread.setUncaughtExceptionHandler((t, e) -> { log.error("线程 {} 执行任务失败", t.getName(), e); }); return thread; } } // 2. 线程池配置中使用自定义线程工厂 executor.setThreadFactory(new CustomThreadFactory()); // 3. 使用execute()方法提交任务 threadPoolTaskExecutor.execute(() -> { // 任务逻辑，抛异常会被自定义线程工厂捕获并输出日志 throw new RuntimeException("任务执行失败"); });
场景5：线程泄漏，导致OOM（内存溢出）
1. 典型报错信息
java.lang.OutOfMemoryError: Java heap space t java.util.concurrent.ThreadPoolExecutor$Worker.<init>(ThreadPoolExecutor.java:612) java.util.concurrent.ThreadPoolExecutor.addWorker(ThreadPoolExecutor.java:925) at a
2. 错误原因
线程池核心线程数设置过大，且核心线程长期空闲但无法销毁（核心线程默认不会自动销毁）；
任务中存在无限循环、死锁，导致线程一直被占用，无法释放；
线程池未正确关闭，程序退出时线程未释放，导致资源泄漏。
3. 解决方案
// 1. 合理设置核心线程数，避免过大 // 核心线程数 = CPU核心数 * 2 + 1，避免核心线程过多导致内存占用 int corePoolSize = Runtime.getRuntime().availableProcessors() * 2 + 1; executor.setCorePoolSize(corePoolSize); // 2. 避免任务中无限循环、死锁，确保任务能正常结束 threadPoolTaskExecutor.submit(() -> { try { // 任务逻辑，避免无限循环 if (condition) { return; // 正常结束 } } catch (Exception e) { log.error("任务执行异常", e); } }); // 3. 程序退出时，关闭线程池，释放资源 @PreDestroy // 容器销毁时执行 public void destroyThreadPool() { // 优雅关闭：等待所有任务执行完成后，关闭线程池 threadPoolTaskExecutor.shutdown(); try { // 等待60秒，若任务仍未执行完成，强制关闭 if (!threadPoolTaskExecutor.awaitTermination(60, TimeUnit.SECONDS)) { threadPoolTaskExecutor.shutdownNow(); // 强制关闭 } } catch (InterruptedException e) { threadPoolTaskExecutor.shutdownNow(); } log.info("线程池已关闭"); }
场景6：定时任务使用线程池，报 TaskRejectedException
1. 典型报错信息
org.springframework.scheduling.support.TaskRejectedException: Executor [org.springframework.scheduling.concurrent.ThreadPoolTaskExecutor@12345678] rejected task [org.springframework.scheduling.support.ScheduledMethodRunnable@87654321]
2. 错误原因
SpringBoot 定时任务（@Scheduled）默认使用单线程执行，若定时任务执行时间过长，会导致后续任务堆积，若配置了线程池，线程池耗尽时会报任务拒绝异常。
3. 解决方案
给定时任务配置专属线程池，避免与业务线程池冲突，合理设置线程数。
@Configuration @EnableScheduling // 开启定时任务 public class ScheduledConfig implements SchedulingConfigurer { @Autowired private ThreadPoolTaskExecutor scheduledThreadPool; // 配置定时任务线程池 @Bean public ThreadPoolTaskExecutor scheduledThreadPool() { ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor(); executor.setCorePoolSize(5); // 定时任务核心线程数，根据定时任务数量调整 executor.setMaxPoolSize(10); executor.setQueueCapacity(20); executor.setThreadNamePrefix("scheduled-thread-"); executor.setRejectedExecutionHandler(new ThreadPoolExecutor.CallerRunsPolicy()); executor.initialize(); return executor; } // 让定时任务使用自定义线程池 @Override public void configureTasks(ScheduledTaskRegistrar taskRegistrar) { taskRegistrar.setTaskExecutor(scheduledThreadPool); } } // 定时任务示例 @Scheduled(cron = "0/10 * * * * ?") // 每10秒执行一次 public void scheduledTask() { // 定时任务逻辑 log.info("定时任务执行"); }
三、线程池万能排查步骤（记这6步）
查配置：核心线程数、最大线程数、队列容量、拒绝策略是否合理；
查任务：任务执行时间、是否有死锁、无限循环，是否使用非线程安全对象；
查状态：通过Actuator或代码监控线程池活跃线程数、任务堆积数；
查异常：任务提交方式是否正确（Callable/ Runnable），是否捕获异常；
查资源：线程池是否关闭，是否存在线程泄漏；
查并发：是否存在多线程共享变量，是否做了线程安全处理。
四、避坑指南（线程池开发必看）
配置规范：核心线程数按 CPU 核心数调整，避免过大或过小；拒绝策略优先选择 CallerRunsPolicy，避免任务丢失；
线程安全：多线程环境下，避免使用非线程安全集合，必要时加锁或使用线程安全集合；
任务监控：通过 Actuator 监控线程池状态，及时发现任务堆积、线程耗尽问题；
任务提交：核心任务用 Callable，便于捕获异常、获取结果；非核心任务用 Runnable，配合异常处理；
资源释放：程序退出时，优雅关闭线程池，避免线程泄漏；
定时任务：给定时任务配置专属线程池，避免与业务线程池冲突，防止任务拒绝。
五、总结
SpringBoot 线程池报错，核心就3个问题：「配置不合理」「使用不规范」「线程不安全」，记住：
任务拒绝：查配置、拒绝策略，优化线程池容量；
线程安全：查共享变量、集合类型，加锁或使用线程安全集合；
任务堆积：查任务执行时间、并发量，优化任务逻辑、扩容线程池；
线程泄漏：查核心线程数、任务逻辑，优雅关闭线程池；
定时任务：配置专属线程池，避免冲突。
线程池是并发开发的核心，只要配置合理、使用规范，就能避免99%的报错。掌握本文的场景和解决方案，并发开发时能快速定位线程池相关问题，高效解决，让异步任务、定时任务稳定运行。
如果这篇文章帮到你了，记得点赞+收藏🌟！评论区说说你遇到过最坑的线程池问题，一起交流避坑经验～
