为什么前面获取锁失败了, 这里还要再次尝试获取锁呢?
首先, 这里再次尝试获取锁是基于一定的条件的,即:当前节点的前驱节点就是HEAD节点，因为我们知道，head节点就是个虚拟节点，它不代表任何线程，或者代表了持有锁的线程，如果当前节点的前驱节点就是head节点，那就说明当前节点已经是排在整个等待队列最前面的了。
setHead(node); 方法
// 这个方法将head指向传进来的node,并且将node的thread和prev属性置为null private void setHead(Node node) { head = node; node.thread = null; node.prev = null; } 可以看出，这个方法的本质是丢弃原来的head，将head指向已经获得了锁的node。但是接着又将该node的thread属性置为null了，这某种意义上导致了这个新的head节点又成为了一个虚拟节点，它不代表任何线程。为什么要这样做呢，因为在tryAcquire调用成功后，exclusiveOwnerThread属性就已经记录了当前获取锁的线程了，此处没有必要再记录。这某种程度上就是将当前线程从等待队列里面拿出来了，是一个变相的出队操作。
shouldParkAfterFailedAcquire(Node pred, Node node)方法
如果为前驱节点的waitStatus值为 Node.SIGNAL 则直接返回 true
如果为前驱节点的waitStatus值为 Node.CANCELLED (ws > 0), 则跳过那些节点, 重新寻找正常等待中的前驱节点，然后排在它后面，返回false
其他情况, 将前驱节点的状态改为 Node.SIGNAL, 返回false
acquireQueued方法中的Finally代码
private void cancelAcquire(Node node) { // 将无效节点过滤 if (node == null) return; // 设置该节点不关联任何线程，也就是虚节点 node.thread = null; Node pred = node.prev; // 通过前驱节点，跳过取消状态的node while (pred.waitStatus > 0) node.prev = pred = pred.prev; // 获取过滤后的前驱节点的后继节点 Node predNext = pred.next; // 把当前node的状态设置为CANCELLED node.waitStatus = Node.CANCELLED; // 如果当前节点是尾节点，将从后往前的第一个非取消状态的节点设置为尾节点 // 更新失败的话，则进入else，如果更新成功，将tail的后继节点设置为null if (node == tail && compareAndSetTail(node, pred)) { compareAndSetNext(pred, predNext, null); } else { int ws; // 如果当前节点不是head的后继节点， // 1.判断当前节点前驱节点的是否为SIGNAL // 2.如果不是，则把前驱节点设置为SINGAL看是否成功 // 如果1和2中有一个为true，再判断当前节点的线程是否为null // 如果上述条件都满足，把当前节点的前驱节点的后继指针指向当前节点的后继节点 if (pred != head && ((ws = pred.waitStatus) == Node.SIGNAL || (ws <= 0 && compareAndSetWaitStatus(pred, ws, Node.SIGNAL))) && pred.thread != null) { Node next = node.next; if (next != null && next.waitStatus <= 0) compareAndSetNext(pred, predNext, next); } else { // 如果当前节点是head的后继节点，或者上述条件不满足，那就唤醒当前节点的后继节点 unparkSuccessor(node); } node.next = node; // help GC } } 4.3 非公平锁获取流程图非公平锁获取锁成功的流程图
非公平锁获取锁失败的流程图