单元测试中模拟异步线程的核心是隔离调度、替换执行单元、验证行为而非时序；应通过依赖注入传入同步执行器（如runnable::run或directexecutor）、completablefuture预完成、mock异步服务等方式实现快速确定性测试。
在单元测试中模拟异步线程，核心不是真的启动新线程，而是**隔离线程调度逻辑、替换可执行单元、验证行为而非时序**。Java 单元测试（如 JUnit）要求快速、确定、可重复，直接 new Thread() 或使用 ExecutorService 会引入竞态、延迟和资源泄漏风险。
用依赖注入解耦线程执行逻辑
把“何时异步执行”和“执行什么”分开。不要在被测类里直接写 new Thread(...) 或 executor.submit(...)，而是通过接口或函数式参数传入执行策略：
- 定义一个 Executor 类型的字段（如
private final Executor asyncExecutor;），构造时注入 - 测试时传入
Runnable::run（同步执行）、Executors.newSingleThreadExecutor()（慎用）或更推荐的DirectExecutor（Guava 提供，立即同步调用） - 例如：
new MyService(Commands::execute)或new MyService(Runnable::run)
用 CompletableFuture 配合 thenAccept/thenRun 做可测试链路
如果业务逻辑天然基于 CompletableFuture（比如调用 HTTP 客户端返回的 CF），测试时可直接 完成它，跳过异步环节：
- 在测试中创建
CompletableFuture<string> mockFuture = new CompletableFuture();</string> - 被测代码消费这个 CF（如
future.thenAccept(this::handleResult)） - 测试中调用
mockFuture.complete("test-data");，触发后续回调，无需 sleep 或 await - 断言 handleResult 是否被正确调用（可用 Mockito verify）
用 Mockito 模拟异步调用目标，避免真实线程启动
如果被测方法内部调用了某个服务的异步方法（如 notificationService.sendAsync(...)），就Mock 这个服务本身，而不是去 Mock 线程：
- 用
@Mock NotificationService notificationService; when(notificationService.sendAsync(any())).thenReturn(CompletableFuture.completedFuture(true));- 这样 sendAsync 看似“异步”，实际返回的是已完成的 CF，整个流程同步执行，无真实线程参与
- 再验证业务逻辑是否按预期处理了结果（比如数据库是否更新、事件是否发布）
不推荐但偶有用处：用 CountDownLatch 控制线程等待（仅限集成级验证）
仅当必须验证多线程协作顺序（如生产者-消费者、回调时机），且无法重构为上述方式时，才考虑：
- 在测试中创建
CountDownLatch latch = new CountDownLatch(1); - 在被测代码的异步分支末尾调用
latch.countDown(); - 测试主线程调用
latch.await(2, TimeUnit.SECONDS);等待完成 - 注意：这不是纯单元测试，有超时风险，应作为最后手段，且需设合理超时时间
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
