守护线程不自动将守护状态传递给子线程，子线程默认为用户线程；必须显式调用setDaemon(true)才能设为守护线程，否则JVM会因残留用户线程而无法退出。
守护线程的生命周期不会自动传递到它创建的子线程中——Java 中没有“守护线程继承”机制。子线程默认是用户线程（非守护），无论其是否由守护线程启动。
守护状态不自动继承
当一个守护线程调用 new Thread().start() 创建新线程时，该新线程的 isDaemon() 值为 false（即用户线程），除非显式调用 setDaemon(true)。JVM 只根据线程自身的 daemon 属性决定是否等待它结束，与创建者无关。
- 主线程（用户线程）→ 启动守护线程 A → A 启动线程 B：B 默认仍是用户线程
- 若希望 B 也是守护线程，必须在
start()前设置：t.setDaemon(true); - 一旦线程已启动，再调用
setDaemon()会抛出IllegalThreadStateException
多级嵌套中的实际影响
若未显式设置，深层嵌套的子线程可能成为“意外的用户线程”，导致 JVM 无法正常退出——即使所有原始守护线程已结束，只要任一用户线程仍在运行（哪怕只是 sleep 或 wait），JVM 就会继续存活。
- 典型陷阱：守护线程启动一个定时任务线程，但忘记设为 daemon，结果程序挂起
- 可通过
Thread.getAllStackTraces().keySet()检查当前所有活跃线程及其 daemon 状态 - 建议对所有明确用于后台支撑、不应阻止 JVM 退出的线程，统一显式设为守护线程
正确传递守护意图的实践方式
没有自动传递，但可通过封装或工厂模式确保一致性。例如定义一个守护线程安全的启动工具：
立即学习“Java免费学习笔记（深入）”；
- 封装方法：
static void startDaemonThread(Runnable r) { new Thread(r).apply { isDaemon = true }.start() }（Kotlin 风格示意） - Java 中可写工具类：
DaemonThreadFactory实现ThreadFactory，返回的线程默认 daemon - 使用
Executors.newCachedThreadPool(new DaemonThreadFactory())管理线程池
注意线程组与上下文无关
线程组（ThreadGroup）本身不控制守护属性，也不影响 JVM 的退出判断。即使把多个线程放入同一组，只要其中有一个用户线程活着，JVM 就不会终止。
-
ThreadGroup主要用于批量中断或统计，不是生命周期管理机制 - 守护线程创建的线程，默认归属当前线程所在线程组，但 daemon 属性独立设置
- 不要依赖线程组来“统一设为守护”——这是常见误解
守护线程的语义只作用于自身，不辐射子线程。理解这一点，才能避免因隐式用户线程导致的进程滞留问题。
