守护线程不参与JVM优雅关闭，因其生命周期完全依附于非守护线程；一旦所有非守护线程结束，JVM立即强制终止守护线程，不执行finally、shutdown hook或任何清理逻辑，仅非守护线程和显式注册的shutdown hook（须为非守护）才被保障执行。

Java 中守护线程不参与 JVM 优雅关闭过程，也不拥有执行权。它不会被等待、不会被通知、也不会被赋予清理机会——JVM 退出时，守护线程直接终止，不执行任何后续逻辑。

这是由 JVM 的线程生命周期机制决定的：优雅关闭只针对非守护线程（用户线程）和注册的 Shutdown Hook，而守护线程被设计为“可随时丢弃”的后台服务者。

---

守护线程与 JVM 关闭的关系

• JVM 是否退出，只看是否还有活跃的非守护线程

  • 只要存在至少一个非守护线程在运行，JVM 就继续运行
  • 当最后一个非守护线程结束，JVM 立即启动关闭流程，此时所有守护线程被强制终止

• 守护线程无法注册 Shutdown Hook

  立即学习“Java免费学习笔记（深入）”；

  • Runtime.getRuntime().addShutdownHook() 要求传入的 Thread 必须是非守护线程
  • 若传入守护线程，会抛出 IllegalArgumentException（JDK 源码中明确校验 hook.isDaemon() == false）

• 守护线程中新建的子线程，自动继承守护属性

  

  Alibabacloud Sdk Client Initialization For Java

  在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。

  下载
  • 即使子线程里尝试 setDaemon(false)，也因已启动而失败（抛 IllegalThreadStateException）

---

JVM 优雅关闭真正依赖的执行主体

JVM 关闭流程中，有明确执行权和顺序保障的只有两类：

• 用户注册的 Shutdown Hook 线程（非守护线程）

  • 执行顺序按注册逆序（LIFO），可通过 order 参数控制优先级（如 DeleteOnExitHook 使用 order=2）
  • 这些钩子能安全执行资源释放、日志刷盘、连接关闭等操作

• JVM 内置的关键钩子（如 DeleteOnExitHook、ApplicationShutdownHooks）

  • 它们本身也是非守护线程，且被严格排序（例如 DeleteOnExitHook 设为高 order，确保在用户钩子之后执行）
  • 具备线程安全、幂等性、容错注册（如 registerShutdownInProgress = true）等设计保障

---

为什么不能依赖守护线程做清理？

• 守护线程可能在任意时刻被中断（无 interrupt() 通知，无 finally 块执行机会）
• 不保证 finally 块或 try-with-resources 正常执行
• 文件句柄、数据库连接、网络通道等资源大概率泄漏
• 示例风险代码：

  Thread daemon = new Thread(() -> {
      try (FileWriter w = new FileWriter("log.txt")) {
          w.write("done");
      } catch (IOException e) {
          e.printStackTrace();
      }
  });
  daemon.setDaemon(true);
  daemon.start();
  // main 结束 → JVM 退出 → FileWriter 构造函数中的流未 flush/close

---

正确做法：用 Shutdown Hook 替代守护线程清理

若需在 JVM 退出前执行清理，应：

• 创建普通线程（非守护）
• 在 run() 中编写清理逻辑
• 通过 Runtime.getRuntime().addShutdownHook() 注册
• 避免耗时操作（JVM 不会等待超时钩子）

Runtime.getRuntime().addShutdownHook(new Thread(() -> {
    System.out.println("正在关闭连接池...");
    dataSource.close(); // 安全释放资源
    System.out.println("关闭完成");
}));

这类钩子是 JVM 关闭阶段唯一被保障执行的用户代码入口。