前言
- 上篇文章咱们基于两个案例理解了ReentrantLock(偏心锁)的加锁过程。接下来咱们持续基于雷同的案例来意识它的解锁过程。
两个案例
1.线程A独自加锁再解锁
2.线程A正在持有锁的过程中，线程t1来加锁，线程t1阻塞后，线程A解锁
一、案例1：线程A独自加锁再解锁
还是应用雷同的代码：
public class SimpleThreadLock { static ReentrantLock lock = new ReentrantLock(true); public static void main(String[] args) throws InterruptedException { Thread a = new Thread(() -> { try { lock.lock(); System.out.println("Get lock"); } catch (Exception e) { e.printStackTrace(); } finally { lock.unlock(); } }, "线程a"); a.start(); a.join(); System.out.println("end"); }}还记得线程A独自加锁时的流程么？或者说独自加锁后的程序会定位到哪里？没错，在执行完tryAcquire办法后，它返回的是true，那么进而阐明acquire办法前面的语句压根不会执行。
public final void acquire(int arg) { if (!tryAcquire(arg) && acquireQueued(addWaiter(Node.EXCLUSIVE), arg)) selfInterrupt();}这也间接阐明了在单个线程加锁时，只会操作aqs队列中的state变量，其中队列都不会产生。那么咱们来做一个猜想：是不是解锁时，只是独自的将aqs中的state变量cas成0呢？ 咱们带着这个疑难来看unlock办法的源码。
java.util.concurrent.locks.ReentrantLock#unlock源码：
public void unlock() { sync.release(1);}依据咱们的主题，偏心锁的解锁过程，所以咱们间接定位到
FairSync的release办法，然而它并没有对父类AbstractQueuedSynchronizer的release办法进行重写，那么此时调用的必定是父类的release办法，咱们间接粘贴源码(父类AbstractQueuedSynchronizer release办法源码)：public final boolean release(int arg) { // 尝试去开释锁，与tryLock一样，有可能会失败 // tryRelease具体源码剖析将在上面给出 // 咱们先接着往下看，看完tryRelase再回过头来看 // if内的逻辑 // ...... 上面的逻辑请先看完tryRelease来回过头来接着看 // 在上面的tryRelease办法中有说到，只有线程对 // 锁开释胜利了，这里返回的才是true，若 // 开释锁的次数 < 重入的次数，那么会返回false // 若解锁的线程和以后持有state的线程不是同一个线程 // 则抛出异样。 if (tryRelease(arg)) { // 进入了if, 则示意线程开释锁胜利 // 因为在本案例中，只有一个线程加锁 // 所以aqs队列都没有初始化，head必定为null // 因而不须要执行if内的逻辑，而后间接返回true即可 // 在本案例中，返回true也毫无意义，在最顶端的 // 办法调用链中并没有接管这个返回值，因而 // 本案例的解锁过程完结 Node h = head; if (h != null && h.waitStatus != 0) unparkSuccessor(h); return true; } return false;}java.util.concurrent.locks.ReentrantLock.Sync#tryRelease源码：
protected final boolean tryRelease(int releases) { // 在以后案例中，state的值为1, // 而传入的release为1(由上述的调用链可知) // 所以此时做完操作后，c的值就等于0了 int c = getState() - releases; // 这里做了一个校验，肯定要以后持有state的 // 线程能力做解决操作，否则抛异样 if (Thread.currentThread() != getExclusiveOwnerThread()) throw new IllegalMonitorStateException(); // 能执行到这一步，就阐明是以后持有 // state的线程执行的unlock办法， // 后续要做的操作就是： // 确认c是否等于0，如果等于0则示意锁开释 // 结束，接着就是设置state的拥有者为null // 且设置state变量为0, // 若c不等于0，则示意以后这个线程持有的锁 // 是一把重入锁，重入多少次就要unlock多少次 // ===> 只有以后线程解锁胜利后，才返回true // 若解锁的次数 < 重入的次数则返回false boolean free = false; if (c == 0) { free = true; setExclusiveOwnerThread(null); } setState(c); return free; }看完这部分源码后记得返回看上述的release源码。在release源码中的正文有说到，在此案例下，线程A的解锁过程就完结了。因而在ReentrantLock中，单线程的执行或者多线程交替执行，并不会产生aqs队列，就是对state变量的一个加、减操作。但需注意：ReentrantLock的重入个性以及解锁的校验，重入了多少次就要解锁多少次，以及只能由以后持有state的线程能力unlock，否则抛异样。
二、案例2：线程A正在持有锁的过程中，线程t1来加锁，线程线程A解锁
还是应用雷同上篇文章雷同的代码：
public class TwoThreadLock { static ReentrantLock lock = new ReentrantLock(true); public static void main(String[] args) throws InterruptedException { new Thread(() -> { try { lock.lock(); System.out.println("Thread a get lock"); TimeUnit.SECONDS.sleep(60); } catch (Exception e) { e.printStackTrace(); } finally { lock.unlock(); } }, "线程a").start(); Thread t1 = new Thread(() -> { try { lock.lock(); System.out.println("Thread t1 get lock"); } catch (Exception e) { e.printStackTrace(); } finally { lock.unlock(); } }, "线程t1"); t1.start(); t1.join(); System.out.println("end"); }}还记得线程t1加锁时是在哪里被阻塞的吗？没错，就是在java.util.concurrent.locks.AbstractQueuedSynchronizer#acquireQueued办法
final boolean acquireQueued(final Node node, int arg) { boolean failed = true; try { boolean interrupted = false; for (;;) { // 局部代码省略..... // 在上篇博客的案例中，咱们有说到 // 当线程t1在线程a持有锁的过程中 // 来竞争锁了，此时就会在这里被park // 也就是在这里被阻塞了。 if (shouldParkAfterFailedAcquire(p, node) && parkAndCheckInterrupt()) interrupted = true; } } finally { if (failed) cancelAcquire(node); }}依据源码中的正文可知，线程t1在指定地位被阻塞了。依照以后案例来说，当线程t1阻塞时，线程a调用了unlock办法进行理解锁，此时的解锁过程和案例一的差不多，区别就在于release中的if代码块，详见下述源码解释：
public final boolean release(int arg) { // 尝试去开释锁，与tryLock一样，有可能会失败 // tryRelease具体源码剖析将在上面给出 // 咱们先接着往下看，看完tryRelase再回过头来看 // if内的逻辑 // ...... 上面的逻辑请先看完tryRelease来回过头来接着看 // 在上面的tryRelease办法中有说到，只有线程对 // 锁开释胜利了，这里返回的才是true，若 // 开释锁的次数 < 重入的次数，那么会返回false // 若解锁的线程和以后持有state的线程不是同一个线程 // 则抛出异样。 if (tryRelease(arg)) { // 进入了if, 则示意线程开释锁胜利 // 在本案例中，因为aqs队列初始化了， // 所以head不为null，且它的waitStatus // 为0，于是会执行if外部的 // unparkSuccessor办法 // 看完上面对unparkSuccessor办法的源码解析 // 再回过头来持续往下看！！！！！ // ................... // 最终返回true， // 其实这个返回值在这个案例中也没作用, // 因为在调用链中并没有接管它的返回值 // 所以它线程a的解锁流程算是实现了。 Node h = head; if (h != null && h.waitStatus != 0) // 此时传入的为aqs队列中的head节点 unparkSuccessor(h); return true; } return false;}java.util.concurrent.locks.AbstractQueuedSynchronizer#unparkSuccessor源码解析
private void unparkSuccessor(Node node) { // 在以后案例中，传入的node为队列中的head节点 // 此时它的ws为0 int ws = node.waitStatus; if (ws < 0) compareAndSetWaitStatus(node, ws, 0); /** 拿到head节点的下一个节点， 因为它的下一个节点不为null且waitStatus的值为-1( 在以后案例下，它的下一个节点 是处于park状态，那么它的waitStatus必定是-1) 于是不进if外面的逻辑 */ Node s = node.next; if (s == null || s.waitStatus > 0) { s = null; for (Node t = tail; t != null && t != node; t = t.prev) if (t.waitStatus <= 0) s = t; } // 在以后案例下head节点的下一个节点不为null if (s != null) // 于是对s这个node中保护的线程做unpark操作 // 在本案例中，这个s节点外部保护的线程就是 // t1, 于是t1会被唤醒。 // 还记得线程t1是在哪里被阻塞的吗？咱们持续往下看 LockSupport.unpark(s.thread);}再次回到java.util.concurrent.locks.AbstractQueuedSynchronizer#acquireQueued办法
final boolean acquireQueued(final Node node, int arg) { boolean failed = true; try { boolean interrupted = false; for (;;) { // ----------看完上面的start局部再回头看 ------------ // 此时的node为t2线程对应的node // 此时获取它的上一个节点， // 它的上一个节点是head节点， // 于是走前面的&& 逻辑 // 前面的&& 逻辑就是持续去加锁 // 此时因为只有线程t2在，所以必定 // 会加锁胜利，最终返回true // 进而进入if的代码块中， // 在if代码块中次要做的时就是 // 批改head节点的援用，并回收 // 原来的head节点，最终获取锁 // 胜利 // ----------看完上面的start局部再回头看 ------------ final Node p = node.predecessor(); if (p == head && tryAcquire(arg)) { setHead(node); p.next = null; // help GC failed = false; return interrupted; } // ----------start局部------------ // start局部: 线程t1是在parkAndCheckInterrupt办法中被阻塞的， // ****************** // 先看上面的parkAndCheckInterrupt办法再回头持续往下看 // ****************** // 在parkAndCheckInterrupt办法中返回了true // 所以会持续自旋， // ----------start局部------------ if (shouldParkAfterFailedAcquire(p, node) && parkAndCheckInterrupt()) interrupted = true; } } finally { if (failed) cancelAcquire(node); }}java.util.concurrent.locks.AbstractQueuedSynchronizer#parkAndCheckInterrupt办法
private final boolean parkAndCheckInterrupt() { // 所以当线程a调用unlock办法时，线程t2 // 会从此处开始继续执行， LockSupport.park(this); // 会将以后线程标识为interrupt状态， // 并且返回true return Thread.interrupted();}通过上述的源码正文，应该对案例2的解锁过程也理解了。其实也蛮简略，就是上一个线程unlock，于是unpark head节点的后一个节点对应的线程。当然，这也只是针对于案例2的简略，外面还有很多细节没有提及到，因为是针对案例而言的嘛，咱们得以案例为核心进行总结。
三、总结
- 还是那句话，解锁过程也是基于两个简略的案例来总结的，其实ReentrantLock还有很多其余的情景，然而咱们把最根本的加锁、解锁过程的流程给弄清楚后，后续的各种情景咱们
照单全收！丝毫不慌 - ReentrantLock加锁流程波及到每个办法的具体步骤可查看在github中的总结：传送门
- I am a slow walker, but I never walk backwards.