JVM如何通知长运行线程停止？非thread.interrupt()的实现方式

嘿，这个问题问到点子上了！很多人对JVM线程终止的逻辑都有误解，刚好我琢磨过这块细节，给你掰扯清楚。

首先得明确场景：JVM不会没事干去停止正常运行的线程，只有当它自己要退出的时候，才会涉及到线程的终止。触发JVM关闭的情况主要有这几种：

• 最后一个非守护线程执行完毕（比如main线程结束了，其他都是守护线程）
• 调用了System.exit(int)方法
• 收到操作系统的终止信号（比如Ctrl+C触发的SIGINT，或者kill命令的SIGTERM）
• 虚拟机发生致命错误（比如OOM或者JNI崩溃）

先给你拍板：JVM真的不会主动给线程发interrupt信号，这点那个回答说得没错。那问题来了，它怎么让线程知道该停了？

答案是：JVM本身没有内置的“通知长运行线程停止”的机制！没错，就是这么直接。它不会遍历所有线程去喊“快停下”，也不会给线程发任何内置的终止信号。

那线程怎么知道要停止？全靠开发者自己实现退出逻辑：

• 最常见的方式是用一个volatile boolean标志位，让线程定期检查这个标志，一旦标志为true就主动退出循环/方法。比如：

  private volatile boolean shouldStop = false;
  
  @Override
  public void run() {
      while (!shouldStop) {
          // 执行你的长运行任务
          doLongRunningWork();
      }
      // 清理资源后优雅退出
      cleanupResources();
  }
  
  // 外部调用这个方法请求线程停止
  public void requestStop() {
      shouldStop = true;
  }
  

• 如果你用了关闭钩子（Shutdown Hook），可以在钩子线程里调用上面的requestStop()方法；要是线程卡在可中断的操作上（比如Thread.sleep()、Object.wait()），你也可以在钩子中手动调用thread.interrupt()——但注意，这是你自己的代码调用的interrupt，不是JVM自动做的。
• 有些框架会封装这类退出逻辑，但本质上还是开发者层面的实现，和JVM本身无关。

分两种情况看：

1. 正常关闭流程 #

当JVM进入正常关闭序列时：

• 首先，它会锁死线程创建的入口，不让新线程再诞生。
• 然后，启动所有你注册的关闭钩子线程——这些是你通过Runtime.getRuntime().addShutdownHook(Thread)注册的线程，它们会并发跑起来，帮你做资源清理（比如关闭数据库连接、保存缓存到磁盘）。
• 接下来，JVM会老老实实等所有非守护线程自己结束，包括那些关闭钩子线程。如果某个非守护线程死扛着不退出，JVM就会一直等下去（除非你手动调用Runtime.halt()强制终止）。
• 当所有非守护线程都走完了，JVM会直接终止所有守护线程——没有提前通知，没有清理时间，直接干掉，谁让守护线程本来就是用来服务非守护线程的，主子都没了，它们也没必要留着。

2. 强制关闭 #

如果调用了Runtime.halt(int)，或者操作系统直接给JVM来了个致命一击（比如kill -9），那JVM会立刻原地暴毙，所有线程瞬间终止，不会执行任何关闭钩子，也不会做任何清理操作，连句“再见”都不会说。

• JVM绝对不会主动调用thread.interrupt()来停止线程，所有的interrupt都是开发者代码触发的。
• JVM没有内置的“喊线程停”的机制，长运行线程要能优雅停止，全靠开发者自己写退出逻辑（比如标志位、手动调用interrupt）。
• JVM正常关闭时，只会等非守护线程自己走完，然后强制干掉守护线程；强制关闭时则直接一锅端所有线程。

内容的提问来源于stack exchange，提问作者Lubor