并发工具类：AQS有哪些作用？（二）

Java识堂

已于 2022-03-02 10:07:36 修改

阅读量1.4k

点赞数 2

分类专栏：并发文章标签： java 开发语言后端

于 2018-04-22 10:42:19 首次发布

本文链接：https://blog.csdn.net/zzti_erlie/article/details/80036829

版权

并发专栏收录该内容

32 篇文章 4 订阅

订阅专栏

在这里插入图片描述

AQS封装的加锁和解锁方法

AQS提供了独占锁和共享锁两种加锁方式，每种方式都有响应中断和不响应中断的区别，所以AQS的锁可以分为如下四类

不响应中断的独占锁(acquire)
响应中断的独占锁(acquireInterruptibly)
不响应中断的共享锁(acquireShared)
响应中断的共享锁(acquireSharedInterruptibly)

而释放锁的方式只有两种

独占锁的释放(release)
共享锁的释放(releaseShared)

独占锁的加锁

我们前面在写入队的逻辑的时候，直接将Thread放到Queue中就完事了。看看Doug Lea是如何写的

AQS队列，当队列为空时，第一次生成两个节点，第一个节点代表当前占有锁的线程，第二个节点为抢锁失败的节点。不为空的时候，每次生成一个节点放入队尾。

当把线程放入队列中时，后续应该做哪些操作呢？

如果让你写是不是直接放入队列中就完事了？但Doug Lea是这样做的

如果当前线程是队列中的第二个节点则再尝试抢一下锁（不是第二个节点就不用抢来，轮不到），这样避免了频繁的阻塞和唤醒线程，提高了效率
上闹钟，让上一个线程来唤醒自己（后续会说到，即更改上一个节点的waitStatus）
阻塞

另外还得注意一下出队的逻辑，当A线程释放锁，唤醒队列中的B线程，A线程会从队列中删除。那出队这个事情由谁来做？是由被唤醒的线程来做，即B线程

从加锁的模版方法开始分析

// 调用ReentrantLock.FairSync#lock方法其实就是调用acquire(1);
public final void acquire(int arg) {
	if (!tryAcquire(arg) &&
		acquireQueued(addWaiter(Node.EXCLUSIVE), arg))//获取到锁返回false，否则返回true
		selfInterrupt();//当前线程将自己中断
}

先尝试获取，如果获取到直接退出，否则进入2
获取锁失败，以独占模式将线程包装成Node放到队列中
如果放入的节点是队列的第二个节点，则再尝试获取锁，因为此时锁有可能释放类，不是第二个节点就不用尝试了，因为轮不到。如果获取到锁则将当前节点设为head节点，退出，否则进入4
设置好闹钟后将自己阻塞
线程被唤醒，重新竞争锁，获取锁成功，继续执行。如果线程发生过中断，则最后重置中断标志位位true，即执行selfInterrupt()方法

从代码层面详细分析一波，走起

tryAcquire是让子类实现的

protected boolean tryAcquire(int arg) {
	throw new UnsupportedOperationException();
}

这里通过抛出异常来告诉子类要重写这个方法，为什么不将这个方法定义为abstract方法呢？因为AQS有2种功能，独占和共享，如果用abstract修饰，则子类需要同时实现两种功能的方法，对子类不友好

当队列不为空，尝试将新节点通过CAS的方式设置为尾节点，如果成功，返回附加着当前线程的节点
当队列为空，或者新节点通过CAS的方式设置为尾节点失败，进入enq方法

private Node addWaiter(Node mode) {
	Node node = new Node(Thread.currentThread(), mode);
	Node pred = tail;
	if (pred != null) {
		node.prev = pred;
		if (compareAndSetTail(pred, node)) {
			pred.next = node;
			return node;
		}
	}
	enq(node);
	return node;
}

当队列不为空，一直CAS，直到把新节点放入队尾
当队列为空，先往对列中放入一个节点，在把传入的节点CAS为尾节点

前面已经说过了哈，AQS队列为空时，第一次会放入2个节点

private Node enq(final Node node) {
	for (;;) {
		Node t = tail;
		// 队列为空，进行初始化，
		if (t == null) {
			if (compareAndSetHead(new Node()))
				tail = head;
		} else {
			node.prev = t;
			if (compareAndSetTail(t, node)) {
				t.next = node;
				return t;
			}
		}
	}
}

