基于 AbstractQueuedSynchronizer 的并发类实现（3）

look_w

非公平模式ReentrantLock实现原理看完了公平模式ReentrantLock，接着我们看一下非公平模式ReentrantLock是如何实现的。NonfairSync类，同样是继承自Sync类，实现为：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

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

结合nonfairTryAcquire方法一起讲解，nonfairTryAcquire方法的实现为：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

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; }

看到差别就在于非公平锁lock()的时候会先尝试通过CAS看看能不能把state从0变为1（即获取锁），如果可以的话，直接获取锁而不需要排队。举个实际例子就很好理解了：

• 线程1、线程2、线程3竞争锁，线程1竞争成功获取锁，线程2、线程3依次排队
• 线程1执行完毕，释放锁，state变为0，唤醒了第一个排队的线程2
• 此时线程4来尝试获取锁了，由于线程2被唤醒了，因此线程2与线程4竞争锁
• 线程4成功将state从0变为1，线程2竞争锁失败，继续park

看到整个过程中，后来的线程4反而比先来的线程2先获取锁，相当于是一种非公平的模式，
那为什么非公平锁效率会比公平锁效率高？上面第（3）步如果线程2和线程4不竞争锁就是答案。为什么这么说，后面的解释很重要，希望大家可以理解：

线程1是先将state设为0，再去唤醒线程2，这两个过程之间是有时间差的。
那么如果线程1将state设置为0的时候，线程4就通过CAS算法获取到了锁，且在线程1唤醒线程2之前就已经使用完毕锁，那么相当于线程2获取锁的时间并没有推迟，在线程1将state设置为0到线程1唤醒线程2的这段时间里，反而有线程4获取了锁执行了任务，这就增加了系统的吞吐量，相当于单位时间处理了更多的任务。

从这段解释我们也应该能看出来了，非公平锁比较适合加锁时间比较短的任务。这是因为加锁时间长，相当于线程2将state设为0并去唤醒线程2的这段时间，线程4无法完成释放锁，那么线程2被唤醒由于没法获取到锁，又被阻塞了，这种唤醒-阻塞的操作会引起线程的上下文切换，继而影响系统的性能。