Java单元测试验证多线程代码的核心是可控模拟并发并可靠验证线程安全：用ExecutorService+CountDownLatch替代Thread.sleep和join，以AtomicInteger等线程安全类型共享状态，并通过@RepeatedTest和@Timeout增强缺陷暴露。
Java 单元测试中验证多线程并发代码，核心不是“跑起来多个线程”，而是**可控地模拟并发执行，并可靠地验证结果与行为是否符合线程安全预期**。直接用 new Thread().start() 或随意 sleep 等待，极易导致测试不稳定、假通过或假失败。
用 ExecutorService + 显式等待替代 Thread.sleep()
避免在测试里写 Thread.sleep(2000)——它既不精确也不可移植。主线程可能提前退出，子线程还没执行完，测试就结束了。
- 使用
Executors.newFixedThreadPool(n)创建受控线程池 - 提交所有任务后，必须调用
shutdown()+awaitTermination() - 超时未完成时，应调用
shutdownNow()并检查是否残留阻塞逻辑
用同步工具确保测试可观测性
单纯启动线程不能保证你“看到”并发效果。要验证计数、状态变更或异常行为，得让主线程等所有工作线程真正结束。
-
CountDownLatch：适合“N个线程做完，主线程再断言”。初始化为任务数，每个线程完成时
countDown()，主线程await() - CyclicBarrier：适合需要多轮协同的场景，比如“所有线程先初始化，再同时开始操作”
- 不用
join()数组线程也可以，但ExecutorService配合CountDownLatch更简洁、更贴近真实线程池使用方式
共享状态必须线程安全
测试中若需统计执行次数、收集结果或校验最终值，普通变量（如 int count = 0）会被竞态条件破坏。
立即学习“Java免费学习笔记（深入）”；
- 用
AtomicInteger替代int，AtomicBoolean替代boolean - 收集多个线程输出时，优先选
ConcurrentLinkedQueue或CopyOnWriteArrayList，而非ArrayList - 如果被测方法本身用了
synchronized或ReentrantLock，测试只需验证其效果（如最终值正确、无异常），不必重复加锁
增强问题暴露概率
并发缺陷往往偶发。单次运行很难触发，需提高压力和不确定性。
- 用
@RepeatedTest(50)（JUnit 5）反复执行同一并发测试，增加竞态窗口出现机会 - 配合
@Timeout(value = 2, unit = TimeUnit.SECONDS)捕获死锁或无限等待 - 对关键路径，可故意引入微小延迟（如
Thread.onSpinWait()或短 sleep）放大调度不确定性，但仅用于调试，不进正式测试