放入队列后还要干什么？

如果是第二个节点再尝试获取一波锁，因为此时有可能锁已经释放了，其他节点就不用了，因为还轮不到
上闹钟，让别的线程唤醒自己
阻塞自己

// 自旋获取锁，直到获取锁成功，或者异常退出
// 但是并不是busy acquire，因为当获取失败后会被挂起，由前驱节点释放锁时将其唤醒
// 同时由于唤醒的时候可能有其他线程竞争，所以还需要进行尝试获取锁，体现的非公平锁的精髓。
final boolean acquireQueued(final Node node, int arg) {
	boolean failed = true;
	try {
		boolean interrupted = false;
		for (;;) {
			// 获取前继节点
			final Node p = node.predecessor();
			// node节点的前继节点是head节点，尝试获取锁，如果成功说明head节点已经释放锁了
			// 将node设为head开始运行(head中不包含thread)
			if (p == head && tryAcquire(arg)) {
				setHead(node);
				// 将第一个节点出队
				p.next = null; // help GC
				failed = false;
				return interrupted;
			}
			// 获取锁失败后是否可以挂起
			// 如果可以挂起，则阻塞当前线程（获取锁失败的节点）
			if (shouldParkAfterFailedAcquire(p, node) &&
				parkAndCheckInterrupt())
				interrupted = true;
		}
	} finally {
		if (failed)
			cancelAcquire(node);
	}
}

根据前继节点的状态，是否可以阻塞当前获取锁失败的节点

一般情况会经历如下2个过程

默认情况下上一个节点的waitStatus=0，所以会进入compareAndSetWaitStatus方法，通过cas将上一个节点的waitStatus设置为SIGNAL，然后return false
shouldParkAfterFailedAcquire方法外面是一个死循环，当再次进入这个方法时，如果上一步cas成功，则会走第一个if，return true。接着执行parkAndCheckInterrupt，线程会阻塞

private static boolean shouldParkAfterFailedAcquire(Node pred, Node node) {
	int ws = pred.waitStatus;
	// 前继节点释放时会unpark后继节点，可以挂起
	if (ws == Node.SIGNAL)
		return true;
	if (ws > 0) {
		//将CANCELLED状态的线程清理出队列
		// 后面会提到为什么会有CANCELLED的节点
		do {
			node.prev = pred = pred.prev;
		} while (pred.waitStatus > 0);
		pred.next = node;
	} else {
		// 将前继节点的状态设置为SIGNAL，代表释放锁时需要唤醒后面的线程
		// cas更新可能失败，所以不能直接返回true
		compareAndSetWaitStatus(pred, ws, Node.SIGNAL);
	}
	return false;
}

shouldParkAfterFailedAcquire表示上好闹钟了，可以阻塞线程了。后续当线程被唤醒的时候会从return语句出继续执行，然后进入acquireQueued方法的死循环，重新抢锁。至此，加锁结束。

// 挂起线程，返回是否被中断过
private final boolean parkAndCheckInterrupt() {
	// 阻塞线程
	LockSupport.park(this);
	// 返回当前线程是否被调用过Thread#interrupt方法
	return Thread.interrupted();
}

最后用一个流程图来解释不响应中断的独占锁
在这里插入图片描述

入队过程中有异常该怎么办？

这部分内容比较难，看着吃力的小伙伴跳过即可，对主流程影响不大

可以看到上面调用acquireQueued方法发生异常的时候，会调用cancelAcquire方法，我们就详细分析一下这个cancelAcquire方法有哪些作用？

哪些地方执行发生异常会执行cancelAcquire?

可以看到调用cancelAcquire方法的有如下几个部分
在这里插入图片描述
分析这些方法的调用，发现基本就是如下2个地方会发生异常

尝试获取锁的方法如tryAcquire，这些一般是交给子类来实现的
当线程是被调用Thread#interrupt方法唤醒，如果要响应中断，会抛出InterruptedException

在这里插入图片描述

