JUC：LockSupport与线程中断

1 内容介绍

一个线程不应该由其他线程来强制中断或停止，而是应该山线程自己自行停止,自己来决定自己的命运。

在Java中没有办法立即停止一条线程，然而停止线程却显得尤为重要，如取消一个耗时操作。
因此，Java提供了一种用于停止线程的协商机制--中断，也即中断标识协商机制。

中断只是一种协作协商机制，Java没有给中断增加任何语法，中断的过程完全需要程序员自己实现。若要中断一个线程，你需要手动调用该线程的interrupt方法，该方法也仅仅是将线程对象的中断标识设成true; 接着你需要自己写代码不断地检测当前线程的标识位，如果为true，表示别的线程请求这条线程中断,此时究竟该做什么需要你自己写代码实现。

每个线程对象中都有一个中断标识位，用于表示线程是否被中断;该标识位为true表示中断，为false表示未中断;通过调用线程对象的interrupt方法将该线程的标识位设为true;可以在别的线程中调用，也可以在自己的线程中调用。

如何中断一个运行中的线程？

2 线程中断机制

// Thread类中
public void interrupt() // Just to set the interrupt flag 
public static boolean interrupted() // 1. 判断当前的线程是否被中断，2. 清除当前中断状态
public boolean isInterrupted() // 判断当前线程是否被中断

• volatile标识一个flag，协商中断
• AtomicBoolean, 类似于volatile，协商中断
• 通过Thread类自带的api，协商中断（底层为volatile）

调用一个线程的interrupt()方法时：

• 如果线程正常运行，仅仅是把中断标志位修改为true
• 如果线程处于被阻塞状态（WATING, TIME_WATING, BLOCKED)，线程会退出当前被阻塞状态，清除当前中断状态，并直接抛出InterrruptedException异常。

3 LockSupport是什么

用于创建锁和其他同步类的基本线程阻塞原语。

LockSupport的park()和unpark()分别是阻塞线程和解除线程阻塞

4.3.4 线程等待唤醒机制

3种让线程等待和唤醒的方法

• 使用Object的wait()和notify()
• 使用JUC种Condition的await()和signal()
• LockSupport的park()和unpark()

（1）Object的wait()和notify()

// thread1
Object objectLock = new Object();
new Thread(()->{
    synchronized(object){ // 需要结合synchronized来进行等待唤醒操作。没有synchronized代码块包裹，会报错
        System.out.println("线程一");
        try {
            object.wait(); // 等待唤醒，直到被唤醒才被唤醒。如果不被唤醒则一直处于等待状态
        } catch (InterruptedException e) {
            throw new RuntimeException(e);
        }
    }
}).start();

// thread2
new Thread(()->{
    synchronized(object){
        object.notify(); // 唤醒等待线程， 必须在锁块中
    }
}).start();

（2）JUC中Condition的await()和signal()

ReentrantLock lock = new ReentrantLock();
Condition condition = lock.newCondition();
// thread1
new Thread(()->{
    lock.lock();
    try {
        condition.await(); // 必须在锁块中，等待唤醒，直到被唤醒才开始运行。否则一直处于等待状态
    } catch (InterruptedException e) {
        throw new RuntimeException(e);
    }finally {
        lock.unlock();
    }
}).start();

//thread2
new Thread(()->{
    lock.lock();
    try{
        condition.signal(); // 必须在锁块中
    }finally {
        lock.unlock();
    }
}).start();

（3）LockSupport的park()和unpark()

LockSupport类使用了一种名为Permit（许可）的概念来做到阻塞和唤醒线程的功能，每个线程都有一个许可（permit）

于Semaphore不同的是，许可的累加上线是1.

• 阻塞park() / park(Object blocker): 阻塞当前线程 / 阻塞传入的具体线程

  public static void park(){
      UNSAFE.park(false,0L);  
  }
  public static void park() {
      U.park(false, 0L); //  | 0ms 没有通行证就一直等待
  }
  

  permit许可证默认没有不能放行，所以一开始调用park()方法，当前线程就会被阻塞，直到别的线程给当前线程发放permit, park方法才会被返回（唤醒）

• 唤醒unpark(Thread thread) ： 唤醒处于阻塞状态的指定线程

  public static void unpark(Thread thread) {
      if (thread != null)
          U.unpark(thread);
  }
  

  调用unpark(thread)方法后，就会将thread线程的许可证permit发放，会自动唤醒park的线程，即之前阻塞中的LockSupport.park()方法会立即返回。

Thread thread1 = new Thread(() -> {
    System.out.println("线程一启动");
    LockSupport.park();
    System.out.println("线程一被唤醒");
});
thread1.start();

try {
    TimeUnit.SECONDS.sleep(3);
} catch (InterruptedException e) {
    throw new RuntimeException(e);
}

new Thread(()->{
    System.out.println("线程二启动");
    LockSupport.unpark(thread1); // 发放permit，放行thread1.(唤醒thread1)
}).start();

• 无需锁块包裹
• 可以实现提前唤醒的操作
• park()和unpark()成对出现，单个线程重复调用unpark()不会累计permit，permit最多只能有一个！

为什么可以突破wait/notify原有的调用顺序？

unpark获取了一个permit凭证，调用park()时由于有permit会顺利进行，不会阻塞。

为什么唤醒两次后阻塞两次，最终还是阻塞？

因为permit凭证最多只能有一个，虽然有两次唤醒，但是只积累了一个permit，阻塞两次只有第一次有permit时能唤醒阻塞，第二次阻塞由于没有permit，无法唤醒。