并发系列五：基于两种案例来认识ReentrantLock源码解锁过程(公平锁)

前言

• 上篇文章咱们基于两个案例了解了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.