//处理异常退出的node
private void cancelAcquire(Node node) {
	if (node == null)
		return;

	// 设置该节点不再关联任何线程
	node.thread = null;

	// 跳过CANCELLED节点，找到一个有效的前继节点
	Node pred = node.prev;
	while (pred.waitStatus > 0)
		node.prev = pred = pred.prev;

	// 获取过滤后的有效节点的后继节点
	Node predNext = pred.next;

	// 设置状态为取消
	node.waitStatus = Node.CANCELLED;

	// case 1
	if (node == tail && compareAndSetTail(node, pred)) {
		compareAndSetNext(pred, predNext, null);
	} else {
		// case 2
		int ws;
		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 {
			// case3
			unparkSuccessor(node);
		}

		node.next = node; // help GC
	}
}

将node出队有如下三种情况

当前节点是tail
当前节点不是head的后继节点，也不是tail
当前节点是head的后继节点

当前节点是tail

compareAndSetTail，将tail指向pred
compareAndSetNext，将pred的next指向null，也就是把当前节点移出队列

在这里插入图片描述

当前节点不是head的后继节点，也不是tail
在这里插入图片描述
这里将node的前继节点的next指向了node的后继节点，即compareAndSetNext(pred, predNext, next)，注意pred和node节点中间有可能有CANCELLED的节点，怕乱就没画出来

当前节点是head的后继节点

没有对队列进行操作，只是进行head后继节点的唤醒操作（unparkSuccessor方法，后面会分析这个方法），因为此时他是head的后继节点，还是有可能获取到锁的，所以唤醒它尝试获取一波锁，当再次调用到shouldParkAfterFailedAcquire（判断是否应该阻塞的方法时）会把CANCELLED状态的节点从队列中删除

独占锁的解锁

独占锁是释放其实就是利用cas将state-1，当state=0表示锁被释放，需要将阻塞队列中的线程唤醒

public final boolean release(int arg) {
	// 是否需要释放锁，返回ture则需要释放锁
	if (tryRelease(arg)) {
		Node h = head;
		if (h != null && h.waitStatus != 0)
			// 唤醒阻塞的线程
			unparkSuccessor(h);
		return true;
	}
	return false;
}

tryRelease即具体的解锁逻辑，需要子类自己去实现

唤醒同步队列中的线程，可以看到前面加了判断h != null && h.waitStatus != 0

h = null，说明同步同步队列中没有数据，则不需要唤醒
h = null && waitStatus = 0，同步队列是有了，但是没有线程给自己上闹钟，不用唤醒
h != null && waitStatus < 0，说明头节点被人上了闹钟，自己需要唤醒阻塞的线程
h != null && waitStatus > 0，头节点因为发生异常被设置为取消，但还是得唤醒线程

private void unparkSuccessor(Node node) {

	int ws = node.waitStatus;
	if (ws < 0)
		compareAndSetWaitStatus(node, ws, 0);

	// 头结点的下一个节点
	Node s = node.next;
	// 为空或者被取消
	if (s == null || s.waitStatus > 0) {
		s = null;
		// 从队列尾部向前遍历找到最前面的一个waitStatus<=0的节点
		for (Node t = tail; t != null && t != node; t = t.prev)
			if (t.waitStatus <= 0)
				s = t;
	}
	if (s != null)
		// 唤醒节点,但并不表示它持有锁，要从阻塞的地方开始运行
		LockSupport.unpark(s.thread);
}

为什么要从后向前找第一个非CANCELLED的节点呢？

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;
    if (pred != null) {
        node.prev = pred;
        if (compareAndSetTail(pred, node)) {
        	// 线程在这里挂起了
            pred.next = node;
            return node;
        }
    }
    enq(node);
    return node;
}

这其实和入队的逻辑有关系，假如Node1在图示位置挂起了，Node1后面又陆续增加了Node2和Node3，如果此时从前向后遍历会导致元素丢失，不能正确唤醒线程
在这里插入图片描述

分析一下独占锁响应中断和不响应中断的区别

我们之前说过独占锁可以响应中断，也可以不响应中断，调用的方法如下？

不响应中断的独占锁(acquire)
响应中断的独占锁(acquireInterruptibly)

所以我们只需要看这2个方法的区别在哪里就可以，我下面只列出有区别的部分哈。

