2.1 操作系统中线程的状态及切换

在现在的操作系统中，线程是被视为轻量级进程的，所以操作系统线程的状态其实和操作系统进程的状态是一致的。

操作系统线程主要有三个状态：

• 就绪状态（ready）：线程正在等待使用 CPU，经调度程序调用之后可进入 running 状态。
• 执行状态（running）：线程正在使用 CPU。
• 等待状态（waiting）：线程经过等待事件的调用或者正在等待其他资源（比如 I/O）。

2.2 Java 中线程的六种状态

Thread 类中有一个枚举 State，表示线程中的六种状态：

// Thread.State 源码
public enum State {
    NEW,
    RUNNABLE,
    BLOCKED,
    WAITING,
    TIMED_WAITING,
    TERMINATED;
}

状态名	说明
NEW	初始化状态，表示线程被创建了，但是还没有调用 start() 方法
RUNNABLE	运行状态，Java 线程将操作系统中的就绪和运行状态笼统的称为"运行中"
BLOCKED	阻塞状态，表示线程阻塞于锁
WAITING	等待状态，表示线程进入等待状态，进入该状态需要其他线程做出一些特定的动作（通知或中断）
TIME_WAITING	超时等待状态，进入该状态，线程在等待指定时间后自动返回（唤醒）
TERMINATED	终止状态，标识当前线程已经执行完毕

01、NEW（线程尚未启动）

处于 NEW 状态的线程此时尚未启动，也就是说还没有调用 Thread 实例的 start() 方法启动线程。

public static void main(String[] args) {
    Thread thread = new Thread();
    System.out.println(thread.getState()); // NEW
}

由此可见，new Thread() 只是创建了线程而并没有调用 start() 方法，此时的线程处于 NEW 状态。

关于 start() 的两个引申问题：

1. 反复调用同一个线程的 start() 方法是否可行？
2. 假如一个线程执行完毕（此时处于 TERMINATED 状态），再次调用这个线程的 start() 方法是否可行？

我们来扒一下 start() 方法的源码：

public synchronized void start() {
    // 如果 threadStatus 不等于 0
    if (threadStatus != 0)
        throw new IllegalThreadStateException();

    group.add(this);

    boolean started = false;
    try {
        start0();
        started = true;
    } finally {
        try {
            if (!started) {
                group.threadStartFailed(this);
            }
        } catch (Throwable ignore) {
            /* do nothing. If start0 threw a Throwable then
              it will be passed up the call stack */
        }
    }
}

在 start() 方法内部有一个 threadStatus 的变量。如果它不等于 0，就直接抛出异常。

如果 threadStatus 等于 0，接着会调用start0()方法。这个方法是 native 修饰的，里面并没有对 threadStatus 的处理。

执行下面代码：

public static void main(String[] args) {
   Thread thread = new Thread();
    System.out.println(thread.getState()); // NEW

    thread.start(); // 第一次调用
    thread.start(); // 第二次调用
}

程序运行结果：

我两次调用 start() 方法后，程序抛出了异常。使用 debug 方式追踪一下程序的运行过程：

第一次调用 start() 方法

第二次调用 start() 方法

可以看到，两次调用 start() 方法时 threadStatus 的值：

1. 第一次调用时，threadStatus = 0；
2. 第二次调用时，threadStatus != 0。

查看一下线程此时的状态源码：

// Thread.getState方法源码
public State getState() {
    // get current thread state
    return sun.misc.VM.toThreadState(threadStatus);
}

// sun.misc.VM.toThreadState方法源码
public static State toThreadState(int var0) {
    if ((var0 & 4) != 0) {
        return State.RUNNABLE;
    } else if ((var0 & 1024) != 0) {
        return State.BLOCKED;
    } else if ((var0 & 16) != 0) {
        return State.WAITING;
    } else if ((var0 & 32) != 0) {
        return State.TIMED_WAITING;
    } else if ((var0 & 2) != 0) {
        return State.TERMINATED;
    } else {
        return (var0 & 1) == 0 ? State.NEW : State.RUNNABLE;
    }
}

所以，结合源码我们可以得到两个引申问题的答案：两个答案都是不可行的。

在调用一次 start() 之后，threadStatus 的值会改变（threadStatus != 0），此时再次调用 start() 方法会抛出 IllegalThreadStateException 异常。比如：threadStatus = 2 表示当前线程状态是 TERMINATED。

02、RUNNABLE（运行中）

表示当前线程正在运行中。处于 RUNNABLE 状态的线程在 Java 虚拟机中运行，也有可能在等待 CPU 分配资源。

