深入AQS原理(我在一开始学的时候就把非公平锁和公平锁给弄混了)

谈到并发,我们不得不说AQS(AbstractQueuedSynchronizer),所谓的AQS即是抽象的队列式的同步器,内部定义了很多锁相关的方法,我们熟知的ReentrantLockReentrantReadWriteLockCountDownLatchSemaphore等都是基于AQS来实现的。

我们先看下AQS相关的UML图:

深入AQS原理(我在一开始学的时候就把非公平锁和公平锁给弄混了)_第1张图片

 

在下面自己整理出一张AQS的框架图,供大家参考

深入AQS原理(我在一开始学的时候就把非公平锁和公平锁给弄混了)_第2张图片

 AQS实现原理

AQS中 维护了一个volatile int state(代表共享资源)和一个FIFO线程等待队列(多线程争用资源被阻塞时会进入此队列)。

这里volatile能够保证多线程下的可见性,当state=1则代表当前对象锁已经被占有,其他线程来加锁时则会失败,加锁失败的线程会被放入一个FIFO的等待队列中,并且会被UNSAFE.park()操作挂起,等待其他获取锁的线程释放锁才能够被唤醒。

另外state的操作都是通过CAS来保证其并发修改的安全性。

具体原理我们可以用一张图来简单概括

深入AQS原理(我在一开始学的时候就把非公平锁和公平锁给弄混了)_第3张图片

 AQS 中提供了很多关于锁的实现方法,

  • getState():获取锁的标志state值
  • setState():设置锁的标志state值
  • tryAcquire(int):独占方式获取锁。尝试获取资源,成功则返回true,失败则返回false。
  • tryRelease(int):独占方式释放锁。尝试释放资源,成功则返回true,失败则返回false。

等等。

目录结构

三个线程(线程一、线程二、线程三)同时来加锁/释放锁

目录如下:

  • 线程一加锁成功时AQS内部实现
  • 线程二/三加锁失败时AQS中等待队列的数据模型
  • 线程一释放锁及线程二获取锁实现原理
  • 通过线程场景来讲解公平锁具体实现原理
  • 通过线程场景来讲解Condition中await()signal()实现原理

这里会通过画图来分析每个线程加锁、释放锁后AQS内部的数据结构和实现原理。

场景分析

线程一加锁成功

如果同时有三个线程并发抢占锁,此时线程一抢占锁成功,线程二线程三抢占锁失败,具体执行流程如下:

深入AQS原理(我在一开始学的时候就把非公平锁和公平锁给弄混了)_第4张图片

此时AQS内部数据为:

深入AQS原理(我在一开始学的时候就把非公平锁和公平锁给弄混了)_第5张图片 

 线程二线程三加锁失败

深入AQS原理(我在一开始学的时候就把非公平锁和公平锁给弄混了)_第6张图片

 有图可以看出,等待队列中的节点Node是一个双向链表,这里SIGNALNodewaitStatus属性,Node中还有一个nextWaiter属性,这个并未在图中画出来,这个到后面Condition会具体讲解的

这里使用的ReentrantLock非公平锁,线程进来直接利用CAS尝试抢占锁,如果抢占成功state值回被改为1,且设置对象独占锁线程为当前线程

线程二抢占锁失败

可以直接看屎黄色标注的快速理解

我们按照真实场景来分析,线程一抢占锁成功后,state变为1,线程二通过CAS修改state变量必然会失败。此时AQSFIFO(First In First Out 先进先出)队列中数据如图所示:

深入AQS原理(我在一开始学的时候就把非公平锁和公平锁给弄混了)_第7张图片

我们将线程二执行的逻辑一步步拆解来看:

java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire()

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

先看看tryAcquire()的具体实现: java.util.concurrent.locks.ReentrantLock .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)
            throw new Error("Maximum lock count exceeded");
        setState(nextc);
        return true;
    }
    return false;
}

nonfairTryAcquire()方法中首先会获取state的值,如果不为0则说明当前对象的锁已经被其他线程所占有,接着判断占有锁的线程是否为当前线程,如果是则累加state值,这就是可重入锁的具体实现,累加state值,释放锁的时候也要依次递减state

