源码角度来分析ReentrantLock是怎么利用AQS来实现公平锁，和非公平锁

ReentrantLock

这篇文章是从JDK8的ReentrantLock源码角度来分析ReentrantLock是怎么利用AQS来实现公平锁，和非公平锁的。

所以前提需要理解AQS。

简单的翻译了一下，大概清楚JDK doc里ReentrantLock介绍

   /**
     * A reentrant mutual exclusion {@link Lock} with the same basic
     * behavior and semantics as the implicit monitor lock accessed using
     * {@code synchronized} methods and statements, but with extended
     * capabilities.

      ReentrantLock属于非共享锁，即独占锁，每次只能是一个线程取得锁资源，它与synchronized关键字具有相同的锁语义，但是ReentrantLock具有一些另外的拓展功能

     *
     * A {@code ReentrantLock} is owned by the thread last
     * successfully locking, but not yet unlocking it. A thread invoking
     * {@code lock} will return, successfully acquiring the lock, when
     * the lock is not owned by another thread. The method will return
     * immediately if the current thread already owns the lock. This can
     * be checked using methods {@link #isHeldByCurrentThread}, and {@link
     * #getHoldCount}.

      ReentrantLock锁只属于获得它的线程，直到unlock解锁。如果一个线程执行lock()，如果当前锁没有
      其他线程在占用，则会获取得锁，立即返回。
      如果该线程已经拥有当前锁，再执行lock()，也会再次获得锁，立即返回。
      当前线程是否持有当前锁，可以用锁的isHeldByCurrentThread（）来查看获得当前锁的线程。
     *
     * <p>The constructor for this class accepts an optional
     * <em>fairness</em> parameter.  When set {@code true}, under
     * contention, locks favor granting access to the longest-waiting
     * thread.  Otherwise this lock does not guarantee any particular
     * access order.  
     ReentrantLock的构造函数可以传入一个boolean类型的true，来表示构造一个公平的锁，此时锁倾向于最长
     等待时间的线程。
     如果默认。或者传入函数为false。则为非公平锁，此时不保证获取得到锁的线程顺序。
     Programs using fair locks accessed by many threads
     * may display lower overall throughput (i.e., are slower; often much
     * slower) than those using the default setting, but have smaller
     * variances in times to obtain locks and guarantee lack of
     * starvation. 
     使用公平锁的吞吐率其实在某些情况会比使用非公平锁低，但是可以解决饥饿现象
     Note however, that fairness of locks does not guarantee
     * fairness of thread scheduling. Thus, one of many threads using a
     * fair lock may obtain it multiple times in succession while other
     * active threads are not progressing and not currently holding the
     * lock.
     * Also note that the untimed {@link #tryLock()} method does not
     * honor the fairness setting. It will succeed if the lock
     * is available even if other threads are waiting.

      值得注意的是，tryLock()属于非阻塞方法，成功则返回true,失败则返回false,
      这个方法无所谓的公平和非公平之分，即使是设置的是公平锁，任何线程调用这个方法，都会尝试获得锁资源，
      即使等待队列中有其他线程正在等待该锁资源
     *
     * <p>It is recommended practice to <em>always</em> immediately
     * follow a call to {@code lock} with a {@code try} block, most
     * typically in a before/after construction such as:
     *
     *  <pre> {@code
     * class X {
     *   private final ReentrantLock lock = new ReentrantLock();
     *   // ...
     *
     *   public void m() {
     *     lock.lock();  // block until condition holds
     *     try {
     *       // ... method body
     *     } finally {
     *       lock.unlock()
     *     }
     *   }
     * }}</pre>
     *
     * <p>In addition to implementing the {@link Lock} interface, this
     * class defines a number of {@code public} and {@code protected}
     * methods for inspecting the state of the lock.  Some of these
     * methods are only useful for instrumentation and monitoring.
     *
     * <p>Serialization of this class behaves in the same way as built-in
     * locks: a deserialized lock is in the unlocked state, regardless of
     * its state when serialized.
     *
     * <p>This lock supports a maximum of 2147483647 recursive locks by
     * the same thread. Attempts to exceed this limit result in
     * {@link Error} throws from locking methods.

        同一线程最大可重入锁的次数是 2的31次方减1，就是2147483647
     *
     * @since 1.5
     * @author Doug Lea
     */

IDEA里面的UML图显示，ReentranLock里面组合了Sync内部类，而Sync是继承了AQS。

其次，NonfairSync,fairSync是集成自Sync的两个内部类，分别对应非公平与公平的AQS。

再仔细看，NonfairSync,fairSync只是重写了Sync的lock()方法和重写了AQS的tryAcquire()

首先是，构造函数

  public ReentrantLock(boolean fair) {
        sync = fair ? new FairSync() : new NonfairSync();
    }

再来看看内部继承AQS的同步器Sync，Sync作为ReentrantLock的内部类。

abstract static class Sync extends AbstractQueuedSynchronizer {
        private static final long serialVersionUID = -5179523762034025860L;

