单元测试中不应使用 setDaemon(true)，因其易致测试不可靠、JVM提前退出或资源泄漏；必须在 start() 前调用，否则抛 IllegalThreadStateException；应显式控制线程启停，用 join()、interrupt() 或 ExecutorService 管理生命周期。
在单元测试里直接给线程设置 setDaemon(true)？这事儿听起来省事，但往往是个坑——测试变得不可靠，JVM可能提前退出，资源泄漏的风险也会随之而来。
必须在测试线程启动前设置，否则会抛出异常
setDaemon() 有个硬性要求：必须在 Thread.start() 之前调用，否则系统会毫不客气地抛出 IllegalThreadStateException。这个限制意味着，如果你在测试中动态创建线程，还想事后补设守护属性（比如在 @BeforeEach 或者某个断言之后才去设置），那基本就是白费功夫。但问题的关键不在于这个前置校验——真正的核心是：单元测试压根儿就不该去依赖守护线程的生命周期语义。
- 测试线程的启停应该由你显式控制，而不是指望“主线程一结束就自动终止”这种模糊行为。
- 像
Thread.sleep()、CountDownLatch、CompletableFuture这些同步机制，哪个不比守护属性更靠谱？ - 如果线程里跑的是异步任务——比如日志刷盘、心跳上报——那就在
tearDown()方法里主动interrupt()或者调用关闭钩子，给它们一个体面的收尾。
避免在测试中模拟守护行为
有些开发者会动小心思，想着用 setDaemon(true) 让测试“跑得更快”——比如这样写：
Thread worker = new Thread(() -> {
while (!Thread.interrupted()) {
doWork();
Thread.sleep(100);
}
});
worker.setDaemon(true); // ❌ 错误：测试可能在 worker 还没真正开始就结束了
worker.start();
但这种方式隐患很大：主线程（也就是JUnit的测试方法）一旦结束，JVM可能立刻退出，worker还没来得及执行任何逻辑就夭折了，自然也无法验证它的行为。正确的做法是让 worker 能够优雅关闭，并在测试中明确等待它完成：
AtomicBoolean running = new AtomicBoolean(true);
Thread worker = new Thread(() -> {
while (running.get()) {
doWork();
try { Thread.sleep(100); } catch (InterruptedException e) { return; }
}
});
worker.start();
// 执行业务操作...
running.set(false);
worker.join(500); // 显式等待最多500ms
测试框架本身已管理线程生命周期
JUnit 5 和 TestNG 的设计思路是每个测试方法独立运行，不会跨测试复用线程。如果你手动创建了一个线程，却没有显式 join() 或 interrupt()，它很可能会残留到下一个测试方法里，导致状态污染、端口被占等问题。解决办法也很直接：
- 在
@AfterEach里清理所有手动启动的线程。 - 优先考虑用
ExecutorService，测试结束时调用shutdownNow()集中收尾。 - 对于那些需要长期存活的后台服务（比如嵌入式HTTP server），就封装成
@TestInstance(Lifecycle.PER_CLASS)配合@BeforeAll/@AfterAll来管理。
真实场景中守护线程只用于 JVM 级服务，非业务逻辑
真正的守护线程，是给 JVM 级别的核心服务用的——比如垃圾回收、JIT 编译、RMI GC 这些。你在业务代码里写的什么“监控线程”“清理线程”，哪怕给它打上 daemon=true 的标签，也千万别指望在单元测试里靠它自动收尾。测试需要的是可观察、可断言、可重复的行为。把“是否守护”当成部署配置项来处理（就像 Spring Boot 里控制 @Scheduled 是否启用一样），而不是嵌到测试逻辑里。
说起来，这些细节并不复杂，只是容易被忽略。
