这篇 ReentrantLock 看不懂，加我我给你发红包（三）-阿里云开发者社区

unlock 解锁流程

unlock 和 lock 是一对情侣，它们分不开彼此，在调用 lock 后必须通过 unlock 进行解锁。如果当前线程持有锁，在调用 unlock 后，count 计数将减少。如果保持计数为0就会进行解锁。如果当前线程没有持有锁，在调用 unlock 会抛出 IllegalMonitorStateException 异常。下面是它的源码

微信图片_20220412190321.jpg

在有了上面阅读源码的经历后，相信你会很快明白这段代码的意思，锁的释放不会区分公平锁还是非公平锁，主要的判断逻辑就是 tryRelease 方法，getState 方法会取得同步锁的重入次数，如果是获取了偏向锁，那么可能会多次获取，state 的值会大于 1，这时候 c 的值 > 0 ，返回 false，解锁失败。如果 state = 1，那么 c = 0，再判断当前线程是否是独占锁的线程，释放独占锁，返回 true，当 head 指向的头结点不为 null，并且该节点的状态值不为0的话才会执行 unparkSuccessor 方法，再进行锁的获取。

微信图片_20220412190326.jpg

ReentrantLock 其他方法

isHeldByCurrentThread & getHoldCount

在多线程同时访问时，ReentrantLock 由最后一次成功锁定的线程拥有，当这把锁没有被其他线程拥有时，线程调用 lock() 方法会立刻返回并成功获取锁。如果当前线程已经拥有锁，这个方法会立刻返回。可以通过 isHeldByCurrentThread 和 getHoldCount 来进行检查。

首先来看 isHeldByCurrentThread 方法

public boolean isHeldByCurrentThread() {
  return sync.isHeldExclusively();
}

根据方法名可以略知一二，是否被当前线程持有，它用来询问锁是否被其他线程拥有，这个方法和 Thread.holdsLock(Object) 方法内置的监视器锁相同，而 Thread.holdsLock(Object) 是 Thread 类的静态方法，是一个 native 类，它表示的意思是如果当前线程在某个对象上持有 monitor lock(监视器锁) 就会返回 true。这个类没有实际作用，仅仅用来测试和调试所用。例如

private ReentrantLock lock = new ReentrantLock();

public void lock(){
assert lock.isHeldByCurrentThread();
}

这个方法也可以确保重入锁能够表现出不可重入的行为

private ReentrantLock lock = new ReentrantLock();
public void lock(){
  assert !lock.isHeldByCurrentThread();
  lock.lock();
  try {
    // 执行业务代码
  }finally {
    lock.unlock();
  }
}

如果当前线程持有锁则 lock.isHeldByCurrentThread() 返回 true，否则返回 false。

我们在了解它的用法后，看一下它内部是怎样实现的，它内部只是调用了一下 sync.isHeldExclusively()，sync 是 ReentrantLock 的一个静态内部类，基于 AQS 实现，而 AQS 它是一种抽象队列同步器，是许多并发实现类的基础，例如 ReentrantLock/Semaphore/CountDownLatch。sync.isHeldExclusively() 方法如下

protected final boolean isHeldExclusively() {
  return getExclusiveOwnerThread() == Thread.currentThread();
}

此方法会在拥有锁之前先去读一下状态，如果当前线程是锁的拥有者，则不需要检查。

getHoldCount()方法和isHeldByCurrentThread 都是用来检查线程是否持有锁的方法，不同之处在于 getHoldCount() 用来查询当前线程持有锁的数量，对于每个未通过解锁操作匹配的锁定操作，线程都会保持锁定状态，这个方法也通常用于调试和测试，例如

private ReentrantLock lock = new ReentrantLock();
public void lock(){
  assert lock.getHoldCount() == 0;
  lock.lock();
  try {
    // 执行业务代码
  }finally {
    lock.unlock();
  }
}

这个方法会返回当前线程持有锁的次数，如果当前线程没有持有锁，则返回0。

newCondition 创建 ConditionObject 对象

ReentrantLock 可以通过 newCondition 方法创建 ConditionObject 对象，而 ConditionObject 实现了 Condition 接口，关于 Condition 的用法我们后面再讲。

isLocked 判断是否锁定

查询是否有任意线程已经获取锁，这个方法用来监视系统状态，而不是用来同步控制，很简单，直接判断 state 是否等于0。

isFair 判断是否是公平锁的实例

