基于AQS的ReentrantLock实现原理

Java中的大部分同步类（Lock、Semaphore、ReentrantLock等）都是基于AbstractQueuedSynchronizer（简称为AQS）实现的。

AQS是一种提供了原子式管理同步状态、阻塞和唤醒线程功能以及队列模型的简单框架。

ReentrantLock

ReentrantLock是可重入锁，指的是一个线程能够对一个临界资源重复加锁。ReentrantLock支持公平锁和非公平锁，并且ReentrantLock的底层就是由AQS来实现的。那么ReentrantLock是如何通过公平锁和非公平锁与AQS关联起来呢？ReentrantLock提供了一个Sync内部类，该类继承了AQS，ReentrantLock的公平锁和非公平锁就是通过继承Sync来跟AQS关联起来的。

我们着重从这两者的加锁过程来理解一下它们与AQS之间的关系。

可重入

AQS提供了一个同步状态State来控制整体可重入的情况。State是Volatile修饰的，用于保证一定的可见性和有序性。

cs复制代码AbstractQueuedSynchronizer


private volatile int state;

因此ReentrantLock也就具有了可重入的特性。

State这个字段主要的过程：

• 1、State初始化的时候为0，表示没有任何线程持有锁。
• 2、当有线程持有该锁时，值就会在原来的基础上+1，同一个线程多次获得锁是，就会多次+1，这里就是可重入的概念。
• 3、解锁也是对这个字段-1，一直到0，此线程对锁释放。

公平锁 VS 非公平锁

java复制代码static final class NonfairSync extends Sync {
  private static final long serialVersionUID = 7316153563782823691L;


  /**
   * Performs lock.  Try immediate barge, backing up to normal
   * acquire on failure.
   */
  final void lock() {
    if (compareAndSetState(0, 1))
      setExclusiveOwnerThread(Thread.currentThread());
    else
      acquire(1);
  }


  protected final boolean tryAcquire(int acquires) {
    return nonfairTryAcquire(acquires);
  }
}

上面代码的逻辑为：

• 1、若通过CAS设置变量State（同步状态）成功，也就是获取锁成功，则将当前线程设置为独占线程。
• 2、若通过CAS设置变量State（同步状态）失败，也就是获取锁失败，则进入Acquire方法进行后续处理。

第一步很好理解，但第二步获取锁失败后，后续的处理策略是怎么样的呢？有以下两种可能：

• (1) 将当前线程获锁结果设置为失败，获取锁流程结束。这种设计会极大降低系统的并发度，并不满足我们实际的需求。所以就需要下面这种流程，也就是AQS框架的处理流程。
• (2) 存在某种排队等候机制，线程继续等待，仍然保留获取锁的可能，获取锁流程仍在继续。

对于第二种情况，就有如下几种疑问：

• 既然说到了排队等候机制，那么就一定会有某种队列形成，这样的队列是什么数据结构呢？
• 处于排队等候机制中的线程，什么时候可以有机会获取锁呢？
• 如果处于排队等候机制中的线程一直无法获取锁，还是需要一直等待吗，还是有别的策略来解决这一问题？这些问题我们先记下来，后面慢慢讲解。

同样的，对于公平锁

java复制代码static final class FairSync extends Sync {
  private static final long serialVersionUID = -3000897897090466540L;


  final void lock() {
    acquire(1);
  }


  /**
   * Fair version of tryAcquire.  Don't grant access unless
   * recursive call or no waiters or is first.
   */
  protected final boolean tryAcquire(int acquires) {
    final Thread current = Thread.currentThread();
    int c = getState();
    if (c == 0) {
      if (!hasQueuedPredecessors() &&
        compareAndSetState(0, acquires)) {
        setExclusiveOwnerThread(current);
        return true;
      }
    }
    else if (current == getExclusiveOwnerThread()) {
      int nextc = c + acquires;
      if (nextc < 0)
        throw new Error("Maximum lock count exceeded");
      setState(nextc);
      return true;
    }
    return false;
  }
}

ReentrantLock默认使用非公平锁，也可以通过构造器来显示的指定使用公平锁。

通过上面的源代码对比，我们可以明显的看出公平锁与非公平锁的lock()方法唯一的区别就在于公平锁在获取同步状态时多了一个限制条件：hasQueuedPredecessors()。该方法主要做一件事情：主要是判断当前线程是否位于同步队列中的第一个。如果是则返回true，否则返回false。

综上，公平锁就是通过同步队列来实现多个线程按照申请锁的顺序来获取锁，从而实现公平的特性。非公平锁加锁时不考虑排队等待问题，直接尝试获取锁，所以存在后申请却先获得锁的情况。

到了这里，我看到了，公平锁和非公平锁的加锁流程，虽然流程上有一定的不同，但是都调用了Acquire方法，而Acquire方法是FairSync和UnfairSync的父类AQS中的核心方法。

对于上边提到的问题，都需要由acquire来解答，而Acquire方法是在类AbstractQueuedSynch