junit默认不等待非守护线程结束即退出，导致继承thread启动的子线程被强制中断；应使用countdownlatch或join()主动同步，或改用runnable+executorservice提升可测性与复用性。
JUnit 默认不会等待非守护线程结束就退出测试，而继承 Thread 类创建的线程默认是非守护线程。当测试方法中直接 new MyThread().start() 后立即返回，JUnit 主线程执行完就终止 JVM，子线程被强制中断——这并不是“无法并发执行”，而是**根本没机会执行完**。
问题根源：非守护线程 + JUnit 生命周期短
JUnit 的测试方法运行在一个独立的、受控的线程中。该线程结束后，框架会主动关闭测试上下文，不等待你手动启动的非守护线程。即使你用了 extends Thread，只要没显式同步等待，线程就会被丢弃。
- 继承
Thread类本身不阻碍并发，但容易忽略线程生命周期管理 -
start()启动的是新线程，run()直接调用只是普通方法，不并发 - JVM 只有在所有非守护线程都结束时才退出；但 JUnit 不依赖 JVM 自然退出，它自己调用
System.exit()或直接返回
推荐解法：用 CountDownLatch 主动同步
这是最稳定、可读性强、适合多线程测试场景的方式。无需修改被测代码逻辑，仅在测试方法内添加协调机制。
- 声明
CountDownLatch latch = new CountDownLatch(n)，n 是预期启动的子线程数 - 每个子线程任务执行完毕后调用
latch.countDown() - 测试方法末尾调用
latch.await()，阻塞直到计数归零 - 务必在
finally或 try-with-resources 中关闭线程池（如使用了）
替代方案：join() 与线程池封装
若只启动少量线程，可用 thread.join() 简单等待：
- 适用于单个或固定几个
Thread子类实例 - 多个线程需逐个
join()，顺序阻塞，不如CountDownLatch灵活 - 更优实践是避免继承
Thread，改用Runnable + ExecutorService，便于复用和控制
长期建议：放弃继承 Thread，转向 Runnable + 线程池
继承 Thread 在测试中暴露的问题，本质是设计耦合过重：
- Java 单继承限制扩展能力
- 每次
new MyThread()都新建线程对象，不利于资源复用 - 线程池（
ExecutorService）天然支持Runnable，也更容易配合CountDownLatch或CompletableFuture - JUnit 5 原生支持并行测试，但前提是测试逻辑本身线程安全、无共享状态污染
不复杂但容易忽略：关键不在“怎么启线程”，而在“怎么等线程”。把等待逻辑写进测试方法，比纠结继承还是实现接口更能解决实际问题。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
