单元测试中不应使用 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 的 test 方法）结束后 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 级服务，非业务逻辑
垃圾回收、JIT 编译、RMI GC 等才是典型的守护线程。你在业务代码中写的“监控线程”“清理线程”，哪怕标记为 daemon=true，也不该在单元测试里靠它自动收尾——因为测试需要可观察、可断言、可重复的行为。把“是否守护”当成部署配置项（如 Spring Boot 的 @Scheduled 是否启用），而非测试逻辑的一部分。
不复杂但容易忽略
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
