基础设施
在 AQS 类中，定义了一个 int 类型变量 state，用来表示是否持有锁，以及重入持有锁的次数
在 AQS 类中，定义了一个双向链表 Node 类，用来对竞争锁的线程进行排队
在 AQS 类中，定义了 head 和 tail 两个变量，分别指向链表的头节点和尾节点
通过 Unsafe 类来实现部分变量的 CAS 操作，通过 LockSupport 类来实现线程的阻塞和唤醒
ReentrantLock 包含两种实现，公平和非公平，从代码上区别很小，思想上类似乐观锁和悲观锁
加锁过程
ReentrantLock 的 lock 方法调用内部类 Sync 的 lock 方法，而 Sync 类的 lock 方法属于 abstract，所以最终是调用子类的 lock 方法，Sync 有两个子类，分别实现为公平锁和非公平锁，先看非公平锁
final void lock() { // CAS操作尝试获取锁 if (compareAndSetState(0, 1)) // 获取锁成功，记录获取锁的线程 setExclusiveOwnerThread(Thread.currentThread()); else // 获取锁失败 acquire(1);}
复制代码
AQS 中的 acquire 方法
public final void acquire(int arg) { if (!tryAcquire(arg) && acquireQueued(addWaiter(Node.EXCLUSIVE), arg)) selfInterrupt();}
复制代码
tryAcquire 方法是 AQS 专门设计由子类去实现的方法，所以还是看非公平锁子类的实现
protected final boolean tryAcquire(int acquires) { return nonfairTryAcquire(acquires);}
复制代码
nonfairTryAcquire 方法
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;}
复制代码
addWaiter 方法
tryAquire 执行结束，回到 AQS 的 aquire 方法，继续执行链表相关操作，先执行 addWaiter 方法
private Node addWaiter(Node mode) { Node node = new Node(Thread.currentThread(), mode); // Try the fast path of enq; backup to full enq on failure Node pred = tail; // 链表存在，直接尝试CAS+尾插入链表 if (pred != null) { node.prev = pred; if (compareAndSetTail(pred, node)) { pred.next = node; return node; } } enq(node); return node;}
复制代码
enq 方法
private Node enq(final Node node) { for (;;) { Node t = tail; if (t == null) { // Must initialize // 注意这里初始化链表生成了一个假的头节点，链表常用手段，哨兵节点 // 所以真正有意义的节点都存在头节点之后 if (compareAndSetHead(new Node())) tail = head; } else { // 注意这里是一个死循环，所以上面的假头节点生成之后，会把当前线程的node插在头结点后面 node.prev = t; if (compareAndSetTail(t, node)) { t.next = node; return t; } } }}
复制代码
acquireQueued 方法
addWaiter 方法结束，新链表节点已生成并且入队，接下来执行 acquireQueued 方法
final boolean acquireQueued(final Node node, int arg) { boolean failed = true; try { boolean interrupted = false; for (;;) { // 因为有假头结点存在，所以这里永远有前驱节点，p不会为null final Node p = node.predecessor(); // 如果当前节点的prev是head，说明它是第一个排队的，可以尝试获取锁 if (p == head && tryAcquire(arg)) { // 将当前节点的属性置空，变成新的假头节点，并释放旧头节点的next指针，失去引用，帮助gc setHead(node); p.next = null; // help GC failed = false; return interrupted; } // 根据前驱节点的waitStatus状态，判断需要park当前线程 // 获取锁的线程执行完毕之后，释放锁会unpark头节点的下一个线程，该线程会从这里开始继续执行 // 利用if + && + 抽象两个function，可以少写一层if嵌套，有点代码洁癖在的 if (shouldParkAfterFailedAcquire(p, node) && parkAndCheckInterrupt()) interrupted = true; } } finally { if (failed) cancelAcquire(node); }}
复制代码
shouldParkAfterFailedAcquire 方法，第一次看会摸不着头脑，其实就是对 condition 和 cancel 两种情况做了特殊处理，其他状态都会置为 SIGNAL 状态，SIGNAL 状态顾名思义就是 signal 方法，说明要执行唤醒线程的操作了
private static boolean shouldParkAfterFailedAcquire(Node pred, Node node) { // 在addWaiter方法可以看到，新创建的node waitStatus是未赋值的，所以默认为0 // 意味着新node第一次进入这个方法会返回false，也就是不park当前线程，再回到acquireQueued方法的 // 死循环里，再进入一次当前方法就会返回true，此时就满足park条件了 // 可以看出设计者是非常不希望线程进入阻塞状态的，前后进行了很多次CAS操作失败才会最终阻塞 int ws = pred.waitStatus; if (ws == Node.SIGNAL) /* * This node has already set status asking a release * to signal it, so it can safely park. */ return true; if (ws > 0) { /* * Predecessor was cancelled. Skip over predecessors and * indicate retry. */ do { node.prev = pred = pred.prev; } while (pred.waitStatus > 0); pred.next = node; } else { /* * waitStatus must be 0 or PROPAGATE. Indicate that we * need a signal, but don't park yet. Caller will need to * retry to make sure it cannot acquire before parking. */ compareAndSetWaitStatus(pred, ws, Node.SIGNAL); } return false;}
复制代码
至此，加锁流程结束，可以看到，加锁流程从对 state 变量的 CAS 操作，到新建 node 入队的 CAS 操作，到第一次入队后再次尝试 CAS 获取锁操作，最后到两次循环之后才改变 prev node 到 SIGNAL 状态最终进入 park 状态。整个流程通过多次 CAS 操作，延缓未获取锁的线程进入 Park 的时间，降低线程 park 的可能性。这个思路可以看出，ReentrantLock 非公平锁的设计是偏向乐观锁思想的，适合并发不高，同步代码块代码耗时不高的场景
对于公平锁来说，唯一的区别是 tryAquire 方法
protected final boolean tryAcquire(int acquires) { final Thread current = Thread.currentThread(); int c = getState(); if (c == 0) { // 第一次获取锁失败后，再次尝试获取锁时发现锁已经释放 // 公平锁为了保证公平，会检查AQS链表中是否存在已排队的线程 // 如果存在，公平锁不会直接尝试CAS获取锁，而是继续后续新建node去排队的流程 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;}
复制代码
释放锁过程
释放锁过程，公平锁和非公平锁时一致的，所以由 Sync 类自己实现
public final boolean release(int arg) { if (tryRelease(arg)) { // 这里就是通过假头节点指针，来进入链表，进行unpark操作 Node h = head; if (h != null && h.waitStatus != 0) unparkSuccessor(h); return true; } return false;}
复制代码
tryRelease 方法
protected final boolean tryRelease(int releases) { // 释放锁过程不存在竞争，所以不需要CAS操作，仅需检查重入的所有次数是否均已释放 int c = getState() - releases; if (Thread.currentThread() != getExclusiveOwnerThread()) throw new IllegalMonitorStateException(); boolean free = false; if (c == 0) { free = true; setExclusiveOwnerThread(null); } setState(c); return free;}
复制代码
unparkSuccessor 方法
private void unparkSuccessor(Node node) { /* * If status is negative (i.e., possibly needing signal) try * to clear in anticipation of signalling. It is OK if this * fails or if status is changed by waiting thread. */ int ws = node.waitStatus; if (ws < 0) compareAndSetWaitStatus(node, ws, 0);
/* * Thread to unpark is held in successor, which is normally * just the next node. But if cancelled or apparently null, * traverse backwards from tail to find the actual * non-cancelled successor. */ Node s = node.next; // 如上面英文注释所说，处理CANCEL状态的节点 if (s == null || s.waitStatus > 0) { s = null; for (Node t = tail; t != null && t != node; t = t.prev) if (t.waitStatus <= 0) s = t; } // unpark下一位选手，此时，这位选手会从acquireQueued方法里继续开始执行 if (s != null) LockSupport.unpark(s.thread); }
复制代码
评论