AbstractQueuedSynchronizer（九）——ReentrantLock公平和非公平锁

更详细权威的内容参见ReentrantLock(重入锁)以及公平性

1.简介

这里提到一个锁获取的公平性问题，如果在绝对时间上，先对锁进行获取的请求一定被先满足，
那么这个锁是公平的，反之，是不公平的，也就是说等待时间最长的线程最有机会获取锁，也可以说锁的获取是有序的。
ReentrantLock这个锁提供了一个构造函数，能够控制这个锁是否是公平的。
而锁的名字也是说明了这个锁具备了重复进入的可能，也就是说能够让当前线程多次的进行对锁的获取操作，
这样的最大次数限制是Integer.MAX_VALUE，约21亿次左右。
事实上公平的锁机制往往没有非公平的效率高，因为公平的获取锁没有考虑到操作系统对线程的调度因素，
这样造成JVM对于等待中的线程调度次序和操作系统对线程的调度之间的不匹配。 对于锁的快速且重复的获取过程中，
连续获取的概率是非常高的，而公平锁会压制这种情况，虽然公平性得以保障，但是响应比却下降了(不停的park和unpark对线程调度带来的影响)，
但是并不是任何场景都是以TPS(吞吐量)作为唯一指标的，因为公平锁能够减少“饥饿”发生的概率，等待越久的请求越是能够得到优先满足。
<p/>

2.比较

{@link java.util.concurrent.locks.ReentrantLock.FairSync}和
{@link java.util.concurrent.locks.ReentrantLock.NonfairSync}，
区别在于{@link java.util.concurrent.locks.Lock#lock()}的实现上，
可以说是对新来的节点(线程)的对待态度上。

3.FairSync

FairSync的lock要从{@link java.util.concurrent.locks.AbstractQueuedSynchronizer#acquire(int)}
开始，{@link java.util.concurrent.locks.ReentrantLock.FairSync#tryAcquire(int)}中
如果状态为0(可以获取资源)，还要先看
{@link java.util.concurrent.locks.ReentrantLock.FairSync#hasQueuedPredecessors()}是否为true，
true代表前面没有人排在该节点（Node）前面，也即是说当前线程在CLH队列的队首，这时tryAcquire失败，入队列。
语义更明显的话用：getFirstQueuedThread() != Thread.currentThread() && hasQueuedThreads()

4.NonfairSync

后者从{@link java.util.concurrent.locks.AbstractQueuedSynchronizer#compareAndSetState(int, int)}
开始，如果失败，从{@link java.util.concurrent.locks.ReentrantLock.NonfairSync#tryAcquire(int)}开始，
还是先{@link java.util.concurrent.locks.AbstractQueuedSynchronizer#compareAndSetState(int, int)}，

可以看出来NonfairSync采用当前线程优先的策略。这里用源码里对它的称呼——fast path。fast path在同步器代码中多次出现，比如addWaiter和getFirstQueuedThread操作，后面有一章说这个。

5.总结比较

ReentrantLock(重入锁)以及公平性一文中写了个测试用例，测试公平锁和非公平锁产生的不同效果。

对非公平锁来说，有fast path，fast path体现在上来直接compareAndSetState(0, 1)，失败之后tryAcquire(nonfairTryAcquire)中也是先compareAndSetState(0, acquires)，这体现了 当前线程优先的策略。

/**
         * 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);
        }

/**
         * Performs non-fair tryLock.  tryAcquire is
         * implemented in subclasses, but both need nonfair
         * try for trylock method.
         */
        final boolean nonfairTryAcquire(int acquires) {
            final Thread current = Thread.currentThread();
            int c = getState();
            if (c == 0) {
                if (compareAndSetState(0, acquires)) {
                    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);
                return true;
            }
            return false;
        }

对公平锁来说，首先没有直接compareAndSetState(0, 1)，tryAcquire中也是用hasQueuedPredecessors判断队列中是否有节点，所以体现了 队列中节点优先的策略。

测试用例的结果中很明显，对于非公平锁，当前线程连续获得锁的概率很高，如果获取不到才轮到队列中的节点获取锁。

对于公平锁，总是先让队列中的节点获得锁。
6.获得锁的顺序比较

对于非公平锁，如果当前线程没有获取到锁，那么队列中的节点获得锁，获得顺序是有序的，前驱节点是头节点的节点——老二节点先获得锁。

对于公平锁，当前线程无法获取到锁，直接入队列，而且在队尾。队列中的节点获得锁，获得顺序是有序的，前驱节点是头节点的节点——老二节点先获得锁。

所以如果非公平锁当前节点没有获取到锁而轮到了队列中元素获取到锁，那么获取的顺序是和公平锁一样的，都是越靠近队首的节点越先获取到锁( 等待时间越长的节点越先获取到锁)。