异步任务在业务系统里随处可见：发短信、写日志、刷缓存、跑批处理，都习惯性挂一个 @Async 注解了事。但注解背后的线程池配置才是真正决定稳定性的部分。核心线程数给多少、队列长度设多长、拒绝策略选哪种，这些参数写错了编译器不会报错，单测跑不跑得过也不一定看得出来，往往要等到线上流量一上来，任务堆积、线程打满、请求被拒绝，问题才集中爆发。与其事后排查，不如在单元测试阶段就把线程池配置的关键行为验证清楚，让配置错误在构建阶段就失败。这篇文章就来聊聊具体怎么做。
先搞清楚 @Async 的生效机制，否则测试方向就错了
很多人写测试之前没弄明白 @Async 是怎么工作的，结果测了半天测的是个假象。@Async 的本质是 Spring AOP 代理：容器启动时，如果检测到 @EnableAsync 注解，会为含有 @Async 方法的 Bean 创建代理对象，调用方调用的其实是代理，代理把方法体包装成任务提交给线程池执行。
这个机制直接带来三个容易被忽视的失效场景。第一，同类内部调用不走代理：一个 Bean 的方法 A 调用同类的 @Async 方法 B，等于 this.B()，绕过了代理，异步根本不生效。第二，方法必须是 public 且不能是 static，否则代理无法拦截。第三，异步方法抛出的异常不会传播到调用方，默认情况下就像被黑洞吞掉一样，日志里可能只有一行不起眼的警告。写测试时如果你不知道这些，很容易写出「看起来通过了但其实什么都没验证」的用例。
另外一个关键点：@Async 默认使用的线程池。如果 Spring 上下文中只有一个 TaskExecutor 类型的 Bean，它会自动使用；如果有多个而没在 @Async("xxxExecutor") 里指定名字，Spring 会先找名为 taskExecutor 的 Bean，找不到还可能退化到 SimpleAsyncTaskExecutor——这个实现每次执行任务都新建线程，不复用，在高频调用下会直接把系统拖垮。单元测试的重要价值之一，就是把「到底用了哪个线程池」这件事变成一个可以被断言的事实。
针对线程池参数与拒绝策略的配置测试
线程池配置类本身是第一个测试对象。下面是一个典型的配置类：
@Configuration
@EnableAsync
public class AsyncConfig {
@Bean("businessExecutor")
public ThreadPoolTaskExecutor businessExecutor() {
ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor();
executor.setCorePoolSize(8);
executor.setMaxPoolSize(16);
executor.setQueueCapacity(200);
executor.setKeepAliveSeconds(60);
// 关键任务不允许静默丢弃，交给调用方线程执行形成天然背压
executor.setRejectedExecutionHandler(new ThreadPoolExecutor.CallerRunsPolicy());
executor.setThreadNamePrefix("biz-async-");
executor.setWaitForTasksToCompleteOnShutdown(true);
executor.setAwaitTerminationSeconds(30);
executor.initialize();
return executor;
}
}对这类配置，最直接的测试是加载上下文后断言关键参数没有被误改：
@SpringBootTest
class AsyncConfigTest {
@Autowired
@Qualifier("businessExecutor")
private ThreadPoolTaskExecutor executor;
@Test
void threadPoolParametersShouldMatchConfiguration() {
ThreadPoolExecutor tpe = executor.getThreadPoolExecutor();
assertEquals(8, tpe.getCorePoolSize());
assertEquals(16, tpe.getMaximumPoolSize());
assertEquals(200, tpe.getQueue().size() + tpe.getQueue().remainingCapacity());
assertEquals("biz-async-", executor.getThreadNamePrefix());
}
@Test
void rejectedTasksShouldFallBackToCallerThread() {
ThreadPoolExecutor tpe = executor.getThreadPoolExecutor();
assertTrue(tpe.getRejectedExecutionHandler()
instanceof ThreadPoolExecutor.CallerRunsPolicy);
}
}注意队列容量的断言写法：ThreadPoolTaskExecutor 内部用的是 LinkedBlockingQueue，getQueue().size() 加上 remainingCapacity() 才是配置的总容量。此外还要测拒绝策略的行为而不只是类型——比如配置了 AbortPolicy 时，任务超载应该抛出 TaskRejectedException，这个行为对上层代码是否友好，值得单独写一个用例验证。
拒绝策略的选择本身就是业务决策：AbortPolicy 快速失败适合可重试场景；CallerRunsPolicy 提供背压但会阻塞调用线程，不适合 Web 请求线程；DiscardPolicy 静默丢任务几乎总是错的，除非业务明确允许。测试里把这些行为固化下来，等于给未来的配置修改加了一道保险，谁改错了构建立刻红。
异步方法的返回值与异常传播测试
@Async 方法如果返回 void，测试只能验证「任务被提交了」，无法验证执行结果。推荐统一让异步方法返回 CompletableFuture，这样测试可以精确等待结果：
@Service
public class NotificationService {
@Async("businessExecutor")
public CompletableFuture<Boolean> sendAsync(String userId) {
if (userId == null) {
throw new IllegalArgumentException("userId 不能为空");
}
return CompletableFuture.completedFuture(true);
}
}对应的测试用 JUnit5 可以这样写：
@SpringBootTest
class NotificationServiceTest {
@Autowired
private NotificationService service;
@Test
void shouldExecuteInPoolThread() throws Exception {
CompletableFuture<Boolean> future = service.sendAsync("u1001");
assertTrue(future.get(3, TimeUnit.SECONDS));
}
@Test
void exceptionShouldBeCapturedInFuture() {
CompletableFuture<Boolean> future = service.sendAsync(null);
ExecutionException ex = assertThrows(ExecutionException.class,
() -> future.get(3, TimeUnit.SECONDS));
assertTrue(ex.getCause() instanceof IllegalArgumentException);
}
}第二个用例特别重要：它验证了异步异常没有被吞掉。如果有人把方法的返回类型从 CompletableFuture 改成 void，异常传播路径就变了，这个测试会失败，从而提醒你补充异步异常处理器（比如实现 AsyncConfigurer 的 getAsyncUncaughtExceptionHandler），把异常推到监控告警里。
如果你还想验证任务确实运行在业务线程池而非主线程，可以捕获执行时的线程名做断言：
@Async("businessExecutor")
public CompletableFuture<String> currentThreadName() {
return CompletableFuture.completedFuture(Thread.currentThread().getName());
}
// 测试断言
assertTrue(service.currentThreadName().get(3, TimeUnit.SECONDS)
.startsWith("biz-async-"));这种断言能有效捕捉「线程池配置未生效、退化到默认执行器」的隐性回归，是 @Async 测试里性价比最高的一个用例。
避免测试相互干扰与资源泄漏的工程细节
线程池测试最常见的坑是用例之间互相污染。@SpringBootTest 默认复用同一个上下文，线程池里的线程会跨用例存活，前一个用例提交的慢任务可能影响后一个用例的断言。几个实用做法：给每个测试类使用独立上下文（例如通过 @DirtiesContext 或不同 的 @TestPropertySource）；异步测试里所有 future.get() 都必须带超时参数，避免一个卡死的任务挂住整个 CI；如果需要精确控制执行时机，可以在测试里注入一个专用的同步执行器。
让异步变同步是简化测试的经典手法。自定义一个在当前线程直接执行任务的 Executor，然后把它指定为测试环境的线程池：
@TestConfiguration
public class SyncExecutorConfig {
@Bean("businessExecutor")
public ThreadPoolTaskExecutor businessExecutor() {
ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor() {
@Override
protected ExecutorService initializeExecutor(
ThreadFactory threadFactory, RejectedExecutionHandler handler) {
return new CurrentThreadExecutorService();
}
};
executor.initialize();
return executor;
}
}这样异步方法在测试中变成同步执行，断言不需要等待，也不存在时序抖动，特别适合业务逻辑本身复杂、异步只是包装的场景。但要记住：同步化之后，与线程切换相关的行为（比如 ThreadLocal 丢失、SecurityContext 不传递）就测不到了。ThreadLocal 在异步线程中不自动传递是一个高频线上问题，如果你依赖 RequestContextHolder 或 MDC 打日志链路，一定要保留至少一个真实异步执行的测试用例，验证跨线程上下文传递方案（如 TaskDecorator）确实生效：
executor.setTaskDecorator(runnable -> {
// 主线程执行 decorate，子线程执行 runnable 前 restore
Map<String, String> mdc = MDC.getCopyOfContextMap();
return () -> {
try {
if (mdc != null) MDC.setContextMap(mdc);
runnable.run();
} finally {
MDC.clear();
}
};
});最后是资源清理。测试结束前调用 executor.shutdown()，或者在配置里开启 setWaitForTasksToCompleteOnShutdown(true) 配合 awaitTerminationSeconds，避免残留线程阻止 JVM 退出，导致 CI 上出现「测试全绿但构建卡死」的诡异现象。把这些细节做扎实，你的线程池配置就不再是「写完就扔」的静态代码，而是一套每次构建都被验证的活契约。
Spring @Async线程池配置单元测试修改时间：2026-09-13 06:24:32