        /**
         * Performs {@link Lock#lock}. The main reason for subclassing
         * is to allow fast path for nonfair version.
         */
        abstract void lock();       //  NonfairSync，fairSync 要继承此Sync要实现的

        /**
         * Performs non-fair tryLock.  tryAcquire is implemented in
         * subclasses, but both need nonfair try for trylock method.

           注意这里，因为Lock接口的语义里，tryLock()是不分公平与非公平的，（实际语义其实等同于非公平的）
           所以初始构造ReentrantLock时候，无论是new的fairSync还是notfairSync，都应该可以执行tryLock()，

           因此tryLock（）用到的Sync(AQS)的nonfairTryAcquire()，应该在NonfairSync,fairSync父类中实现，就是此类Sync，这样才可以达到共用的效果。

         */
        final boolean nonfairTryAcquire(int acquires) {
            final Thread current = Thread.currentThread();
            int c = getState();
            if (c == 0) {
                if (compareAndSetState(0, acquires)) {      //CAS安全地更新state
                    setExclusiveOwnerThread(current);
                    return true;
                }
            }
            else if (current == getExclusiveOwnerThread()) {        //检查是否是重入
                int nextc = c + acquires;
                if (nextc < 0) // overflow
                    throw new Error("Maximum lock count exceeded");
                setState(nextc);        //此时是重入，所以这里可以不用CAS来改变state
                return true;
            }
            return false;
        }

       //此tryRelease为NonfairSync，fairSync共用，因为释放无所谓公平不公平

        protected final boolean tryRelease(int releases) {
            int c = getState() - releases;
            if (Thread.currentThread() != getExclusiveOwnerThread())
                throw new IllegalMonitorStateException();
            boolean free = false;
            if (c == 0) {           //state==0  才解除线程持有锁
                free = true;
                setExclusiveOwnerThread(null);
            }
            setState(c);
            return free;
        }

        protected final boolean isHeldExclusively() {
            // While we must in general read state before owner,
            // we don't need to do so to check if current thread is owner
            return getExclusiveOwnerThread() == Thread.currentThread();
        }

        final ConditionObject newCondition() {
            return new ConditionObject();
        }

        // Methods relayed from outer class

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

        final int getHoldCount() {
            return isHeldExclusively() ? getState() : 0;
        }

        final boolean isLocked() {
            return getState() != 0;
        }

        /**
         * Reconstitutes the instance from a stream (that is, deserializes it).
         */
        private void readObject(java.io.ObjectInputStream s)
            throws java.io.IOException, ClassNotFoundException {
            s.defaultReadObject();
            setState(0); // reset to unlocked state
        }
    }

再来看看 NonfairSync ，也就是默认的非公平模式

 /**
     * Sync object for non-fair locks
     */
    static final class NonfairSync extends Sync {
        private static final long serialVersionUID = 7316153563782823691L;

        /**
         * Performs lock.  Try immediate barge, backing up to normal
         * acquire on failure.
         */
        @Override    //重写父类Sync的抽象方法Lock(),其实公平和非公平，区别在这，非公平lock（）的时候，都会先尝试获取锁资源，失败了，再进入acquire()流程。


      //而公平锁却直接进入acquire（）流程，需要检验等待队列中是否有其他线程在等待，若无，才尝试获取锁

        final void lock() {
            if (compareAndSetState(0, 1))
                setExclusiveOwnerThread(Thread.currentThread());
            else
                acquire(1);
        }


      //直接调用的是Sync定义的nonfairTryAcquire（）
        protected final boolean tryAcquire(int acquires) {
            return nonfairTryAcquire(acquires);
        }
    }

再来看FairSync

   /**
     * Sync object for fair locks
     */
    static final class FairSync extends Sync {
        private static final long serialVersionUID = -3000897897090466540L;


      //这里不同于非公平，这里直接进入acquire()
        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;
        }
    }

所以说，非公平锁，lock的时候，会无视正在等待锁资源的队列里面是否有成员，而直接尝试一次获取，若不成功，则还是会进入AQS的CLH等待队列，然后阻塞，顺序等待唤醒，获取。

公平锁，lock的时候，则不能无视正在等待锁资源的队列里面的成员。

最后，看下ReentrantLock的提供给我们使用的接口函数，是怎样调用fairSync，nonfairSync的

public void lock() {
    sync.lock();
}

分派给NonfairSync的lock()

   final void lock() {
        if (compareAndSetState(0, 1))
            setExclusiveOwnerThread(Thread.currentThread());
        else
            acquire(1);
    }

分派给fairSync的lock()

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

而tryLock(),直接是用的sync内部类定义的nonfairTryAcquire（），这也是为什么nonfairTryAcquire()定义在Sync，而不是NonfairSync（）的原因。

  public boolean tryLock() {
        return sync.nonfairTryAcquire(1);
    }

总结，Doug Lea,非常巧妙的利用AQS的模板方法，简洁而清晰地实现了具有公平和非公平的模式的ReentrantLock,值得我们去学习。