基于Java 8进行源码分析
1.ReentrantLock
1.1. lock()
// 非公平锁
final void lock() {
if (compareAndSetState(0, 1))
setExclusiveOwnerThread(Thread.currentThread());
else
acquire(1);
}
// 公平锁
final void lock() {
acquire(1);
}
1.2. acquire(int)
这个方法是一个综合操作，目的是为了让线程获取到锁。大致逻辑：
1.尝试让当前线程获取锁，如果成功直接返回，如果失败就执行下一步。
2.将没有获取到锁的线程封装为节点存储在阻塞队列中，新来的都呆在队列的后面。
3.如果当前线程位于head.next的位置，尝试获取锁，获取到就直接返回，如果获取不到就和队列中其他位置的线程一样进入阻塞状态。
4.当阻塞的线程被唤醒时(例如unlock()被调用)，然后再次重复上一步。(unlock()只会让一个线程退出阻塞状态，不会导致惊群)其中还有一些对中断逻辑的处理
*一般情况下，如果线程进入阻塞状态前，中断标志就已经为true，那么中断的逻辑在进入阻塞状态后就会被触发(因为只有进入Safepoint，线程才能感知到中断标志的变化)。
*那么在lock()方法的调用过程中，如果对队列中没能获取到获取到锁的线程进行中断的话，在它进入阻塞状态后，AQS会感知到这个操作并暂时清除中断标志，在目标线程成功获取到锁后，AQS会恢复中断标志为true，方便用户自己处理中断的逻辑。
*AQS暂时清除中断标志的原因是为了能让AQS内的自选逻辑继续执行，这是lock()的执行逻辑；如果使用的是lockInterruptibly()的话，在这个暂时清除中断标志的逻辑中，会直接抛出中断的异常。
public final void acquire(int arg) {
if (!tryAcquire(arg) &&
acquireQueued(addWaiter(Node.EXCLUSIVE), arg)) // addWaiter里，设置的默认waitStatus为null
selfInterrupt();
}
1.2.1. tryAcquire(int)
tryAcquire(int)方法的逻辑比较简单，主要行为是尝试一次获取锁，公平锁和非公平锁的区别在于：
公平锁在获取锁之前会看看有没有线程比它等待时间久；非公平锁则是直接尝试获取。
// 非公平锁的实现
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)
throw new Error("Maximum lock count exceeded");
setState(nextc);
return true;
}
return false;
}
// 公平锁的实现
protected final boolean tryAcquire(int acquires) {
final Thread current = Thread.currentThread();
int c = getState();
if (c == 0) {
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;
}
1.2.2. addWaiter(Node.EXCLUSIVE)
这个方法的目的是：对于没/不能插队的lock操作，将它对应的线程添加到AQS的阻塞队列中，等待合适的执行时机。
其中一共有两个行为: （
阻塞队列是一个双向链表）
1.初始阻塞队列
这里会创建一个既是head又是tail的空内容节点
2.向阻塞队列尾部链接新节点
// AbstractQueuedSynchronizer#acquire(int) 中的代码片段
acquireQueued(addWaiter(Node.EXCLUSIVE), arg)
// AbstractQueuedSynchronizer
private Node addWaiter(Node mode) {
Node node = new Node(Thread.currentThread(), mode); // 新建一个节点，当前发起lock操作的线程作为新节点
// Try the fast path of enq; backup to full enq on failure
Node pred = tail;
// 如果尾部节点不为null，把新建的节点链接到队列当前尾部节点后面。
if (pred != null) {
node.prev = pred;
// 尝试完成双向链接行为。
// 通过CAS操作保证并发时的结果正确，如果CAS操作失败会进入下面的enq(node)方法。
// 代表节点由于并发问题，没能成功添加到队列中。
if (compareAndSetTail(pred, node)) {
pred.next = node;
return node;
}
}
// 通过自旋，把当前节点添加到阻塞队列的尾部
enq(node);
return node;
}
// AbstractQueuedSynchronizer
private Node enq(final Node node) {
for (;;) {
Node t = tail; // tail是被volatile修饰的
if (t == null) { // Must initialize
// 初始化队列，把一个空内容的Node作为队列的head和tail
if (compareAndSetHead(new Node()))
tail = head;
} else {
// 再次尝试将当前新建的节点链接到队列当前尾部节点后面。
node.prev = t;
if (compareAndSetTail(t, node)) {
t.next = node;
return t; // 这里返回的是当前节点的前一个节点
}
}
}
}
1.2.3. acquireQueued(Node, int)
1.让队列中位于head.next的线程尝试获取锁。
2.确认当前节点是不是应该进入阻塞状态
如果在第1步中的节点获取到了锁，那这个节点就不用走第2步。
对于获取到锁的线程，会把这个线程对应的节点作为哨兵，变相相当于把它清除出阻塞队列了。
Thread 的
interrupt、interrupted、isinterrupted
interrupt: 设置当前线程的中断标志为true，不会立即执行中断，只有在Safepoint时线程才会知道中断标志的值是什么。
interrupted: 检测当前线程的中断标志，同时把值设置为false。 (这个是Thread的静态方法)
isinterrupted: 检测当前线程的中断标志。
LockSupport API文档
LockSupport.park(this)的作用是让当前线程进入阻塞状态，但不会释放当前线程占有的锁资源，如果检测到中断，会立即退出阻塞状态。
LockSupport.unpark(Thread)可以让指定线程退出阻塞状态。
// AbstractQueuedSynchronizer
final boolean acquireQueued(final Node node, int arg) { // 在上文中可以看出arg的值为1
boolean failed = true; // 是否没有获取到锁，true代表没获取到
try {
boolean interrupted = false;
// 下面这些行为是对每个线程都有效的，相当于节点的自旋自检
for (;;) {
final Node p = node.predecessor(); // 尝试获取当前节点的上一个节点，如果为null会导致抛出异常
// 1. 如果当前节点的上一个节点是head
// 2. 当前尝试一次获取锁 (获取到会返回true，失败会返回false)
// 同时满足上面两点才会进入if代码块，这也意味着只有位于这个head后的节点才会尝试去获取锁，
// 如果if判断成立，则代表当前线程成功获取到了锁。
if (p == head && tryAcquire(arg)) {
setHead(node); // 把当前获取到锁的节点作为head 并 清除它的prev和thread属性值，变相相当于清除出队列了
p.next = null; // help GC
failed = false;
return interrupted;
}
// 确定当前线程是否应该被阻塞
// 如果当前线程对应的等待状态为0，那下次获取锁失败后才会被阻塞，并且等待状态会被设置为-1。
// 如果当前线程对应的等待状态为-1，那线程直接阻塞。
if (shouldParkAfterFailedAcquire(p, node) &&
parkAndCheckInterrupt())
// 如果进入这里，代表当前线程的中断标志为true
interrupted = true;
}
} finally {
if (failed) // 在获取锁的过程中出现异常，导致当前线程没有获取到锁，但自旋中断了
cancelAcquire(node); // 综合逻辑中意味着将当前节点移出阻塞队列
}
}
// AbstractQueuedSynchronizer
private static boolean shouldParkAfterFailedAcquire(Node pred, Node node) {
//上一个节点的等待状态，这个waitStatus和Condition的操作有关。
int ws = pred.waitStatus;
// 经过下面的处理，可以看出来这样的一个逻辑，上一个节点的等待状态决定了当前节点是否需要被阻塞。
// 如果是SIGNAL，也就是-1的话，当前线程进入阻塞状态，类似sleep()，都不会释放线程所占有的锁资源
if (ws == Node.SIGNAL)
/*
* This node has already set status asking a release
* to signal it, so it can safely park.
*/
return true;
// 如果上一个节点的waitStatus大于0，就不断向前寻找，直至找到一个等待状态小于等于0的节点，
// 然后在这个节点和当前节点之间建立双向链接，整个过程意味着把两者之间waitStatus > 0的节点清除出阻塞队列了。
if (ws > 0) {
/*
* Predecessor was cancelled. Skip over predecessors and
* indicate retry.
*/
// 多线程操作下也不会出现问题，因为每个节点都只会找自己之前的第一个 waitStatus 小于等于0的数据
do {
node.prev = pred = pred.prev;
} while (pred.waitStatus > 0);
pred.next = node;
} else { // 额外情况(例如为null)，就把上一个节点的等待状态设置为SIGNAL，也就是-1
/*
* 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;
}
// AbstractQueuedSynchronizer
private final boolean parkAndCheckInterrupt() {
// 阻塞当前线程，但不会释放当前线程占有的锁资源
LockSupport.park(this);
// 检测当前线程的中断标志，并清除该标志，如果不清空会导致下次自旋时无法进入阻塞状态。
// 如果线程在进入阻塞状态前就已经被标记为中断状态的话，阻塞行为会立即中止执行这里的return操作。
return Thread.interrupted();
}
| waitStatus | 值 | 代表含义 |
|---|---|---|
| PROPAGATE | -3 | 当前节点后续的共享锁可以获取 |
| CONDITION | -2 | 当前节点在condition队列中 |
| SIGNAL | -1 | 当前节点的next需要unpark |
| 未命名 | 0 | 当前节点刚进入阻塞队列，还没有进入阻塞状态 |
| CANCELLED | 1 | 当前的节点被取消 |
1.3. unlock()
让当前线程的下一位的线程退出阻塞状态，并不会引起惊群。
public void unlock() {
sync.release(1); // 释放1层锁，也就是让state减1
}
public final boolean release(int arg) {
if (tryRelease(arg)) { // 尝试释放指定层锁，只有当state为0是才会进入if代码块
Node h = head;
if (h != null && h.waitStatus != 0) // 在本文中展示的调用链里，进这里的只有-1
unparkSuccessor(h); // 对head.next位置上的线程进行unpark
return true;
}
return false;
}
2. Condition
这东西和
Object#wait()、Object#notify的用法差不多
// 使用示例
public static void main(String[] args) {
ReentrantLock reentrantLock = new ReentrantLock();
Condition condition = reentrantLock.newCondition();
condition.await();
condition.signal();
condition.signalAll();
}
await()或者wait()要确保在获取到锁的代码块内编写，否则会报错。
2.1. await()
简单的过一遍代码，可以发现，
await()会把当前线程放到条件队列中，同时会释放持有的锁资源，然后把线程阻塞住。
// AbstractQueuedSynchronizer
public final void await() throws InterruptedException {
if (Thread.interrupted()) // 对中断的先行检测
throw new InterruptedException();
// 把当前线程加入到条件队列中，其中waitStatus默认为-2，之前在说lock()的逻辑时，那里面存的是null
// 条件队列不像阻塞队列，它里面是没有哨兵的。
Node node = addConditionWaiter();
// 释放当前线程掌握的锁资源
int savedState = fullyRelease(node);
int interruptMode = 0;
while (!isOnSyncQueue(node)) { // 如果不在阻塞队列上
LockSupport.park(this); // 阻塞当前线程
if ((interruptMode = checkInterruptWhileWaiting(node)) != 0)
break;
}
// ... 省略部分代码
}
2.2. signal() & signalAll()
可以看出来这两个方法的逻辑是相似的，都是在调用时把条件队列中的节点从前到后的移动到阻塞队列中，只不过前者只移一个，后者全部移过去。
在常规使用中，这两个方法在调用过程中并不会触发unpark方法，也就是说不会让线程退出阻塞状态，想要让线程退出阻塞状态，还得靠unlock()方法。
// signal()
// AbstractQueuedSynchronizer
public final void signal() {
if (!isHeldExclusively())
throw new IllegalMonitorStateException();
Node first = firstWaiter; // 获取条件队列上的第一个元素
if (first != null)
doSignal(first);
}
// AbstractQueuedSynchronizer
private void doSignal(Node first) {
// 代码块里面的逻辑: 把条件队列中的第一个节点从条件队列中移除，并添加到阻塞队列中，
// 并且把自己的waitStatus从-2改为0，把在阻塞队列中前一位的waitStatus改为-1
do {
if ( (firstWaiter = first.nextWaiter) == null)
lastWaiter = null;
first.nextWaiter = null;
} while (!transferForSignal(first) &&
(first = firstWaiter) != null);
}
// AbstractQueuedSynchronizer
final boolean transferForSignal(Node node) {
/*
* If cannot change waitStatus, the node has been cancelled.
*/
if (!compareAndSetWaitStatus(node, Node.CONDITION, 0)) // 把waitStatus从-2变为0
return false;
/*
* Splice onto queue and try to set waitStatus of predecessor to
* indicate that thread is (probably) waiting. If cancelled or
* attempt to set waitStatus fails, wake up to resync (in which
* case the waitStatus can be transiently and harmlessly wrong).
*/
Node p = enq(node); // 把当前的节点放入到阻塞队列中，返回值是原来的tail，不是当前节点，别搞错
int ws = p.waitStatus;
// 尝试把前一个节点的waitStatus修改为-1,普遍都能执行成功
if (ws > 0 || !compareAndSetWaitStatus(p, ws, Node.SIGNAL)) // 一般情况下，不会执行if里面的代码
LockSupport.unpark(node.thread);
return true;
}
// signalAll()
public final void signalAll() {
if (!isHeldExclusively())
throw new IllegalMonitorStateException();
Node first = firstWaiter;
if (first != null)
doSignalAll(first);
}
private void doSignalAll(Node first) {
lastWaiter = firstWaiter = null;
do {
// 代码块里面的逻辑: 把条件队列中的全部节点从条件队列中移除，并添加到阻塞队列中，
// 并且把自己的waitStatus从-2改为0，把在阻塞队列中前一位的waitStatus改为-1
Node next = first.nextWaiter;
first.nextWaiter = null;
transferForSignal(first);
first = next;
} while (first != null);
}
公平锁 & 非公平锁
非公平锁在调用
lock()方法时，会优先进行CAS操作；公平锁只有在队列中没有比它等得久的线程时才会进行CAS操作尝试获取一次锁。
一旦线程进入到阻塞队列，那两者就没什么区别。
非公平锁形象点描述就是：你刚来的时候可以插队，但如果没插队成功，到了等待队伍里，那就乖乖的排队就行了。
可中断锁
lockInterruptibly()和lock()的逻辑很相似，起码核心功能代码是很相似的，多了对中断异常的抛出。
见AbstractQueuedSynchronizer#doAcquireInterruptibly(int)
见AbstractQueuedSynchronizer#acquireInterruptibly(int)
太简单了，这里就不贴代码了
ReentrantLock 条件
条件队列内的节点是有序的，在唤醒的操作中，条件队列内的数据也是有序的转移到阻塞队列，所以
signal或者signal能够按向条件队列内添加的顺序执行。