Thread 源码里对 RUNNABLE 状态的定义：

 /**
  * Thread state for a runnable thread.  A thread in the runnable
  * state is executing in the Java virtual machine but it may
  * be waiting for other resources from the operating system
  * such as processor.
  */

翻译过来是这样的：

可运行线程的线程状态：处于可运行状态的线程正在Java虚拟机中执行，但它可能正在等待来自操作系统的其他资源（如处理器）。

注意：Java 线程的 RUNNABLE 状态其实是包括了传统操作系统线程的 ready 和 running 两个状态。

03、BLOCKED（阻塞状态）

阻塞状态。处于 CLOCKED 状态的线程正等待锁的释放以进入同步区。

使用 BLOECKED 状态举一个生活中的小例子：

假如今天下班后我准备去食堂吃饭，在走向仅剩的一个有饭的窗口时发现，前面已经有个人在窗口面前了，此时我必须等前面的人从窗口离开才可以买饭。
假设我是线程 thread2，前面的那个人是线程 thread1。此时 thread1 占有了锁（仅剩的一个有饭的窗口），thread2 正在等待锁的释放，所以此时我这个线程 thread2 就处于 BOLCKED 状态。

04、WAITING（等待状态）

等待状态。处于等待状态的线程变成 RUNNABLE 状态需要其他线程唤醒。

调用以下三个方法会使线程进入等待状态：

1. Object.wait()：使当前线程处于等待状态直到另一个线程唤醒它。
2. Thread.join()：等待线程执行完毕，底层调用的是 Object 实例的 wait() 方法。
3. LockSupport.park()：除非获得调用许可，否则禁用当前线程进行线程调度。

执行 wait() 方法后，线程进入等待状态，进入等待状态的线程需要其他线程的通知（notify()、notifyAll()…等方法）唤醒才能够回到 RUNNABLE 状态。而超时等待状态相当于在等待状态的基础上增加了超时限制，也就是超时时间到达时将会返回到运行状态。

调用以下三个方法会解除线程等待状态：

1. Object.notify()：唤醒一个等待线程。
2. Object.notifyAll()：唤醒所有的等待线程。
3. LockSupport.unpark(Thread thread)：唤醒指定的等待线程。

05、TIMED_WAITING（超时等待状态）

超时等待状态。线程等待一个具体的时间，时间到后会被自动唤醒。

调用以下方法会使线程进入超时等待状态：

1. Thread.sleep(long millis)：使当前线程睡眠指定时间。
2. Object.wait(long timeout)：线程休眠指定时间，等待期间可以通过 notify()/notifyAll() 唤醒。
3. Thread.join(long millis)：等待当前线程最多执行 millis 毫秒，如果 millis 为0，则会一直执行。
4. LockSupport.parkNanos(long nanos)： 除非获得调用许可，否则禁用当前线程进行线程调度指定时间。
5. LockSupport.parkUntil(long deadline)：同上，也是禁止线程进行调度指定时间；

调用以下方法会解除线程超时等待状态：

1. Object.notify()：唤醒一个超时等待线程。
2. Object.notifyAll()：唤醒所有的超时等待线程。
3. LockSupport.unpark(Thread thread)：唤醒指定的超时等待线程。

06、TERMINATED（终止状态）

终止状态。此时线程已经执行完毕，进入这个状态有两个方式：

1. run() 方法执行完毕，线程正常退出；
2. 出现一个没有捕获的异常，终止了 run() 方法，最终导致意外终止。

2.3 Java 中线程的状态切换

先上一张图（Java 线程状态切换流程图）：

01、BLOCKED 与 WAITING 的区别，以及如何进入 RUNNABLE 状态

• 线程在进入 synchronized 同步代码块时，并没有获取到 monitor 同步锁，此时就处于同步阻塞状态（synchronized 同步代码块都是基于 monitor 锁实现的）。
• BLOCKED 阻塞状态是在等待获取其他线程释放 monitor 锁，从而进入 RUNNABLE 状态。

这里需要明确指出一点大部分所认为的关于 WAITING 状态的错误看法：

1. 我们知道，关于 wait() 和 notify()/notifyAll() 等方法，只能在 synchronized 同步代码块中才能调用，在外面调用则会抛出异常。
2. 也就是说，其他线程通过调用 notify()/notifyAll() 等方法来唤醒当前处于 WAITING 状态的线程，因为当前线程是在 synchronized 代码块中的，所以唤醒后就进入到了 BLOCKED 阻塞状态，等获取到 monitor 锁后才能进入 RUNNABLE 状态。
3. 如果处于 WAITING/TIMED_WAITING 状态的线程想直接进入到 RUNNABLE 状态，就需要其他 join 程序执行结束或被中断，或者执行 LockSupport.unpark() 方法，可以直接进入 RUNNABLE 状态。