如果state为0,则执行CAS操作,尝试更新state值为1,如果更新成功则代表当前线程加锁成功。

线程二为例,因为线程一已经将state修改为1,所以线程二通过CAS修改state的值不会成功。加锁失败。

线程二执行tryAcquire()后会返回false,接着执行addWaiter(Node.EXCLUSIVE)逻辑,将自己加入到一个FIFO等待队列中。此时等待对内中的tail指针为空,直接调用enq(node)方法将当前线程加入等待队列尾部。(这是个双向链表)

而end方法是这样做的

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;
            }
        }
    }
}

第一遍循环时tail指针为空,进入if逻辑,使用CAS操作设置head指针,将head指向一个新创建的Node节点。此时AQS中数据:

深入AQS原理(我在一开始学的时候就把非公平锁和公平锁给弄混了)_第8张图片

 

 执行完成之后,headtailt都指向第一个Node元素

接着执行第二遍循环,进入else逻辑,此时已经有了head节点,这里要操作的就是将线程二对应的Node节点挂到head节点后面。此时队列中就有了两个Node节点

深入AQS原理(我在一开始学的时候就把非公平锁和公平锁给弄混了)_第9张图片

 addWaiter()方法执行完后,会返回当前线程创建的节点信息(注意因为线程二是第一个加入等待队列的,所以是经过了两个循环才创建好第二个节点)。继续往后执行acquireQueued(addWaiter(Node.EXCLUSIVE), arg) 逻辑,此时传入的参数线程二对应的Node点信息。

acquireQueued()这个方法会先判断当前传入的Node对应的前置节点是否为head如果是则尝试加锁。加锁成功过则将当前节点设置为head节点,然后空置之前的head节点,方便后续被垃圾回收掉。

果加锁失败或者Node的前置节点不是head节点,就会通过shouldParkAfterFailedAcquire方法 将head节点的waitStatus变为了SIGNAL=-1,最后执行parkAndChecknIterrupt方法,调用LockSupport.park()挂起当前线程

此时AQS中的数据如下图:

深入AQS原理(我在一开始学的时候就把非公平锁和公平锁给弄混了)_第10张图片

此时线程二就静静的待在AQS的等待队列里面了,等着其他线程释放锁来唤醒它

注意每次前一个节点的变化

线程三抢占锁失败

看完了线程二抢占锁失败的分析,那么再来分析线程三抢占锁失败就很简单了

此时等待队列的tail节点指向线程二,进入if逻辑后,通过CAS指令将tail节点重新指向线程三。接着线程三调用enq()方法执行入队操作,和上面线程二执行方式是一致的,入队后会修改线程二对应的Node中的waitStatus=SIGNAL。最后线程三也会被挂起。此时等待队列的数据如图:

深入AQS原理(我在一开始学的时候就把非公平锁和公平锁给弄混了)_第11张图片

 

线程一释放锁

现在来分析下释放锁的过程,首先是线程一释放锁,释放锁后会唤醒head节点的后置节点,也就是我们现在的线程二,具体操作流程如下:

深入AQS原理(我在一开始学的时候就把非公平锁和公平锁给弄混了)_第12张图片

 执行完后等待队列数据如下:

深入AQS原理(我在一开始学的时候就把非公平锁和公平锁给弄混了)_第13张图片

此时线程二已经被唤醒,继续尝试获取锁,如果获取锁失败,则会继续被挂起。如果获取锁成功,则AQS中数据如图。

深入AQS原理(我在一开始学的时候就把非公平锁和公平锁给弄混了)_第14张图片

 线程一释放锁

先tryRelease()方法,这个方法具体实现在ReentrantLock中,如果tryRelease执行成功,则继续判断head节点的waitStatus是否为0,前面我们已经看到过,headwaitStatueSIGNAL(-1),这里就会执行unparkSuccessor()方法来唤醒head的后置节点,也就是我们上面图中线程二对应的Node节点。