这个方法也比较简单，直接使用 instanceof 判断是不是 FairSync 内部类的实例

public final boolean isFair() {
  return sync instanceof FairSync;
}

getOwner 判断锁拥有者

判断同步状态是否为0，如果是0，则没有线程拥有锁，如果不是0，直接返回获取锁的线程。

final Thread getOwner() {
  return getState() == 0 ? null : getExclusiveOwnerThread();
}

hasQueuedThreads 是否有等待线程

判断是否有线程正在等待获取锁，如果头节点与尾节点不相等，说明有等待获取锁的线程。

public final boolean hasQueuedThreads() {
  return head != tail;
}

isQueued 判断线程是否排队

判断给定的线程是否正在排队，如果正在排队，返回 true。这个方法会遍历队列，如果找到匹配的线程，返回true

public final boolean isQueued(Thread thread) {
  if (thread == null)
    throw new NullPointerException();
  for (Node p = tail; p != null; p = p.prev)
    if (p.thread == thread)
      return true;
  return false;
}

getQueueLength 获取队列长度

此方法会返回一个队列长度的估计值，该值只是一个估计值，因为在此方法遍历内部数据结构时，线程数可能会动态变化。此方法设计用于监视系统状态，而不用于同步控制。

public final int getQueueLength() {
  int n = 0;
  for (Node p = tail; p != null; p = p.prev) {
    if (p.thread != null)
      ++n;
  }
  return n;
}

getQueuedThreads 获取排队线程

返回一个包含可能正在等待获取此锁的线程的集合。因为实际的线程集在构造此结果时可能会动态更改，所以返回的集合只是一个大概的列表集合。返回的集合的元素没有特定的顺序。

public final Collection<Thread> getQueuedThreads() {
  ArrayList<Thread> list = new ArrayList<Thread>();
  for (Node p = tail; p != null; p = p.prev) {
    Thread t = p.thread;
    if (t != null)
      list.add(t);
  }
  return list;
}

回答上面那个问题

那么你看完源码分析后，你能总结出 synchronized 和 lock 锁的实现 ReentrantLock 有什么异同吗？

Synchronzied 和 Lock 的主要区别如下：

存在层面：Syncronized 是Java 中的一个关键字，存在于 JVM 层面，Lock 是 Java 中的一个接口
锁的释放条件：1. 获取锁的线程执行完同步代码后，自动释放；2. 线程发生异常时，JVM会让线程释放锁；Lock 必须在 finally 关键字中释放锁，不然容易造成线程死锁
锁的获取: 在 Syncronized 中，假设线程 A 获得锁，B 线程等待。如果 A 发生阻塞，那么 B 会一直等待。在 Lock 中，会分情况而定，Lock 中有尝试获取锁的方法，如果尝试获取到锁，则不用一直等待
锁的状态：Synchronized 无法判断锁的状态，Lock 则可以判断
锁的类型：Synchronized 是可重入，不可中断，非公平锁；Lock 锁则是可重入，可判断，可公平锁
锁的性能：Synchronized 适用于少量同步的情况下，性能开销比较大。Lock 锁适用于大量同步阶段：
Lock 锁可以提高多个线程进行读的效率(使用 readWriteLock)
在竞争不是很激烈的情况下，Synchronized的性能要优于ReetrantLock，但是在资源竞争很激烈的情况下，Synchronized的性能会下降几十倍，但是ReetrantLock的性能能维持常态；
ReetrantLock 提供了多样化的同步，比如有时间限制的同步，可以被Interrupt的同步（synchronized的同步是不能Interrupt的）等

还有什么要说的吗

面试官可能还会问你 ReentrantLock 的加锁流程是怎样的，其实如果你能把源码给他讲出来的话，一定是高分。如果你记不住源码流程的话可以记住下面这个简化版的加锁流程

如果 lock 加锁设置成功，设置当前线程为独占锁的线程；
如果 lock 加锁设置失败，还会再尝试获取一次锁数量，
如果锁数量为0，再基于 CAS 尝试将 state（锁数量）从0设置为1一次，如果设置成功，设置当前线程为独占锁的线程；
如果锁数量不为0或者上边的尝试又失败了，查看当前线程是不是已经是独占锁的线程了，如果是，则将当前的锁数量+1；如果不是，则将该线程封装在一个Node内，并加入到等待队列中去。等待被其前一个线程节点唤醒。