看一下 JDK 文档中对 BLOCKED 状态的描述：

/**
 * Thread state for a thread blocked waiting for a monitor lock.
 * A thread in the blocked state is waiting for a monitor lock
 * to enter a synchronized block/method or
 * reenter a synchronized block/method after calling
 * {@link Object#wait() Object.wait}.
 */
BLOCKED,

当一个阻塞在 wait 的线程，被另一个线程 notify 后，重新进入 synchronized 区域，此时需要重新获取锁，如果失败了，就变成 BLOCKED 状态。

对于这个描述，我们来一张图：

也就是说，我们不可以认为：从 WAITING/TIMED_WAITING 状态被 notify 后是直接进入到 BLOCKED 状态的。而是先进入到 RUNNABLE 状态等待 CPU 时间片的分配，分配到了时间片时才有机会尝试获取锁。如果获取锁成功，会直接进入到 running 状态；如果获取锁失败，就从 RUNNABLE 状态进入到 BLOCKED 状态。

02、BLOCKED 与 RUNNABLE 状态的转换

我们知道：处于 BLOCKED 状态的线程是因为在等待锁的释放。假如有两个线程 a 和 b，a 线程提前获得了锁并且暂未释放锁，此时 b 就处于 BLOCKED 状态。

来看一个例子：

/**
 * @author qiaohaojie
 * @date 2023/7/1  18:39
 */
@Test
public void blockedTest() {
    Thread threadA = new Thread(new Runnable() {
        @Override
        public void run() {
            testMethod();
        }
    }, "a");

    Thread threadB = new Thread(new Runnable() {
        @Override
        public void run() {
            testMethod();
        }
    }, "b");

    threadA.start();
    threadB.start();
    System.out.println(threadA.getName() + "：" + threadA.getState()); // ？
    System.out.println(threadB.getName() + "：" + threadB.getState()); // ？
}


/**
 * 同步方法争夺锁
 */
private synchronized void testMethod() {
        try {
            Thread.sleep(2000);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }
}

运行之前，我们可能会觉得线程 a 会先调用同步方法，同步方法内又调用了 Thread.sleep() 方法，所以线程 a 必然会输出 TIMED_WAITING，而线程 b 因为等待线程 a 释放锁所以必然会输出 BLOCKED。

其实不是的，有两点需要注意的：

1. 在测试方法 blockedTest() 中还有一个 main 线程；
2. 启动线程后执行 run() 方法还需要消耗一定的时间。

测试方法的 main 线程只保证了 a，b 两个线程调用 start() 方法（转化为 RUNNABLE 状态），如果 CPU 执行效率高一点，估计还没等两个线程真正开始争夺锁，就已经打印了此时两个线程的状态了（RUNNABLE）了。

当然，如果 CPU 执行效率低一点，其中某个线程也是会打印出 BLOCKED 状态的（此时两个线程已经开始争夺锁了）。

如果我们想要打印出 BLOCKED 状态该怎么处理呢？BLOCKED 状态的产生需要两个线程争夺锁，可以让 a 线程休息一下，但是要注意 main 线程的休息时间，要保证在线程争夺锁的时间内，而不是等到前一个线程锁都释放了才去争夺，此时是得不到 BLOCKED 状态的。

改下代码：

threadA.start();
// 需要注意这里main线程休眠了1000毫秒，而testMethod()里休眠了2000毫秒
try {
    Thread.sleep(1000L);
} catch (InterruptedException e) {
    e.printStackTrace();
}
threadB.start();
System.out.println(threadA.getName() + "：" + threadA.getState()); // ？
System.out.println(threadB.getName() + "：" + threadB.getState()); // ？

这时两个线程的状态转换如下：

• a 线程的状态转换：RUNNABLE（threadA.start()） -> TIMED_WATING（Thread.sleep()）->RUNABLE（sleep() 时间到）-> BLOCKED(未抢到锁) -> TERMINATED
• b 的状态转换：RUNNABLE（threadB.start()) -> BLOCKED(未抢到锁) ->TERMINATED

其中，斜体字表示可能出现的状态，有很多中情况，大家可以多试一试。

03、WAITING 与 RUNNABLE 状态的转换

有三个方法可以使线程从 RUNNABLE 状态转为 WAITING 状态。