执行完ReentrantLock.tryRelease()后,state被设置成0,Lock对象的独占锁被设置为null。此时看下AQS中的数据:深入AQS原理(我在一开始学的时候就把非公平锁和公平锁给弄混了)_第15张图片

 接着执行java.util.concurrent.locks.AbstractQueuedSynchronizer.unparkSuccessor()方法,唤醒head的后置节点:这里主要是将head节点的waitStatus设置为0。

此时重新将head指针指向线程二对应的Node节点,且使用LockSupport.unpark方法来唤醒线程二

被唤醒的线程二会接着尝试获取锁,用CAS指令修改state数据。 执行完成后可以查看AQS中数据:

深入AQS原理(我在一开始学的时候就把非公平锁和公平锁给弄混了)_第16张图片

此时线程二被唤醒,线程二接着之前被park的地方继续执行,继续执行acquireQueued()方法。 

此时线程二被唤醒,继续执行for循环,判断线程二的前置节点是否为head,如果是则继续使用tryAcquire()方法来尝试获取锁,其实就是使用CAS操作来修改state值,如果修改成功则代表获取锁成功。接着将线程二设置为head节点,然后空置之前的head节点数据,被空置的节点数据等着被垃圾回收深入AQS原理(我在一开始学的时候就把非公平锁和公平锁给弄混了)_第17张图片

线程二释放锁/线程三加锁 

线程二释放锁时,会唤醒被挂起的线程三,流程和上面大致相同,被唤醒的线程三会再次尝试加锁。

公平锁实现原理

上面所有的加锁场景都是基于非公平锁来实现的,非公平锁ReentrantLock的默认实现,那我们接着来看一下公平锁的实现原理,这里先用一张图来解释公平锁非公平锁的区别:

非公平锁执行流程:深入AQS原理(我在一开始学的时候就把非公平锁和公平锁给弄混了)_第18张图片

这里我们还是用之前的线程模型来举例子,当线程二释放锁的时候,唤醒被挂起的线程三线程三执行tryAcquire()方法使用CAS操作来尝试修改state值,如果此时又来了一个线程四也来执行加锁操作,同样会执行tryAcquire()方法。

 这种情况就会出现竞争,线程四如果获取锁成功,线程三仍然需要待在等待队列中被挂起。这就是所谓的非公平锁线程三辛辛苦苦排队等到自己获取锁,却眼巴巴的看到线程四插队获取到了锁。

公平锁执行流程:

深入AQS原理(我在一开始学的时候就把非公平锁和公平锁给弄混了)_第19张图片

 

非公平锁公平锁的区别: 非公平锁性能高于公平锁性能。非公平锁可以减少CPU唤醒线程的开销,整体的吞吐效率会高点,CPU也不必取唤醒所有线程,会减少唤起线程的数量

非公平锁性能虽然优于公平锁,但是会存在导致线程饥饿的情况。在最坏的情况下,可能存在某个线程一直获取不到锁。不过相比性能而言,饥饿问题可以暂时忽略,这可能就是ReentrantLock默认创建非公平锁的原因之一了。

Condition实现原理

应知

Condition是在java 1.5中才出现的,它用来替代传统的Objectwait()notify()实现线程间的协作,相比使用Objectwait()notify(),使用Condition中的await()signal()这种方式实现线程间协作更加安全和高效。因此通常来说比较推荐使用Condition

其中AbstractQueueSynchronizer中实现了Condition中的方法,主要对外提供awaite(Object.wait())signal(Object.notify())调用。

Condition Demo示例

/**
 * ReentrantLock 实现源码学习
 * @author 一枝花算不算浪漫
 * @date 2020/4/28 7:20
 */
public class ReentrantLockDemo {
    static ReentrantLock lock = new ReentrantLock();

