在单元测试中不建议使用 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 服务器），可以封装成
@TestInstance(Lifecycle.PER_CLASS)配合@BeforeAll/@AfterAll来管理。
真实场景中守护线程只用于 JVM 级服务，而非业务逻辑
真正的守护线程是为 JVM 级别的核心服务设计的——比如垃圾回收、JIT 编译、RMI GC 等。你在业务代码中编写的“监控线程”“清理线程”，即便给它打上 daemon=true 标签，也千万不要指望在单元测试中靠它自动收尾。测试需要的是可观察、可断言、可重复的行为。把“是否守护”当作部署配置项来处理（就像 Spring Boot 中控制 @Scheduled 是否启用一样），而不是嵌入到测试逻辑中。
说起来，这些细节并不复杂，只是容易被忽略。
