源码
非公平锁加锁：
//该方法时子类实现
final void lock() {
//线程进入后，先尝试加锁
if (compareAndSetState(0, 1))
//加锁成功后，记录加锁成功的线程（以便可重入）
setExclusiveOwnerThread(Thread.currentThread());
else
//AQS的父类方法
acquire(1);
}
公平锁加锁：
//该方法由子类实现
final void lock() {
//AQS的父类方法
acquire(1);
}
独占锁解锁：
public final boolean release(int arg) {
//改变标志位，即status-1，若status==0，那么该方法返回true。
if (tryRelease(arg)) {
Node h = head;
//waitStatus!=0，即可以理解为=-1，即当前节点释放锁时，需要通知后续节点。
if (h != null && h.waitStatus != 0)
//释放节点的线程
unparkSuccessor(h);
return true;
}
return false;
}
解析
在源码中，可以得出结论：若使用非公平锁加锁，那么线程进入后，会立即尝试一次加锁，加锁失败后。公平锁和非公平锁执行相同的逻辑。
1. 为什么公平锁的效率低呢？
在独占锁解锁过程中，在tryRelease中修改标识位（status）。倘若status==0，此时一个线程进入。
- 非公平锁：该线程立即会获取锁；
- 公平锁：该线程会去等待队列
（sync queue）中排队并阻塞。而AQS会唤醒第一个排队的线程去获取锁，在这个过程中，锁的性能一直被浪费。
总接下：公平锁效率慢的原因：
- 当锁资源空闲时，即使有新线程进入，公平锁
大多数情况下需要借助操作系统唤醒第一个排队的节点线程，让他去抢占锁； - 寻找第一个排队的节点线程时，会采取
tail节点向前遍历。可能也会有些性能上的问题；
上面红字标出的是挖出了两个坑？为什么绝大多数情况下借助OS？为什么tail节点要从后往前遍历？
2. 公平锁的一定效率低？（大多数情况下借助OS）
但是公平锁的效率也不一定低，我们对一个代码块使用了锁。
- 若是线程交替执行，
sync queue是不会被创建，每个线程都是通过CAS来获取锁。性能是相同的。 - 若是线程并发执行，
sync queue此时才会被创建。线程尝试加锁时，会判断队列中是否有节点在排队。若是队列不存在，或队列中只有一个head节点，那么该线程会立即执行CAS尝试加锁。 - 若线程和队列中第一个排队的节点的线程相同，那么该线程也会立即尝试加锁。
也就是说，若是这几种情况，公平锁和非公平锁的效率相同。
3. tail节点往前遍历
这还得从加锁过程中说起
private Node enq(final Node node) {
for (;;) {
Node t = tail;
if (t == null) { // Must initialize
if (compareAndSetHead(new Node()))
tail = head;
} else {
//步骤1
node.prev = t;
//步骤2 原子性，tail指针只会指向一个node节点
if (compareAndSetTail(t, node)) {
//步骤3 原子性，旧tail ---> 新tail的过程。
t.next = node;
return t;
}
}
}
}
上述源码除了CAS外不是线程安全的。而他们又同时操纵了tail节点对象。可能就有并发安全问题。所以要借助于自旋+CAS来保证每一个节点都会尾插到链表中。
若是执行完步骤2但未执行步骤3。思考下这么个问题，是不是从head往后遍历，会最终丢失tail节点？
但是步骤1已经执行完毕，那么实际上tail节点若往前遍历，那么可以遍历到整个链表。
所以最终选择了从后往前遍历。
4. 为什么只有waitStatus!=0时，才会唤醒线程？
waitStatus不是节点自己设置的，而是后继节点设置的。这个标识位就好像一个闹钟，提醒节点释放锁时，你后面有人在排队。你需要唤醒后面等待的节点。
5. 为什么最终要唤醒waitStatus<=0的节点？
//waitStatus默认值为0
static final int CANCELLED = 1;
static final int SIGNAL = -1;
static final int CONDITION = -2;
static final int PROPAGATE = -3;
因为waitStatus==1的节点，是CANCELLED节点，即被取消的节点。
相关阅读
JAVA并发（1）—java对象布局
JAVA并发（2）—PV机制与monitor（管程）机制
JAVA并发（3）—线程运行时发生GC，会回收ThreadLocal弱引用的key吗？
JAVA并发（4）— ThreadLocal源码角度分析是否真正能造成内存溢出！
JAVA并发（5）— 多线程顺序的打印出A，B，C（线程间的协作）
JAVA并发（6）— AQS源码解析（独占锁-加锁过程）
JAVA并发（7）—AQS源码解析（独占锁-解锁过程）
JAVA并发（8）—AQS公平锁为什么会比非公平锁效率低（源码分析）
JAVA并发（9）— 共享锁的获取与释放
JAVA并发（10）—interrupt唤醒挂起线程
JAVA并发（11）—AQS源码Condition阻塞和唤醒
JAVA并发（12）— Lock实现生产者消费者
`
