公平锁 & 非公平锁
来到多线程的第十二篇，前十一篇请点文末底部的上、下一篇标签，这篇说说什么是公平锁 & 非公平锁？开篇之前，先聊聊它们的定义以及优缺点。
「公平锁」：多个线程按顺序排队获取锁，每个线程获取机会均等，但永远只有队列首位线程能获取到锁。
- 优点：每个线程等待一段时间后，都有执行的机会，不至于出现某个线程饿死在队列中。
- 缺点：是队列里面除了第一个线程，其他的线程都会阻塞，cpu 唤醒阻塞线程的开销会很大。
「非公平锁」：多个线程（不管是不是队列首位）去获取锁时会尝试直接获取锁，能获取到就执行任务，否则乖乖排队。
- 优点：获取锁更加灵活、吞吐量大、减少 CPU 唤醒线程的开销。
- 缺点：会出现某些线程永远获取不到锁，饿死在队列中，最终由 JVM 回收。
说了这么一堆，大家也可能看得不是很明白。狗哥就举个在大学跟室友一起排队买早饭的场景。是这样的，帅得一批的狗哥（也就是我啦），跟室友小钊（渣男）、小宝以及小民去买早饭。狗哥以及室友们都看做是一个线程。
「首先是公平锁」
某天狗哥起的最晚，到了饭堂。室友们都已经在排队买早饭了，作为良好市民的狗哥自然也是乖乖过去排队。这样大家都准守秩序，先到先得，很公平。
「然后是非公平锁」
还是狗哥起的最晚，到了食堂刚好小宝买完去上徐国保老师的课了。小钊这比还在思考今晚帮哪个妹子修电脑。狗哥不讲武德，趁机插了上去队头，见到是我插队，后面的小钊、小民即使不爽也不敢说啥，只能看着我买早餐。这就是非公平锁插队成功的例子。
但是，偶尔也有不成功的时候。比如小钊这比思考完要帮妹子阿毛修电脑，这时我想插上去被他发现使出一记闪电五连鞭把我给赶走了，狗哥也是欺软怕硬，只能乖乖去后面排队。这就是非公平锁插队失败的例子。
看完了这个例子是不是对非公平锁 & 公平锁这对 CP 的理解清晰了很多？刚看例子，不讲代码的行为无耻至极。下面随狗哥来读读源码。
源码分析
「如何使用？」
ReentrantLock lock = new ReentrantLock();
上面的代码熟悉么？其实，大家平时应该有使用过 ReentrantLock 的话就已经使用过非公平锁（ReentrantLock 默认）了。源码如下所示：
想要使用公平锁，创建锁的时候直接给个 true 即可。
ReentrantLock lock = new ReentrantLock(true);
「具体是怎么实现的？」
源码可以看到 ReentrantLock 内部有一个 Sync 内部类。他继承了 AbstractQueuedSynchronizer （也就是我们常说的 AQS），在操作锁的时候大多都是通过 Sync 实现的。
public class ReentrantLock implements Lock, java.io.Serializable { private static final long serialVersionUID = 7373984872572414699 L; /** Synchronizer providing all implementation mechanics */ private final Sync sync;
abstract static class Sync extends AbstractQueuedSynchronizer { ... }
下图得知，Sync 他又有两个子类，分别是 NonfairSync（非公平锁） & FairSync（公平锁），见名知义。
「非公平锁加锁实现」
从 nonfairTryAcquire 方法内部的 compareAndSetState 方法可以看到，非公平锁获取锁主要是通过 CAS 方式，修改 state 状态为 1，并且通过 setExclusiveOwnerThread (current) 把当前持有锁的线程改为自己。
static final class NonfairSync extends Sync { private static final long serialVersionUID = 7316153563782823691 L; final void lock() { if (compareAndSetState(0, 1)) setExclusiveOwnerThread(Thread.currentThread()); else acquire(1); } protected final boolean tryAcquire(int acquires) { return nonfairTryAcquire(acquires); } } 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; }
从上面我们知道 AbstractQueuedSynchronizer (AQS) 是 ReentrantLock 加解锁的核心，这样说可能有些笼统，还是刚刚的场景，狗哥给你们画几个图理解下。
1、首先狗哥因为长得帅，线程狗哥一进来就 CAS 判断 state == 0 有戏，把自己设置为加锁线程，成功获取到锁并买到早饭了。
2、这时小钊这逼过来想插队，但一判断 state 发现是 1，有人已经持有锁了。于是只能灰溜溜的滚回去排队了。
3、狗哥买完早饭，把 state 设置为 0 并释放锁，唤醒小钊。
4、就在唤醒期间（小钊还没醒的时刻）烫了个原谅绿藻头的小宝不讲武德插队，先行 CAS 判断 state == 0，可以设置自己为加锁线程。这时小钊可算醒了，CAS 判断 state，发现是 1，这尼玛。狗子不是说到我了吗？怎么又被人占用了，于是又灰溜溜的去排队。
以上就是非公平锁的加锁过程，上面提到非公平锁有部分线程可能会饿死，看完大家也可能理解了。小钊就是那个饿死的线程。。。
「公平锁加锁实现」
公平锁跟非公平锁加锁的逻辑差不多，唯一就是公平加锁的 if 判断中多了 hasQueuedPredecessors 是否队首的判断。
static final class FairSync extends Sync { private static final long serialVersionUID = -3000897897090466540 L; final void lock() { acquire(1); } protected final boolean tryAcquire(int acquires) { final Thread current = Thread.currentThread(); int c = getState(); if (c == 0) { // 多了 hasQueuedPredecessors 是否队首判断 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; } }
这点从以下源码可以看出，就算看不懂。注释也写得很清楚。
