java并发之ReentrantLock

ReentrantLock，可重入锁，支持一个线程对公有资源重复加锁。当然，ReentrantLock还支持公平性的获取锁和非公平性的获取锁。

注：何谓获取锁的公平性？
每一个线程在获取锁的时候可能都会排队等待，如果在等待时间上，先获取锁的线程的请求一定先被满足，那么这个锁就是公平的。反之，这个锁就是不公平的。公平的获取锁，也就是当前等待时间最长的线程先获取锁。

接下来就源码对ReentrantLock做详细的分析。

ReentrantLock源码分析

可重入锁同读写锁一样，也是一种自定义同步器。接下来先从构造函数开始，依次分析可重入锁的具体实现。

构造函数

构造函数

从源码可以看出：

• ReentrantLock提供两个构造方法，不带参数构造方法和带boolean型参数fair的构造方法；

• 默认不带参构造方法是非公平性的获取锁，带参数fair的构造方法根据fair的值判断到底是公平性的获取锁还是非公平性的获取锁，fair == true时，是公平性的获取锁，fair == false时，是非公平性的获取锁。

自定义同步器Sync

ReentrantLock通过自定义同步器来实现锁的获取与释放，如何实现自定义同步器在前文java并发编程之AbstractQueuedSynchronizer 中已经做了详细的分析，在这里就不再赘述，有不了解的小伙伴可以去读一读这篇文章。

Sync实现
对于JDK提供的两种锁来说，锁的竞争其实就是竞争同步器AQS的同步状态state，锁的释放也就是释放同步状态，接下来我们就具体看看相关的源码实现。

• Sync之非公平锁的获取

  
  
  

  Sync之非公平锁的获取
  
  

  从源码可以看出，锁的获取主要分这样几个步骤：

  1. 获取当前线程以及同步器状态state；

  2. 判断state == 0是否成立：

  • 成立，表示当前同步器不存在线程竞争同步状态，可以直接分配给当前线程，设置同步状态，并将持有同步状态的线程置为当前线程；

  • 否则，表示当前同步器存在线程竞争同步状态，跳转到步骤3。

  3. 判断同步状态线程 == 当前线程是否成立：

  • 成立，根据可重入的定义，当前线程可以获取同步状态，获取并设置同步状态；

  • 否则，线程不能获取同步状态，返回。

• Sync之锁的释放

  
  
  

  Sync之锁的释放
  
  

  锁的释放其实就是同步状态state的释放，从源码可以看出：

  1. 计算新的同步状态c；

  2. 如果c == 0，表明当前同步状态释放后无线程占有该同步状态，设置持有同步状态线程为null；

  3. 设置同步状态。

• Sync之其他重要方法
  当然，Sync也提供一些额外的方法便于使用者获取锁的持有者以及判断当前是否加锁等。

  
  
  

  Sync之其它重要方法

从Sync的具体实现可以看出，针对重进入：

1. 锁的再次获取：记录获取锁的线程，每次获取锁都需要去识别获取锁的线程是否为当前站有所的线程，如果是，可以再次成功获取，否则，不能获取；

2. 锁的最终释放：线程重复多次获取了锁，随后再多次释放锁，加锁其实是同步状态state进行自增，当然，state也就表示当前锁被相同线程获取的次数；锁在释放时，state会自减，当state等于0时表示当前线程获取的锁已经成功被释放。

公平锁的实现
公平性其实仅仅是针对锁的获取而言，如果一个锁是公平的，那个锁的获取的顺序就应该满足请求的时间顺序，换言之也就是FIFO。对于非公平锁的获取nonfairTryAcquire方法的具体实现，非公平锁其实只需要CAS设置同步状态成功，当前线程也就获取锁成功，但是公平锁的获取就不一样了。

公平锁的获取

从源码可以看出：
公平锁的获取多了一个判断（在源码中用绿色线标注出来的部分）hasQueuedPredecessors()方法，接下来来看看这个方法到底做了什么来保证了锁获取的FIFO。

• hasQueuedPredecessors实现

  
  
  

  hasQueuedPredecessors实现
  
  

  该方法是AbstractQueuedSynchronizer提供的一个方法，它可以判断当前等待队列是否有线程在等待，如果有返回true，反之返回false；

在公平锁的获取之前加入该判断是为了确定当前线程是否有前驱节点，如果有，表示有线程比当前线程更早的请求获取锁，需要等待前驱线程获取并释放时候才能获取锁。

公平锁与非公平锁的区别
之前做过一个测试，5个线程分别获取2次公平锁与非公平锁，打印获取锁的线程和正在等待的线程，测试结果如下：

公平锁与非公平锁的获取测试

从对比结果可以看出，非公平锁出现了一个线程连续获取锁的情况，那为什么会出现这个情况呢？回想一下非公平锁的获取，当一个线程请求获取锁的时候，只需要获取同步状态即可成功的获取锁，在这个前提下，刚释放锁的线程再次获取同步状态的几率会非常大，这就会使得其他线程只能在同步队列中等待，这样就可能会导致线程饥饿，但是，明显知道它会有这个缺点，为什么还要被设置成默认的呢？我们再来观察下上图的结果，可以发现，公平锁在测试中进行了10次切换，但是非公平锁只有5次切换，这可以说明非公平锁的开销会更小一点。我们再来测试一下系统上下文切换的次数和耗时（测试场景：10个线程，每个线程获取10w次锁）：

公平锁与非公平锁线程上下文切换次数及耗时

从对比结果可以看出，公平锁的总耗时和总切换次数远远超过非公平锁，公平锁以大量的线程切换来换取了锁获取的FIFO原则，而非公平锁虽然可能会导致线程饥饿，但是它的线程切换很少，在一定程度上保证了更大的吞吐量。