JAVA并发（8）—AQS公平锁为什么会比非公平锁效率低（源码分析）

源码

非公平锁加锁：

//该方法时子类实现
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节点，即被取消的节点。