2021-10-12

---

对于java中各类阻塞方法是否可以被打破，并且跳出阻塞的原理分析。

---

java内部有几个可以阻塞线程的方法，sleep方法，juc内部的，syn获取不到锁的，以及syn获取到锁，却调用wait方法进入等待队列的，下面就对这几种方法是否可以响应对应线程的打断方法来跳出阻塞。
1.对于Thread.sleep方法，底层（jvm级别）是会有判断打断状态的操作，如果为true，则说明被打断了，内置的死循环代码
for (;😉 {
//检查打断标记，如果打断标记为ture，则直接返回
if (os::is_interrupted(thread, true)) {
return OS_INTRPT;
}
会被返回，最外侧还包裹了一个InterruptedException错误，这样的话在java层面，就会从sleep(n)阻塞中出来并且抛出一个异常。所以sleep是可以响应打断的，并且抛出InterruptedException异常。
2.而对于juc内置的阻塞方法是unsafe.park方法，这个方法内部底层也是可以被打断的，只不过他不会抛出异常，所以对于ReentrantLock的lockInterruptibly（）模式和lock（）模式，一旦阻塞的线程被打断了。
就会唤醒一下被阻塞的线程，刚好lockInterruptibly方法从唤醒的那一刻会抛出异常
if (shouldParkAfterFailedAcquire(p, node) &&
parkAndCheckInterrupt())
throw new InterruptedException()；
这样就可以跳出内部的死循环了。另外只有parkAndCheckInterrupt（）方法返回值是true才会抛异常，这是因为返回值是true才代表被打断过，而不是true却走出了阻塞是因为锁已经被上一个线程释放了，
所以这个线程就被调用unpark方法唤醒了。
而lock方法并没有打断内部死循环的条件，于是下一次循环来临时，刚刚被打断的线程又会被阻塞住，所以lock方法在调用api层面是不会抛出异常的。
3.syn如果没有获取锁而被阻塞，其实就是和juc的lock方法一样，被打断之后也是唤醒一下线程，但还是在for(;;)中去获取锁，而没有抛出异常去跳出循环，这样一来，一次循环过后，没有获取锁，那么线程依旧会
被阻塞住，
4.调用wait方法的线程也会阻塞住，但是内部代码也是实现了和sleep一样的策略就是根据是否被打断过而抛出异常，这样的话wait方法java层面也是会抛出InterruptedException（）异常的。

最后，阻塞方法内部大部分都是一个死循环，里面无非是处理打断标记为的逻辑而已，当被打断之后还是在死循环里面，一旦有处理打断标记为或者抛出打断异常，就说明可以跳出循环了。