• Object.wait()

  1. 调用 wait() 方法前线程必须持有对象的锁，只能在 synchronized 代码块中使用。
  2. 线程调用 wait() 方法时，会释放当前的锁，直到有其他线程调用 notify()/notifyAll() 方法唤醒等待锁的线程。
  3. 其他线程调用 notify() 方法只会唤醒单个等待锁的线程，如果有多个线程都在等待这个锁的话，不一定会唤醒到之前调用 wait() 方法的线程。
  4. 调用 notifyAll() 方法唤醒所有等待锁的线程之后，也不一定会马上把时间片分给刚才放弃锁的那个线程，具体要看系统的调度。

• Thread.join()

  调用 join() 方法，会一直等待这个线程执行完毕（转换为 TERMINATED 状态）。

  再来改一下代码：

  threadA.start();
  try {
  	// 等待A线程执行完毕后才执行B线程
      threadA.join();
  } catch (InterruptedException e) {
      e.printStackTrace();
  }
  threadB.start();
  System.out.println(threadA.getName() + "：" + threadA.getState()); // a：TERMINATED
  System.out.println(threadB.getName() + "：" + threadB.getState()); // ？
  

  A 线程启动后立马调用了 join() 方法，所以 main 线程就会等到 A 线程执行完毕后才会去执行 B 线程，结果可想而知，A 线程打印的状态值固定是 TERMINATED。但是 B 线程的状态就未知了，可能是 RUNNABLE、TIMED_WAITING 等。

• LockSupport.park()

  1. LockSupport.park() 方法是 JUC 中 LockSupport 类中提供的一个用于线程挂起的方法，随时随地都可以调用。
  2. LockSupport 允许先调用 unpark(Thread t)，后调用 park()。如果 thread1 先调用 unpark(thread2)，然后线程 2 后调用 park()，线程 2 是不会阻塞的。
  3. 如果线程 1 先调用 notify()，然后线程 2 再调用 wait() 的话，线程 2 是会被阻塞的。

04、 TIMED_WAITING 与 RUNNABLE 状态的转换

TIMED_WAITING 与 WAITING 状态类似，只不过 TIMED_WAITING 状态等待的时间是指定的。

• Thread.sleep(long)

  使当前线程睡眠指定时间。需要注意的是，这里的 “睡眠” 只是暂时使线程停止执行，并不会释放锁，等待指定的时间后，线程会重新进入 RUNNABLE 状态。

• Object.wait(long)

  使线程进入 TIMED_WAITING 状态。这两个 wait() 方法都可以通过其他线程调用 notify() 或 notifyAll() 方法来唤醒。但是，有参方法 wait(long) 如果没有其他线程来唤醒它，经过指定时间 long 后会自动唤醒，用友去争夺锁的资格。

• Thread.join(long)

  使当前线程执行指定时间，并且使线程进入 TIMED_WAITING 状态。

  再来改下代码：

  threadA.start();
  try {
      threadA.join(1000);
  } catch (InterruptedException e) {
      e.printStackTrace();
  }
  threadB.start();
  System.out.println(threadA.getName() + "：" + threadA.getState()); // TIMED_WAITING
  System.out.println(threadB.getName() + "：" + threadB.getState()); // ？
  

  因为制定了具体 A 线程执行的时间，并且执行时间小于 A 线程的 sleep 时间（2000）的，所以 A 线程状态输出 TIMED-WAITING。B 线程状态仍然不固定，可能是 RUNNABLE 或 BLOCKED。

2.4 为什么 notify()、wait() 等函数定义在 Object 中，而不是 Thread 中？

Object 中的 wait()、notify() 方法和 synchronized 关键字一样，都是对对象的同步锁操作的。

wait() 方法会让当前线程等待，因为进入等待状态，所以会释放当前所持有的同步锁 monitor；如果不释放，其他线程就获取不到锁而永远无法运行，这是底层操作系统的规定！

我们都知道，处于等待状态的线程，可以通过 notify()、notifyAll() 等方法被唤醒，那么 notify() 方法是依据什么唤醒等待线程的呢？wait() 等待线程和 notify() 之间是通过什么关联起来的？

答案就是：对象的同步锁。

负责唤醒等待线程的那个线程，我们称其为唤醒线程，它只有在获取对象的同步锁（此处的同步锁和处于等待状态的线程的同步锁是同一个），并且调用 notify()/notifyAll() 方法后，才能唤醒等待线程。但是要注意，此时虽然等待线程被唤醒了，但是它还不能立即执行，因为唤醒线程还持有对象的同步锁，所以必须等唤醒线程释放了对象的同步锁之后，等待线程才能获取到对象的同步锁进而继续执行。