    public static void main(String[] args) {
        Condition condition = lock.newCondition();

        new Thread(() -> {
            lock.lock();
            try {
                System.out.println("线程一加锁成功");
                System.out.println("线程一执行await被挂起");
                condition.await();
                System.out.println("线程一被唤醒成功");
            } catch (Exception e) {
                e.printStackTrace();
            } finally {
                lock.unlock();
                System.out.println("线程一释放锁成功");
            }
        }).start();

        new Thread(() -> {
            lock.lock();
            try {
                System.out.println("线程二加锁成功");
                condition.signal();
                System.out.println("线程二唤醒线程一");
            } finally {
                lock.unlock();
                System.out.println("线程二释放锁成功");
            }
        }).start();
    }
}

深入AQS原理(我在一开始学的时候就把非公平锁和公平锁给弄混了)_第20张图片

 Condition实现原理图解

深入AQS原理(我在一开始学的时候就把非公平锁和公平锁给弄混了)_第21张图片

 线程一执行await()方法:

await()方法中首先调用addConditionWaiter()将当前线程加入到Condition队列中

执行完后我们可以看下Condition队列中的数据:

深入AQS原理(我在一开始学的时候就把非公平锁和公平锁给弄混了)_第22张图片

 这里会用当前线程创建一个Node节点,waitStatusCONDITION。接着会释放该节点的锁,调用之前解析过的release()方法,释放锁后此时会唤醒被挂起的线程二线程二会继续尝试获取锁。

接着调用isOnSyncQueue()方法是判断当前的线程节点是不是在同步队列中,因为上一步已经释放了锁,也就是说此时可能有线程已经获取锁同时可能已经调用了singal()方法,如果已经唤醒,那么就不应该park了,而是退出while方法,从而继续争抢锁。

此时线程一被挂起,线程二获取锁成功。.......................

condition的优势

  • Condition可以精准的对多个不同条件进行控制,wait/notify只能和synchronized关键字一起使用,并且只能唤醒一个或者全部的等待队列;

  • Condition需要使用Lock进行控制,使用的时候要注意lock()后及时的unlock(),Condition有类似于await的机制,因此不会产生加锁方式而产生的死锁出现,同时底层实现的是park/unpark的机制,因此也不会产生先唤醒再挂起的死锁,一句话就是不会产生死锁,但是wait/notify会产生先唤醒再挂起的死锁。

  •  

在理解ReentrantLock的可重入性之前,让我们先回顾一下synchronized关键字的工作方式。

synchronized是Java中的关键字,用于实现线程的同步和互斥访问。当一个线程进入synchronized块或方法时,会尝试获取锁,如果锁已经被其他线程获取,则该线程会被阻塞,直到锁被释放。获取到锁的线程可以执行同步块或方法,并在执行完毕后释放锁。

可重入性(Reentrancy)指的是同一个线程在持有锁的情况下,可以再次获取该锁而不会被阻塞。换句话说,一个线程可以反复地进入它已经拥有的锁所保护的代码块,而不会被自己所持有的锁所阻塞。

ReentrantLock是Java中提供的一种可重入锁的实现。与synchronized关键字不同,ReentrantLock使用显式地加锁和释放锁的方式来实现线程的同步。它允许一个线程在持有锁的情况下,重复地获取锁而不会被阻塞,这就是可重入性的体现。

例如,当线程A获得了ReentrantLock的锁并进入了同步块,此时线程A可以在同步块内部再次调用ReentrantLock的lock()方法,获取相同的锁。这样做是允许的,因为ReentrantLock会记录锁的持有线程和持有次数,只有当线程A完全释放了它所持有的锁,其他线程才能获得该锁。

可重入性的好处在于它简化了编程模型,允许线程在多层嵌套的同步代码中反复获取和释放锁,而不会导致死锁或线程阻塞。这使得ReentrantLock在某些复杂的同步场景中更灵活和可控。

总结而言,ReentrantLock的可重入性允许同一个线程在持有锁的情况下重复获取相同的锁,而不会被阻塞。这种机制简化了编程模型,并提供了更灵活和可控的线程同步机制。

 

本篇文章参考自【深入AQS原理】我画了35张图就是为了让你深入 AQS - 掘金

你可能感兴趣的:(并发,java,开发语言)