java单元测试验证多线程并发的核心是可控、可断言、可重复地暴露问题；需用countdownlatch、cyclicbarrier或awaittermination()显式同步，避免sleep；线程池须每次新建并彻底清理；共享状态用原子类或线程安全集合；通过重复执行和超时机制提升缺陷暴露概率。
Java 单元测试对多线程并发场景做验证，核心不是“跑起来多个线程”，而是**可控、可断言、可重复地暴露并发问题**。直接用 Thread.sleep() 等待或忽略线程生命周期，会导致测试不稳定、假通过、CI卡死等问题。
用同步工具显式等待线程完成
避免靠 Thread.sleep() 猜时间。主线程必须等所有工作线程真正结束，才能做断言。
-
CountDownLatch：适合“一个主线程等 N 个子线程完成”。初始化时设为任务数，每个子线程执行完调
countDown()，主线程调await() - CyclicBarrier：适合“N 个线程互相等待，在某一点齐步开始或结束”，比如模拟同时发起请求
-
ExecutorService.awaitTermination()：配合
shutdown()使用，是管理线程池的标准方式；超时后应调shutdownNow()并检查是否真有阻塞逻辑
正确管理线程资源，防止测试污染
每次测试都新建线程池，用完必须彻底清理——否则残留的非守护线程会让 JUnit 进程挂住，尤其在 Maven 多模块或 CI 中会连锁失败。
- 用
Executors.newFixedThreadPool(n)或newCachedThreadPool()创建，不要复用全局池 -
try-finally中确保shutdown()+awaitTermination()成对出现 - 若
awaitTermination()返回false，说明有任务卡住，此时应shutdownNow()并排查死循环、未响应的 I/O 或锁竞争
保护共享状态，避免误判竞态结果
普通变量（如 int count = 0）在多线程中自增不是原子操作，count++ 读-改-写三步可能被交叉执行，导致断言必然失败。
- 用
AtomicInteger、AtomicLong替代基本类型计数 - 共享集合优先选
ConcurrentHashMap、CopyOnWriteArrayList - 若需复杂逻辑同步，用
synchronized块或ReentrantLock，但测试中尽量简化临界区，聚焦验证行为而非锁本身
提升并发缺陷暴露概率
单次运行很难触发竞态条件。要让测试更“苛刻”：
- 用
@RepeatedTest(50)（JUnit 5）反复执行同一并发场景 - 加
@Timeout(value = 3, unit = TimeUnit.SECONDS)防止死锁或无限等待拖垮整个测试套件 - 对关键方法，可结合
JUnitPerf做轻量级性能+并发混合验证（如统计吞吐、检测异常率）
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