总之，notify()、notifyAll() 、wait() 等方法都依赖于同步锁，而同步锁是对象所持有的，并且每个对象有且仅有一个，这就是为什么 notify()、notifyAll() 和 wait() 等方法定义在 Object 类中，而不是 Thread 类中了。

2.5 线程中断

01、什么是线程中断？

在某些情况下，我们在线程启动后发现并不需要它继续执行下去时，需要中断线程。目前在 Java 里还没有安全直接的方法来停止线程，但是 Java 提供了线程中断机制来处理需要中断线程的情况。

线程中断机制是一种协作机制。需要注意，通过中断操作并不能直接终止一个线程，而是通知需要被中断的线程自行处理。

关于线程中断的几个方法：

• Thread.interrupt()：中断线程。这里的中断线程并不会立即停止线程，而是设置线程的中断状态为 true（默认是 false）；
• Thread.currentThread().isInterrupted()：测试当前线程是否被中断。线程的中断状态受这个方法的影响，意思是调用一次使线程中断状态设置为 true，连续调用两次会使得这个线程的中断状态重新转为 false；
• Thread.isInterrupted()：测试当前线程是否被中断。与上面方法不同的是，调用这个方法并不会影响线程的中断状态。

在线程中断机制里，当其他线程通知需要被中断的线程后，线程中断的状态被设置为 true，但是具体被要求中断的线程要怎么处理，完全由被中断线程自己而定，可以在合适的实际处理中断请求，也可以完全不处理继续执行下去。

02、线程中断的两个场景

线程是否被中断，是通过一个共享变量 interrupted 来实现线程之间的通信。但凡有让线程阻塞的机制，都会有 InterruptedException 抛出，这样我们才能去响应它，在 catch 里发出要继续执行的操作。

有两个场景，分别是线程中断和线程复位：

• 线程中断

  线程中断，字面意思很好理解，就是不让线程继续执行了。但是，并非是让线程立马终止，而是通过一个中断标志来判断线程是否要继续执行：

  /**
   * 线程中断
   *
   * @author qiaohaojie
   * @date 2023/6/26  22:48
   */
  public class InterruptedDemo01 implements Runnable {
  
      private int i = 0;
  
      @Override
      public void run() {
          // 中断标记，默认是false  相当于interrupted=false
          while (!Thread.currentThread().isInterrupted()) {
              System.out.println("i=" + i++);
          }
      }
  
      public static void main(String[] args) throws InterruptedException {
          Thread thread = new Thread(new InterruptedDemo01());
          thread.start();
          // 设置终止条件 相当于interrupted=true
          thread.interrupt();
      }
  }
  

  如果发出线程中断信号，就停止运行。其实质上就是设置一个共享变量的值 interrupt（默认是 false），通过 true 和 false 来判断线程是否继续运行：

  /**
   * 替换InterruptedDemo01
   *
   * @author qiaohaojie
   * @date 2023/6/27  23:04
   */
  public class InterruptedDemo03 implements Runnable {
  
      private static volatile boolean interrupt = false;
      private int i = 0;
  
      @Override
      public void run() {
          while (!interrupt) {
              System.out.println("i=" + i++);
          }
      }
  
      public static void main(String[] args) {
          Thread thread = new Thread(new InterruptedDemo03());
          thread.start();
          interrupt = true;
      }
  }
  

• 线程复位

  线程的复位，可以理解为：唤醒阻塞状态下的线程：

  /**
   * 线程复位
   *
   * @author qiaohaojie
   * @date 2023/6/26  23:26
   */
  public class InterruptedDemo02 implements Runnable {
  
      @Override
      public void run() {
          while (!Thread.currentThread().isInterrupted()) { // false
              try {
                  TimeUnit.SECONDS.sleep(200);
              } catch (InterruptedException e) { // 复位 false
                  e.printStackTrace();
                  // 再次中断，true结束  也可以不做处理
                  Thread.currentThread().interrupt();
              }
          }
          System.out.println("processer end");
      }
  
      public static void main(String[] args) throws InterruptedException {
          Thread thread = new Thread(new InterruptedDemo02());
          thread.start();
          // 给一点时间充分运行，确保可以进入while循环
          Thread.sleep(1000);
          // 有作用：响应阻塞的线程
          thread.interrupt(); // true
      }
  }
  

  其中，抛出的异常 InterruptedException 相当于线程的复位，捕获异常后可以继续处理，也可以不做处理。