public final void acquire(int arg) {
    if (!tryAcquire(arg) &&
        acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
        selfInterrupt();
}

 public final void acquireInterruptibly(int arg)
         throws InterruptedException {
     // 判断线程是否被中断
     if (Thread.interrupted())
         throw new InterruptedException();
     if (!tryAcquire(arg))
         doAcquireInterruptibly(arg);
 }

acquire在尝试获取锁的时候完全不管线程有没有被中断，而acquireInterruptibly在尝试获取锁之前会判断线程是否被中断，如果被中断，则直接抛出异常。

tryAcquire方法一样，所以我们只需要对比acquireQueued方法和doAcquireInterruptibly方法的区别即可
在这里插入图片描述
执行acquireQueued方法当线程发生中断时，只是将interrupted设置为true，并且调用selfInterrupt方法将中断标志位设置为true

而执行doAcquireInterruptibly方法，当线程发生中断时，直接抛出异常。

最后看一下parkAndCheckInterrupt方法，这个方法中判断线程是否中断的逻辑特别巧！

private final boolean parkAndCheckInterrupt() {
	LockSupport.park(this);
	return Thread.interrupted();
}

Thread类提供了如下2个方法来判断线程是否是中断状态

isInterrupted
interrupted

这里为什么用interrupted而不是isInterrupted的呢？（这部分内容比较难，看着吃力的小伙伴跳过即可，对主流程影响不大）

演示一下这2个方法的区别

@Test
public void testInterrupt() throws InterruptedException {
    Thread thread = new Thread(() -> {
        while (true) {}
    });
    thread.start();
    TimeUnit.MICROSECONDS.sleep(100);
    thread.interrupt();
    // true
    System.out.println(thread.isInterrupted());
    // true
    System.out.println(thread.isInterrupted());
    // true
    System.out.println(thread.isInterrupted());
}

@Test
public void testInterrupt2() {
    Thread.currentThread().interrupt();
    // true
    System.out.println(Thread.interrupted());
    // false
    System.out.println(Thread.interrupted());
    // false
    System.out.println(Thread.interrupted());
}

isInterrupted和interrupted的方法区别如下

Thread#isInterrupted：测试线程是否是中断状态，执行后不更改状态标志
Thread#interrupted：测试线程是否是中断状态，执行后将中断标志更改为false

接着再写2个例子

public static void main(String[] args) {
	LockSupport.park();
	// end被一直阻塞没有输出
	System.out.println("end");
}

public static void main(String[] args) {
	Thread.currentThread().interrupt();
	LockSupport.park();
	// 输出end
	System.out.println("end");
}

可以看到当线程被中断时，调用park()方法并不会被阻塞

public static void main(String[] args) {
	Thread.currentThread().interrupt();
	LockSupport.park();
	// 返回中断状态，并且清除中断状态
	Thread.interrupted();
	// 输出start
	System.out.println("start");
	LockSupport.park();
	// end被阻塞，没有输出
	System.out.println("end");
}

到这我们就能理解为什么要进行中断的复位了

如果当前线程是非中断状态，则在执行park时被阻塞，返回中断状态false
如果当前线程是中断状态，则park方法不起作用，返回中断状态true，interrupted将中断复位，变为false
再次执行循环的时候，前一步已经在线程的中断状态进行了复位，则再次调用park方法时会阻塞

所以这里要对中断进行复位，是为了不让循环一直执行，让当前线程进入阻塞状态，如果不进行复位，前一个线程在获取锁之后执行了很耗时的操作，那当前线程岂不是要一直执行死循环，造成CPU使用率飙升？

独占锁的获取和释放我们已经搞清楚了，来分析共享锁的获取和释放

共享锁的加锁

加锁成功则执行业务逻辑，否则入队并阻塞

public final void acquireShared(int arg) {
    if (tryAcquireShared(arg) < 0)
        doAcquireShared(arg);
}

入队的逻辑和独占锁的入队逻辑差不多

private void doAcquireShared(int arg) {
    final Node node = addWaiter(Node.SHARED);
    boolean failed = true;
    try {
        boolean interrupted = false;
        for (;;) {
            final Node p = node.predecessor();
            if (p == head) {
                int r = tryAcquireShared(arg);
                if (r >= 0) {
                    setHeadAndPropagate(node, r);
                    p.next = null; // help GC
                    if (interrupted)
                        selfInterrupt();
                    failed = false;
                    return;
                }
            }
            if (shouldParkAfterFailedAcquire(p, node) &&
                parkAndCheckInterrupt())
                interrupted = true;
        }
    } finally {
        if (failed)
            cancelAcquire(node);
    }
}

在获锁成功后，除了设置头节点，还多了一步操作，就是唤醒同步队列中的所有线程

private void setHeadAndPropagate(Node node, int propagate) {
    Node h = head; // Record old head for check below
    setHead(node);
    if (propagate > 0 || h == null || h.waitStatus < 0 ||
        (h = head) == null || h.waitStatus < 0) {
        Node s = node.next;
        if (s == null || s.isShared())
            doReleaseShared();
    }
}

共享锁的解锁

public final boolean releaseShared(int arg) {
    if (tryReleaseShared(arg)) {
        doReleaseShared();
        return true;
    }
    return false;
}

唤醒同步队列中的所有线程

private void doReleaseShared() {
    for (;;) {
        Node h = head;
        if (h != null && h != tail) {
            int ws = h.waitStatus;
            if (ws == Node.SIGNAL) {
                if (!compareAndSetWaitStatus(h, Node.SIGNAL, 0))
                    continue;            // loop to recheck cases
                unparkSuccessor(h);
            }
            else if (ws == 0 &&
                     !compareAndSetWaitStatus(h, 0, Node.PROPAGATE))
                continue;                // loop on failed CAS
        }
        if (h == head)                   // loop if head changed
            break;
    }
}

独占锁和共享锁的区别

我们来总结一下独占锁和共享锁的区别

独占锁：一个锁能被多个线程获取，加锁失败阻塞放入同步队列，加锁成功执行业务逻辑，解锁唤醒同步队列中的一个线程
共享锁：一个锁只能被一个线程获取，加锁失败阻塞放入同步队列，加锁成功会唤醒同步队列中的所有线程，解锁也会唤醒同步队列中的所有线程

参考博客

[1]https://objcoding.com/2019/05/05/aqs-exclusive-lock/
[2]https://objcoding.com/2019/05/08/aqs-shared-lock/
[1]http://www.ideabuffer.cn/2017/03/15/%E6%B7%B1%E5%85%A5%E7%90%86%E8%A7%A3AbstractQueuedSynchronizer%EF%BC%88%E4%B8%80%EF%BC%89/
[2]https://zhuanlan.zhihu.com/p/28843912
[3]https://zhuanlan.zhihu.com/p/27374597
[4]https://blog.csdn.net/column/details/17063.html
[5]http://www.cnblogs.com/liuyun1995/archive/2018/02.html
private和final
[4]http://blog.sina.com.cn/s/blog_71643ce10101h97b.html
[7]https://tech.meituan.com/2019/12/05/aqs-theory-and-apply.html
响应中断和不响应中断
[8]https://blog.csdn.net/m0_45406092/article/details/113774715
[9]https://blog.csdn.net/javazejian/article/details/76167357
写的挺好的实现
[10]https://segmentfault.com/a/1190000016447307
又一个实现
[11]https://mp.weixin.qq.com/s/Tqbz9SaMvB3n9G5HYwQjCA
cancelAcquire方法的分析实现
[12]https://www.jianshu.com/p/01f2046aab64

Java识堂

关注

2
点赞
踩
2

收藏

觉得还不错? 一键收藏
打赏
1
评论
并发工具类：AQS有哪些作用？（二）

前言JUC中的许多并发工具类ReentrantLock，CountDownLatch等的实现都依赖AbstractQueuedSynchronizerAbstractQueuedSynchronizer定义了一个锁实现的内部流程，而如何上锁和解锁则在各个子类中实现，典型的模板方法模式源码基于jdk1.8.0_20，AQS内部维护一个FIFO的队列，通过该队列来实现线程的并发访问控制，队列中的元素是一个Node节点static final class Node { //表示当前线程以共享模式持有
复制链接

扫一扫