AQS深入理解系列(一) 独占锁的获取过程

2024-01-06 00:50

本文主要是介绍AQS深入理解系列(一) 独占锁的获取过程,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

文章目录

  • 前言
  • AQS实现核心
    • state
    • 等待队列
    • CAS
  • 根据实现核心找AQS的成员
    • state
    • 等待队列
    • CAS
  • 观察ReentrantLock的内部类
  • 公平的、不响应中断的 独占锁的获取
    • tryAcquire
    • addWaiter
    • enq
    • enq的尾分叉 与 prev的有效性
    • acquireQueued
    • shouldParkAfterFailedAcquire
    • parkAndCheckInterrupt
  • 不公平的、不响应中断的 独占锁的获取
    • 观察ReentrantLock的内部类
  • 响应中断的 独占锁的获取
  • 超时的 独占锁的获取
  • 只一次尝试的 非公平的 独占锁的获取
  • 总结

前言

AQS(AbstractQueuedSynchronizer)可以说是整个Java并发框架的基础,其实现大量依赖乐观锁的方式(即CAS+自旋)。它实现了一个FIFO的等待队列用于等待获取同步状态,而获取/释放同步器状态的函数则依靠子类来实现。

虽然AQS是一个抽象类,但却没有任何抽象方法。如果定义为抽象方法确实不合适,因为继承使用AQS并不一定需要使用到AQS提供的所有功能(独占锁和共享锁),这样子类反而需要实现所有抽象方法。如果定义为空实现的普通方法,虽然不需要子类实现所有空方法了,但这样还是不够明确。现在AQS将这些方法的实现为抛出UnsupportedOperationException异常,那么如果是子类需要使用的方法,就覆盖掉它;如果是子类不需要使用的方法,一旦调用就会抛出异常。

JUC框架 系列文章目录

AQS实现核心

state

同步器有一个state,它代表着当前同步器的状态,它是整个AQS的核心属性。我们平时使用的JUC框架下的常用类比如ReentrantLock,其实它们的方法就是在设置和改变这个state。而之前说的子类需要实现的方法,简单的说,它的实现逻辑也就是在设置和改变这个state。

等待队列

AQS中已经为我们实现了一个FIFO的等待队列,它是一个双向链表。由于同步器的state一般不能让所有线程同时获得,所以将这些需要暂时等待的线程包装成一个节点放到队列中去,当获取state的条件满足时,会将这个节点内的线程唤醒,以便它接下来去尝试获取state。

CAS

CAS是一种轻量级的并发处理,在对AQS属性以及队列节点属性进行修改时,都会用到CAS操作。既然是多线程环境下,那么就会有多个线程同时修改这些属性,而CAS保证了同一时刻只有一个线程能修改成功,而其他CAS操作失败的线程,一般则会通过自旋继续尝试CAS操作。

根据实现核心找AQS的成员

根据上面讲到的AQS实现核心,我们来寻找AQS类中成员。

state

private volatile int state;

如上,state已经被我们找到了,它一个volatile的变量,这样就保证了可见性。

由于本文分析的是独占锁,所以当state为0时,代表没有线程持有锁。当state为1时,代表有线程持有锁。当state>1时,代表有线程持有该锁,并且重入过该锁。所以state是否为0,可以作为判断是否有线程持有该独占锁的标准。

private transient Thread exclusiveOwnerThread;

exclusiveOwnerThread成员则用来记录当前持有锁的线程。

等待队列

等待队列的节点需要有一个实现类,它正是Node这个静态内部类。

    static final class Node {/** Marker to indicate a node is waiting in shared mode */static final Node SHARED = new Node();/** Marker to indicate a node is waiting in exclusive mode */static final Node EXCLUSIVE = null;/** waitStatus value to indicate thread has cancelled */static final int CANCELLED =  1;/** waitStatus value to indicate successor's thread needs unparking */static final int SIGNAL    = -1;/** waitStatus value to indicate thread is waiting on condition */static final int CONDITION = -2;/*** waitStatus value to indicate the next acquireShared should* unconditionally propagate*/static final int PROPAGATE = -3;volatile int waitStatus;// 双向链表的结构volatile Node prev;volatile Node next;// Node对象用来包装线程volatile Thread thread;// 用来表明当前node的线程是想要获取共享锁还是独占锁Node nextWaiter;final boolean isShared() {return nextWaiter == SHARED;}}
  • 作为双向链表的节点,自然需要prevnext,即前驱和后继指针。通过这两个指针将各节点连接起来。
  • thread成员肯定也是必需的。因为Node就是用来设计包装线程对象的,自然需要一个Thread类型的成员。
  • nextWaiter成员则是用来表明当前node的线程是想要获取共享锁还是独占锁。注意,这个成员只是这个作用,不是用来连接双向链表的。
  • 最重要的还是waitStatus成员,用来表明node代表线程的状态。

有了队列节点,自然也需要AQS持有这个队列。

// 头结点,固定是一个dummy node,因为它的thread成员固定为null
private transient volatile Node head;// 尾节点,请求锁失败的线程,会包装成node,放到队尾
private transient volatile Node tail;

headtail都是AQS的成员,分别代表队列的头和尾,通过持有这两个成员,相当于AQS也持有了这个队列。
在这里插入图片描述
等待队列如上图所示,注意head节点作为一个dummy node,它的thread成员一定为null。

  • head节点的thread成员为null,可以理解为将它的thread成员放到AQS的exclusiveOwnerThread属性上去了,所以它的thread成员为null。
  • 即使等待线程只有一个,等待队列中的节点个数也肯定是2个,因为第一个节点总是dummy node。

CAS

熟悉原子类源码的同学,肯定都见过利用Unsafe工具类来调用CAS操作。对于AQS或Node的属性修改,也需要使用这些CAS操作。

    private static final Unsafe unsafe = Unsafe.getUnsafe();private static final long stateOffset;private static final long headOffset;private static final long tailOffset;private static final long waitStatusOffset;private static final long nextOffset;static {try {stateOffset = unsafe.objectFieldOffset(AbstractQueuedSynchronizer.class.getDeclaredField("state"));headOffset = unsafe.objectFieldOffset(AbstractQueuedSynchronizer.class.getDeclaredField("head"));tailOffset = unsafe.objectFieldOffset(AbstractQueuedSynchronizer.class.getDeclaredField("tail"));waitStatusOffset = unsafe.objectFieldOffset(Node.class.getDeclaredField("waitStatus"));nextOffset = unsafe.objectFieldOffset(Node.class.getDeclaredField("next"));} catch (Exception ex) { throw new Error(ex); }}

从上面可以看到,需要通过CAS操作来修改的属性有AQS的stateheadtail;Node的waitStatusnext。因为这几个属性确实会被多线程访问。

protected final boolean compareAndSetState(int expect, int update) {return unsafe.compareAndSwapInt(this, stateOffset, expect, update);
}
private final boolean compareAndSetHead(Node update) {return unsafe.compareAndSwapObject(this, headOffset, null, update);
}
private final boolean compareAndSetTail(Node expect, Node update) {return unsafe.compareAndSwapObject(this, tailOffset, expect, update);
}
private static final boolean compareAndSetWaitStatus(Node node, int expect,int update) {return unsafe.compareAndSwapInt(node, waitStatusOffset, expect, update);
}
private static final boolean compareAndSetNext(Node node, Node expect, Node update) {return unsafe.compareAndSwapObject(node, nextOffset, expect, update);
}

最后,我们利用UnsafecompareAndSetXXX即CAS方法。

观察ReentrantLock的内部类

public class ReentrantLock implements Lock, java.io.Serializable {private final Sync sync;abstract static class Sync extends AbstractQueuedSynchronizer {...}static final class NonfairSync extends Sync{...}static final class FairSync extends Sync {...}// 默认是非公平锁public ReentrantLock() {sync = new NonfairSync();}// 根据参数,设置公平或非公平public ReentrantLock(boolean fair) {sync = fair ? new FairSync() : new NonfairSync();}// 获取锁public void lock() {sync.lock();}...
}

可以看到ReentrantLock使用AQS都是通过使用子类:

  • Sync继承了AbstractQueuedSynchronizer,在Sync里,实现了tryRelease(父类中的实现是抛出异常)。
  • NonfairSyncFairSync都继承了Sync,在NonfairSyncFairSync里,会调用acquire(父类已有的实现),会实现tryAcquire(父类中的实现是抛出异常)。
  • AQS可以实现 独占锁和共享锁,但ReentrantLock只使用了独占锁部分。获取锁的方式可以分为 公平和非公平响应中断和不响应中断。本文将以 公平、不响应中断 的方式作为切入点,来分析AQS源码。

公平的、不响应中断的 独占锁的获取

//ReentrantLock.javastatic final class FairSync extends Sync {private static final long serialVersionUID = -3000897897090466540L;final void lock() {acquire(1);}/*** Fair version of tryAcquire.  Don't grant access unless* recursive call or no waiters or is first.*/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;}}
  • 获取锁的第一步便是调用acquire,里面的参数1代表state需要增加1。
    public final void acquire(int arg) {if (!tryAcquire(arg) &&acquireQueued(addWaiter(Node.EXCLUSIVE), arg))selfInterrupt();}

先大概说一下每个函数的作用,可能的调用流程:

  1. tryAcquire用来获取独占锁一次,try的意思就是只试一次,要么成功,要么失败。
  2. tryAcquire返回true时,后面的三个函数都不会执行了。
  3. tryAcquire返回false时,必将调用addWaiteracquireQueued
  4. addWaiter是AQS的实现,因为开始获取锁失败了(tryAcquire返回false),所以需要把当前线程包装成node放到等待队列中,返回代表当前线程的node。
  5. acquireQueued是AQS的实现,简单的理解就是:用一个死循环不断得去执行tryAcquire,直到获取锁。当然:
    1. 程序不会真的在死循环,一般情况下,会不断经历 阻塞和被唤醒 两种状态。
    2. 当参数node的前驱是head时,才会去tryAcquire尝试获得锁。
  6. selfInterrupt用来复原中断状态,虽然这个版本的函数不用响应中断。当acquireQueued返回真时,代表这期间函数曾经检测到过中断状态,并且将中断状态消耗掉了(Thread.interrupted()),所以需要在退出acquire之前,将中断状态重新设置上。

悄悄给你说,其实上面就已经讲完了独占锁的获取过程了,接下来让我们具体分析。

tryAcquire

前面提到,tryAcquire在ReentrantLock里,NonfairSyncFairSync分别实现了tryAcquire,而我们这里从FairSync的tryAcquire看起。

简单来说,tryAcquire的实现就是:尝试获得锁一次,成功了返回true,否则false。

        protected final boolean tryAcquire(int acquires) {final Thread current = Thread.currentThread();//获得当前同步器的stateint 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;}
  • 参数acquires代表你想让同步器的state再增加多少。函数返回值为true,代表你成功获取到了锁。返回true时,同步器的state已经增加了acquires,且Thread exclusiveOwnerThread成员被设置成了当前执行线程。
  • 首先获得同步器的state。
  • 如果进入if (c == 0)分支,说明当前state为0,当前锁已经被释放掉了,但此时CHL队列中可能有线程已经在排队了(考虑到此版本是公平锁),所以需要通过hasQueuedPredecessors判断队列中是否已经有等待线程(返回true代表有)。
    • hasQueuedPredecessors返回true,那么直接返回false,说明tryAcquire失败。
    • hasQueuedPredecessors返回false,才会尝试CAS操作设置state。如果CAS操作成功,那么说明当前线程成功抢到了锁,调用setExclusiveOwnerThread设置独占线程;如果CAS操作失败,那么直接返回false,说明此次tryAcquire失败。
  • 如果进入else if (current == getExclusiveOwnerThread())分支,说明当前state不为0,已经有线程持有锁,但考虑锁可重入,如果当前线程就是AQS的独占线程的话,那么就直接让state再加acquires;如果当前线程根本不是AQS的独占线程,那么直接返回false,说明此次tryAcquire失败。

tryAcquire的逻辑总结来说:

  • 当锁已经被释放时(state为0),先以公平的方式判断是否可以尝试获得锁(hasQueuedPredecessors的返回值),再尝试获得锁(通过CAS操作设置state为1)。
  • 当锁已经被占有时,判断一下是否是自己占有的(current == getExclusiveOwnerThread()),如果是就重入这个锁。
  • 需要注意,前者设置state使用的是CAS操作,因为此时当前线程还没有获得锁,不一定谁能竞争到,所以用CAS保证只有一个线程能设置state成功;而后者直接set,是因为当前线程已经获取锁了,此时别的线程都不能修改state,即只有当前线程在写state,所以直接set是安全的。

addWaiter

既然执行到了addWaiter,说明当前线程第一次执行tryAcquire时失败了。既然获取锁失败了,那么就需要将当前线程包装一个node,放到等待队列的队尾上去,以后锁被释放时别人就会通过这个node来唤醒自己。

    private Node addWaiter(Node mode) {Node node = new Node(Thread.currentThread(), mode);// 使用enq的快捷方法,如果CAS操作失败,才会去执行enq Node pred = tail;// 如果队列不为空if (pred != null) {node.prev = pred;if (compareAndSetTail(pred, node)) {pred.next = node;return node;}}// 执行到这里,有两种情况:// 1.队列为空。head和tail成员从来没有初始化过// 2.CAS操作失败。当执行compareAndSetTail时,tail成员已经被修改了enq(node);return node;}
  • 由于当初这么调用的addWaiter(Node.EXCLUSIVE),然后会调用下面的这版构造器。由此可见,刚放到队尾的node,它的nextWaiter肯定为null,它的waitStatus为0(默认初始化)。
        static final Node EXCLUSIVE = null;Node(Thread thread, Node mode) {     // Used by addWaiterthis.nextWaiter = mode;this.thread = thread;}
  • 函数的主要逻辑,其实跟enq函数中一样,所以称它为enq的快捷方式,区别在于enq是循环执行这段逻辑。逻辑为:当队列不为空时,CAS尝试tail成员为新创建的node,如果成功,那么将next指针修正,并返回这个node。该函数既然完成了 将当前线程所包装成的node放在队尾的使命,自然就可以返回该node了。
  • 如果执行到了enq(node),那么可能有两种情况:
    • 队列为空。head和tail成员从来没有初始化过。
    • CAS操作失败。当执行compareAndSetTail时,tail成员已经被修改了。
  • 自然,enq函数能保证 在多线程下 安全得将 该node放到队尾去,它的具体做法是 自旋+CAS。
  • 不管是提前return,还是执行完enq再return,当return时,已经是将代表当前线程的node放到队尾了。注意,返回的是,代表当前线程的node。

enq

由于addWaiter的时候并没有成功将刚创建的node放到队尾,这时需要enq出马了。

    private Node enq(final Node node) {for (;;) {Node t = tail;// 如果tail为null,说明队列为空,head肯定也为null// 进一步说明 等待队列的初始化是懒汉式的if (t == null) { if (compareAndSetHead(new Node()))tail = head;// 如果tail不为null,说明队列至少有一个dummy node,head肯定也不为null} else {node.prev = t;if (compareAndSetTail(t, node)) {t.next = node;return t;}}}}
  • 进入if (t == null)分支,tail为null,说明队列为空,head肯定也为null。然后尝试CAS设置head成员。
    • 注意,如果队列从来没有初始化过(head、tail为null),那么这个循环至少得执行两次,第一次给队列新建一个空node,第二次进if (t == null)的else分支,把参数node放在空node的后面。
    • 根据上一条可知,就算只有一个线程入队,入队完毕后队列将有两个node,第一个node称为dummy node,因为它的thread成员为null;第二个node才算是实际意义的队头,它的thread成员不为null。
    • 新建的是空node,它的所有成员都是默认值。thread成员为null,waitStatus为0。之后你会发现,队尾node的waitStatus总是0,因为默认初始化。
    • compareAndSetHead作为一个CAS操作只有一个参数,是因为它的实现是unsafe.compareAndSwapObject(this, headOffset, null, update);
    • compareAndSetHead的CAS操作也可能失败,当队列为空时,两个线程同时执行到enq
  • 进入if (t == null)的else分支,tail不为null,说明队列至少有一个dummy node,head肯定也不为null。
    • 先令node的prev指向tail,但只有CAS设置node为tail成功后,才会将tail的next指向node,才会将双向链表的指针都正确完成指向。
    • compareAndSetTail(t, node)可能失败,当多个线程都执行到了node.prev = t这里。
  • 这个循环只有在compareAndSetTail(t, node)成功时才会退出循环,这就保证了enq最终肯定能将参数node放到队尾。
  • 简单总结就是:enq利用了自旋(循环)和CAS操作,保证了node放到队尾。

enq的尾分叉 与 prev的有效性

在队列已经有node的情况下,如果同时有多个线程执行到node.prev = t这里,最终只有一个线程能够成功设置tail成员。

            } else {node.prev = t;  // 1if (compareAndSetTail(t, node)) {  // 2t.next = node;  // 3return t;}}

从上面看,发现要完成双向链表的指针指向,需要经过3步:

  1. 将参数node的前驱指向tail
  2. CAS设置参数node为tail
  3. 如果CAS成功,则修正tail的后继

因为CAS操作的保证,所有线程都能够执行第1步,但第2、3步只会有一个线程能够执行到。
在这里插入图片描述
enq的尾分叉:从上面的步骤可以看出,如果存在很多个线程都刚好执行到了node.prev = t这里,那么CAS失败的线程不能成功入队,此时它们的prev还暂时指向的旧tail。

prev的有效性:从上图第二步可以看到,此时线程1的node已经是成功放到队尾了,但此时队列却处于一个中间状态,前一个node的next还没有指向队尾呢。此时,如果另一个线程如果通过next指针遍历队列,就会漏掉最后那个node;但如果另一个线程通过tail成员的prev指针遍历队列,就不会漏掉node了。

prev的有效性也解释了AQS源码里遍历队列时,为什么常常使用tail成员和prev指针来遍历,比如你看unparkSuccessor

acquireQueued

acquireQueued函数是整个独占锁获取的精华部分,它解释了独占锁获取的整个过程。

执行到这个函数,说明:

  • 当前线程已经执行完了addWaiter方法。
  • 传入的node的thread成员就是当前线程。
  • 传入的node已经成功入队。(addWaiter的作用)

简单的说,acquireQueued是利用自旋+tryAcquire“不断”地尝试获取锁,当然实际上如果真的是在死循环来不断调tryAcquire,肯定电脑都卡死了。实际流程是:

  • 每次循环都会判断是否可以尝试获取锁(p == head),如果可以,那么尝试(tryAcquire(arg))。
    • 如果尝试获取锁成功,那么函数的使命就达到了,执行完相应收尾工作,然后返回。
  • 如果 不可以尝试 或者 尝试获取锁却失败了,那么阻塞当前线程(parkAndCheckInterrupt)。
  • 如果当前线程被唤醒了,又会重新走这个流程。被唤醒时,是从parkAndCheckInterrupt处唤醒,然后从这里继续往下执行。
    final boolean acquireQueued(final Node node, int arg) {boolean failed = true;try {boolean interrupted = false;for (;;) {final Node p = node.predecessor();// 尝试获取锁的前提是node是head的后继if (p == head && tryAcquire(arg)) {setHead(node);p.next = null; // help GCfailed = false;return interrupted;}// 执行到这里,说明// 要么不符合 尝试获取锁的前提// 要么 尝试获取锁失败了if (shouldParkAfterFailedAcquire(p, node) &&parkAndCheckInterrupt())interrupted = true;}} finally {if (failed)cancelAcquire(node);}}

为什么tryAcquire(arg)的前提是p == head
因为从enq的逻辑可知,head只会是一个dummy node,实际意义的node只会在head的后面。而node的前驱是head(final Node p = node.predecessor()),则代表node已经是队列中的第一个实际node了,排在最前面的node自然可以尝试去获取锁了。

回想整个调用过程,是最开始在acquire里调用tryAcquire就已经失败了,然而此时第一次循环时,又可能马上去调tryAcquire(说可能,是因为需要p == head成立),这会不会是一次肯定失败的tryAcquire
考虑这种场景,线程1获取了锁正在使用还没释放,此时队列为空,线程2此时也来获取锁,自然最开始在acquire里调用tryAcquire会失败,假设线程2刚开始执行acquireQueued,此时线程1释放了锁,此时线程2肯定排在head后面,那么线程2马上tryAcquire,然后就可以获取成功。

执行acquireQueued的线程是谁?
一定是node参数的thread成员,虽然执行过程中,可能会经历不断 阻塞和被唤醒 的过程。

为什么刚执行完addWaiter方法时,才把代表当前线程的node放到队尾,怎么之后一判断就会发现自己处于head的后继了?
这个问题不考虑上面的特殊场景,而考虑addWaiter时,队列中有许多node。其实这很合理,这说明从head到当前方法栈中的node之间的那些node,它们自己也会在执行acquireQueued,它们依次执行成功(指p == head && tryAcquire(arg)成功),每次执行成功相当于把head成员从队列上后移一个node,当它们都执行完毕,当前方法栈中的node自然也就是head的后继了。
注意,“之间的那些node”的最后一个node执行acquireQueued成功后(代表 最后一个node的代表线程获得锁成功,它自己成为了head),当前方法还在阻塞之中,只有当这“最后一个node”释放独占锁时,才会执行unparkSuccessor(head),当前线程才会被唤醒。关于释放独占锁,以后再具体讲。

finally块是否会执行cancelAcquire(node)
虽然号称此函数是不响应中断的函数,但不响应中断只是对于AQS的使用者来说,如果一个线程阻塞在parkAndCheckInterrupt这里,别的线程来中断它,它是会马上唤醒的,然后继续这个循环。不过想要退出这个函数,只有通过return interrupted,而前一句就是failed = false,所以finally块里,是永远不会去执行cancelAcquire(node)的。

如下图,演示了多个线程依次获得独占锁的过程。
在这里插入图片描述

                if (p == head && tryAcquire(arg)) {setHead(node);p.next = null; // help GCfailed = false;return interrupted;}private void setHead(Node node) {head = node;node.thread = null;node.prev = null;}

从逻辑中可见,如果当前线程获取锁成功,代表当前线程的node会新设置自己为head,然后将其弄成dummy node,即把node的thread成员清空,但这个被清空的thread成员已经在tryAcquire里将这个thread设置为了exclusiveOwnerThread。

  • 可以这么理解,head之所以它的thread成员为null,是因为它的thread成员被放在了exclusiveOwnerThread成员里。
  • 使用setHead而非compareAndSetHead,因为此时不需要CAS操作,执行到这里说明当前线程已经获得了独占锁(tryAcquire成功),所以别的线程是不可能同时执行这部分代码的。

shouldParkAfterFailedAcquire

我们先把函数名分成两部分:

shouldPark:指的是 该函数的返回值影响是否可以执行parkAndCheckInterrupt函数。因为shouldParkAfterFailedAcquire(p, node) && parkAndCheckInterrupt()这么写,只有当该函数返回true时,才会去执行parkAndCheckInterrupt。注意,parkAndCheckInterrupt函数执行后,当前线程就会被挂起了,也就是我们所说的阻塞。

AfterFailedAcquire:指的是 获取锁失败了才会执行该函数。其实具体指两种情况:1. p == head为false,即当前线程的node的前驱不是head 2. 虽然 p == head为true,但tryAcquire返回false了,即当前线程虽然已经排到等待队列的最前面,但获取锁还是失败了。

回想之前讲过的函数,发现它们居然都没有使用过waitStatus这个属性,而现在就可以派上用场了。

static final int CANCELLED =  1;
static final int SIGNAL    = -1;
static final int CONDITION = -2;
static final int PROPAGATE = -3;

node一共有四种状态,但在独占锁的获取和释放过程中,我们只可能将node的状态变成CANCELLEDSIGNAL,而shouldParkAfterFailedAcquire函数就会把一个node的状态变成SIGNAL。注意,一个node新建的时候,它的waitStatus是默认初始化为0的。

  • CANCELLED,一个node的状态是CANCELLED,说明这个node的代表线程已经取消等待了。
  • SIGNAL,一个node的状态是SIGNAL,说明这个node的后继node的代表线程已经阻塞或马上阻塞(shouldParkAfterFailedAcquire设置前驱为SIGNAL后,下一次的acquireQueued循环可能就会阻塞了,所以说“已经阻塞或马上阻塞”),并且当前node成为head并释放锁时,会根据SIGNAL来唤醒后继node。即SIGNAL是唤醒后继节点的标志。
  • 有趣的是,CANCELLED状态与当前node关联,SIGNAL状态与后继node关联。

本函数,简单的讲就是,跳过无效前驱,把node的有效前驱(有效是指node不是CANCELLED的)找到,并且将有效前驱的状态设置为SIGNAL,之后便返回true代表马上可以阻塞了。

    private static boolean shouldParkAfterFailedAcquire(Node pred, Node node) {int ws = pred.waitStatus;if (ws == Node.SIGNAL)/** 前驱节点已经设置了SIGNAL,闹钟已经设好,现在我可以安心睡觉(阻塞)了。* 如果前驱变成了head,并且head的代表线程exclusiveOwnerThread释放了锁,* 就会来根据这个SIGNAL来唤醒自己*/return true;if (ws > 0) {/** 发现传入的前驱的状态大于0,即CANCELLED。说明前驱节点已经因为超时或响应了中断,* 而取消了自己。所以需要跨越掉这些CANCELLED节点,直到找到一个<=0的节点*/do {node.prev = pred = pred.prev;} while (pred.waitStatus > 0);pred.next = node;} else {/** 进入这个分支,ws只能是0或PROPAGATE。* CAS设置ws为SIGNAL*/compareAndSetWaitStatus(pred, ws, Node.SIGNAL);}return false;}
  • 如果前驱节点的状态为SIGNAL,说明闹钟标志已设好,返回true表示设置完毕。
  • 如果前驱节点的状态为CANCELLED,说明前驱节点本身不再等待了,需要跨越这些节点,然后找到一个有效节点,再把node和这个有效节点的前驱后继连接好。
  • 如果是其他情况,那么CAS尝试设置前驱节点为SIGNAL

由于shouldParkAfterFailedAcquire函数在acquireQueued的调用中处于一个死循环中,且因为shouldParkAfterFailedAcquire函数若返回false,且考虑当前线程一直不能获取到锁的情况,那么此函数必将至少执行两次才能阻塞自己。

  • shouldParkAfterFailedAcquire只有在检测到前驱的状态为SIGNAL才能返回true,只有true才会执行到parkAndCheckInterrupt
  • shouldParkAfterFailedAcquire返回false后,进入下一次循环,当前线程又会再次尝试获取锁(p == head && tryAcquire(arg))。或者说,每次执行shouldParkAfterFailedAcquire,都说明当前循环 尝试过获取锁了,但失败了。
  • 如果刚开始前驱的状态为0,那么需要第一次执行compareAndSetWaitStatus(pred, ws, Node.SIGNAL)返回false并进入下一次循环,第二次才能进入if (ws == Node.SIGNAL)分支,所以说 至少执行两次。
  • 死循环保证了最终一定能设置前驱为SIGNAL成功的。(考虑当前线程一直不能获取到锁)

parkAndCheckInterrupt

既然shouldParkAfterFailedAcquire已经返回了true,那么我现在可以执行parkAndCheckInterrupt了。

    private final boolean parkAndCheckInterrupt() {LockSupport.park(this);  //阻塞当前线程return Thread.interrupted();}

调用完LockSupport.park(this),当前线程就阻塞在这里,直到有别的线程unpark了当前线程,或者中断了当前线程。而返回的Thread.interrupted()代表当前线程在阻塞的过程中,有没有被别的线程中断过,如果有,则返回true。注意,Thread.interrupted()会消耗掉中断的状态,即第一次执行能返回true,但紧接着第二次执行就只会返回false了。

  • 如果是别的线程unpark了当前线程,那么调用Thread.interrupted()返回false。
  • 如果是别的线程中断了当前线程,那么调用Thread.interrupted()返回true。

回到acquireQueued的逻辑中,发现一旦当前线程被中断过一次,那么parkAndCheckInterrupt就返回了true,那么执行interrupted = trueinterrupted局部变量就一定是true的了。

    final boolean acquireQueued(final Node node, int arg) {boolean failed = true;try {boolean interrupted = false;for (;;) {final Node p = node.predecessor();if (p == head && tryAcquire(arg)) {// 获取锁成功后setHead(node);p.next = null; // help GCfailed = false;return interrupted;}if (shouldParkAfterFailedAcquire(p, node) &&parkAndCheckInterrupt())  //这里返回了true,说明上一行也返回了true才会执行到这里interrupted = true;  //这里设置后,会被永久保留}} finally {if (failed)cancelAcquire(node);}}

再等到当前线程获取锁成功后,那么acquireQueued返回的就一定是true了。再回到acquire的逻辑,发现需要进入if分支,再执行selfInterrupt()将中断状态补上,这样下一次Thread.interrupted()就能返回true了。为的就是在 回到用户代码之前,把中断状态补上,万一用户需要中断状态呢。

    public final void acquire(int arg) {if (!tryAcquire(arg) &&acquireQueued(addWaiter(Node.EXCLUSIVE), arg))  //acquireQueued返回了trueselfInterrupt(); //中断状态补上}

不公平的、不响应中断的 独占锁的获取

其实不公平锁与公平锁之间的差别只会体现在AQS子类的重写方法中,所以我们直接看子类实现就好。使用不公平锁对ReentrantLock来说,还是直接调用ReentrantLock.lock(),没有区别。要想使用非公平锁,必须在构造ReentrantLock时指定好。

观察ReentrantLock的内部类

//ReentrantLock.javaabstract static class Sync extends AbstractQueuedSynchronizer {...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) // overflowthrow new Error("Maximum lock count exceeded");setState(nextc);return true;}return false;}...}static final class NonfairSync extends Sync {private static final long serialVersionUID = 7316153563782823691L;final void lock() {// if分支里的逻辑只是一次快速尝试// 它和nonfairTryAcquire里的部分逻辑是一样的if (compareAndSetState(0, 1))setExclusiveOwnerThread(Thread.currentThread());elseacquire(1);}protected final boolean tryAcquire(int acquires) {// 将nonfairTryAcquire的逻辑直接放在这里,就把公平锁看起来一样了return nonfairTryAcquire(acquires);}}
  • 与公平锁相比,非公平锁的lock实现略有不同。公平锁的lock实现是直接调用acquire(1),而非公平锁的lock实现会先尝试CAS修改state,如果能够将state从0改成1,那么说明当前线程获取锁,既然获取锁,那么便直接插队setExclusiveOwnerThread(Thread.currentThread())。如果CAS操作失败,再走正常流程,调用父类函数acquire(1)
  • 再看子类实现nonfairTryAcquire,发现和公平锁的实现tryAcquire几乎一模一样,除了公平锁需要多判断一下hasQueuedPredecessors的返回值,也就是需要判断队列是否等待线程。

其实非公平锁的原理就是:不管等待队列中是否有等待线程,直接竞争获取state,要是获取成功了,就直接设置当前线程为exclusiveOwnerThread成员了。这不就是,插了所有等待线程的队嘛。也就是说,非公平锁它可以和队列中的head后继的代表线程同时竞争锁。

    public final void acquire(int arg) {if (!tryAcquire(arg) &&  // 非公平锁插队的机会,只有这里tryAcquire的时候acquireQueued(addWaiter(Node.EXCLUSIVE), arg))selfInterrupt();}

但是 非公平锁插队的机会只有在acquire里面第一次执行tryAcquire的时候,一旦这里tryAcquire获取锁失败了,就会进入acquireQueued的死循环,在循环之前会将当前线程包装成node放到队尾去,之后在循环中的每次循环,想要执行获取锁的动作(tryAcquire(arg))必须自己是head的后继才可以(p == head)。

总结:

  • 非公平锁插队的机会只有,acquire方法里第一次执行tryAcquire的时候,如果这次插队失败,那么它也不可能插队成功了。
  • 公平锁和非公平锁,在进入acquireQueued之后,使用起来没有任何区别。

响应中断的 独占锁的获取

使用响应中断的锁对ReentrantLock来说,是调用ReentrantLock.lockInterruptibly()。从下面函数中,可以看到函数都会抛出InterruptedException异常,这是我们能看到的第一处不同。

//ReentrantLock.javapublic void lockInterruptibly() throws InterruptedException {sync.acquireInterruptibly(1);}
//AbstractQueuedSynchronizer.javapublic final void acquireInterruptibly(int arg)throws InterruptedException {if (Thread.interrupted())throw new InterruptedException();if (!tryAcquire(arg))doAcquireInterruptibly(arg);}

acquireInterruptibly这个方法与 不响应中断的acquire方法 对应。同样的,进入这个方法后,会第一次进行tryAcquire尝试。但不同的,此acquireInterruptibly函数中,会去检测Thread.interrupted(),并抛出异常。

但注意,对于acquireInterruptibly这个方法而言,既可以是公平的,也可以是不公平的,这完全取决于tryAcquire的实现(即取决于ReentrantLock当初是怎么构造的)。

    private void doAcquireInterruptibly(int arg)throws InterruptedException {final Node node = addWaiter(Node.EXCLUSIVE);boolean failed = true;try {for (;;) {final Node p = node.predecessor();if (p == head && tryAcquire(arg)) {setHead(node);p.next = null; // help GCfailed = false;return;}if (shouldParkAfterFailedAcquire(p, node) &&parkAndCheckInterrupt())throw new InterruptedException();}} finally {if (failed)cancelAcquire(node);}}

doAcquireInterruptibly方法 的相对应的方法为acquireQueued方法。观察两个方法的差别很少:

  • doAcquireInterruptibly没有返回值,而acquireQueued方法有返回值,代表当前线程是否被中断过。
    • acquireQueued方法需要有返回值,因为函数调用返回上层后,需要根据返回值来判断是否需要重新设置中断状态,在返回用户代码之前。
    • doAcquireInterruptibly不需要返回值,因为该函数中如果检测到了中断状态,就直接抛出异常就好了。
  • doAcquireInterruptibly方法的finally块是可能会执行到cancelAcquire(node)的,而acquireQueued方法不可能去执行cancelAcquire(node)的。
    • doAcquireInterruptibly方法中,如果线程阻塞在parkAndCheckInterrupt这里后,别的线程来中断阻塞线程,阻塞线程会被唤醒,然后抛出异常。本来抛出异常该函数就马上结束掉的,但由于有finally块,所以在结束掉之前会去执行finally块,并且由于failed为true,则会执行cancelAcquire(node)

回忆起node有一种CANCELLED状态,看来就是为cancelAcquire(node)准备的了。

    private void cancelAcquire(Node node) {// 避免空指针异常if (node == null)return;node.thread = null;Node pred = node.prev;while (pred.waitStatus > 0)  // 循环用来跳过无效前驱node.prev = pred = pred.prev;// 执行完循环,pred会指向node的有效前驱。// 当然,如果node的前驱就是有效的。那么就不需要跳过了。// pred的后继无论如何都需要取消,因为即使前面循环没有执行,// 现在pred的后继(肯定是参数node)也是一个马上取消掉的node。// 之后有些CAS操作会尝试修改pred的后继,如果CAS失败,那么说明有别的线程在做// 取消动作或通知动作,所以当前线程也不需要更多的动作了。Node predNext = pred.next;// 这里直接使用赋值操作,而不是CAS操作。// 如果别的线程在执行这步之后,别的线程将会跳过这个node。// 如果别的线程在执行这步之前,别的线程还是会将这个node当作有效节点。node.waitStatus = Node.CANCELLED;// 如果node是队尾,那简单。直接设置pred为队尾,然后设置pred的后继为nullif (node == tail && compareAndSetTail(node, pred)) {compareAndSetNext(pred, predNext, null);// 如果node不是队尾,node则有后继。} else {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 {unparkSuccessor(node);}node.next = node; // help GC}}

如果node是队尾,那说明node后面没有节点,也就不存在节点需要去唤醒了。

分析node不是队尾的情况,既然不是队尾,说明node后面有节点。如下图所示。
这里面又有分支,先直接看进入分支要做什么,再来分析进入分支的条件:

  • 在if分支里,去做compareAndSetNext(pred, predNext, next),即修复pred的后继,完善双向链表的指针。但这样做有一个前提,就是需要pred的状态已经是SIGNAL的了。
  • 在else分支里,去做unparkSuccessor(node),去唤醒node后继。

在这里插入图片描述
从上图可以看到,实际意义上,pred的后继已经变成了node后继了。

  • pred != head不成立,那么说明pred就是head,执行else分支。node的后继运气爆棚,因为node自己取消掉了,node的后继便成为了等待队列中第一个线程(即成为了head后继),自然需要去唤醒它了(unparkSuccessor(node))。
  • pred != head成立,但(ws = pred.waitStatus) == Node.SIGNAL || (ws <= 0 && compareAndSetWaitStatus(pred, ws, Node.SIGNAL))不成立,执行else分支。
    • 第一个条件成立,说明pred并不是head。
    • 第二个条件不成立,里面是||,说明是两个子条件都不成立。有下面情况:
      • 如果pred的状态是CANCELLED。这似乎有点矛盾,因为之前的for循环已经判断过pred的状态是 <= 0的了,但你要知道多线程环境下,什么都可能发生。很可能从for循环执行到这里的时候,pred又被取消掉了。考虑到pred如果是head后继的话,那么node后继就一下子成为了队列中第一个线程了,所以还是有必要执行unparkSuccessor(node)
      • 如果pred的状态是 <= 0但还不是SIGNAL,但CAS设置pred的状态为SIGNAL却失败了。SIGNAL是作为后继节点被唤醒的标志而存在的,现在居然没有设置成功,所以很有必要执行unparkSuccessor(node)
  • pred != head成立,(ws = pred.waitStatus) == Node.SIGNAL || (ws <= 0 && compareAndSetWaitStatus(pred, ws, Node.SIGNAL))也成立,但pred.thread != null不成立,执行else分支。
    • 第一个条件成立,说明pred并不是head。
    • 第二个条件成立,里面是||,说明是两个子条件要么前真,要么前假后真。
      • 如果是前真,那么说明pred的状态已经是SIGNAL。
      • 如果是前假后真,那么说明pred的状态是0或PROPAGATE,且接下来的CAS操作也成功了,即成功设置为SIGNAL。
    • 第三个条件不成立,说明pred变成了一个dummy node了。要么pred是变成head了,要么pred突然被取消了(执行了node.thread = null)。这两种情况,前者必须执行unparkSuccessor(node),后者只是有必要执行。
  • pred != head成立,(ws = pred.waitStatus) == Node.SIGNAL || (ws <= 0 && compareAndSetWaitStatus(pred, ws, Node.SIGNAL))也成立,且pred.thread != null也成立,只有这里才执行if分支。说明闹钟设置成功,并且设置的node也不是个空节点,那么只需要将pred与node后继相连即可(compareAndSetNext(pred, predNext, next))。

总结一下cancelAcquire

  • 如果闹钟设置成功,且闹钟都在node不是一个dummy node,那么将pred与node后继相连,让node后继继续安心睡觉。
  • 如果发现node后继已经是排队的第一个了、发现闹钟没有设置成功、发现闹钟设置成功但闹钟所在节点变空节点,都需要换线node后继。

超时的 独占锁的获取

使用超时的锁对ReentrantLock来说,是调用public boolean tryLock(long timeout, TimeUnit unit)。从下面函数中,可以看到函数都会抛出InterruptedException异常,这是我们能看到的第一处不同。

//ReentrantLock.javapublic boolean tryLock(long timeout, TimeUnit unit)throws InterruptedException {return sync.tryAcquireNanos(1, unit.toNanos(timeout));//第二个实参,换算得到nano}
//AbstractQueuedSynchronizer.javapublic final boolean tryAcquireNanos(int arg, long nanosTimeout)throws InterruptedException {if (Thread.interrupted())throw new InterruptedException();return tryAcquire(arg) ||doAcquireNanos(arg, nanosTimeout);}

tryAcquireNanos这个方法与 不响应中断的acquire方法 对应。同样的,进入这个方法后,会第一次进行tryAcquire尝试。但不同的,此tryAcquireNanos函数中,会先去检测Thread.interrupted(),并抛出异常。

但注意,对于tryAcquireNanos这个方法而言,既可以是公平的,也可以是不公平的,这完全取决于tryAcquire的实现(即取决于ReentrantLock当初是怎么构造的)。

    private boolean doAcquireNanos(int arg, long nanosTimeout)throws InterruptedException {if (nanosTimeout <= 0L)//如果时间小于0,直接返回失败return false;final long deadline = System.nanoTime() + nanosTimeout;//算出“死期”,当死期到了就直接返回失败了final Node node = addWaiter(Node.EXCLUSIVE);boolean failed = true;try {for (;;) {final Node p = node.predecessor();if (p == head && tryAcquire(arg)) {setHead(node);p.next = null; // help GCfailed = false;return true;}// 看看你的年龄是否到达了死期nanosTimeout = deadline - System.nanoTime();if (nanosTimeout <= 0L)//小于0,说明死期到了return false;if (shouldParkAfterFailedAcquire(p, node) &&nanosTimeout > spinForTimeoutThreshold)//剩余寿命得大于1msLockSupport.parkNanos(this, nanosTimeout);if (Thread.interrupted())throw new InterruptedException();}} finally {if (failed)cancelAcquire(node);}}

doAcquireNanos方法 与不响应中断的acquireQueued方法、响应中断的doAcquireInterruptibly方法进行对比,发现差别很少,简单的我用注释说明了。

  • 每次循环都会检查时间是否到达deadline。
  • 当剩余时间小于spinForTimeoutThreshold时,则不能调用LockSupport.parkNanos,因为时间太短,反而无法精确控制阻塞时间,所以不如在剩余的时间里一直循环。
  • LockSupport.parkNanos除了会因为别人的park而唤醒,也会因为别人的中断而唤醒,当然最重要的,时间到了,它自己会唤醒。
  • 不管哪种情况,被唤醒后,都会检查中断状态。每个循环都会检查一次。

只一次尝试的 非公平的 独占锁的获取

只一次尝试的、非公平的独占锁获得对ReentrantLock来说,是调用ReentrantLock.tryLock()。而nonfairTryAcquire方法就是之前讲过的非公平锁的获取方式。

//ReentrantLock.java
public boolean tryLock() {return sync.nonfairTryAcquire(1);}abstract static class Sync extends AbstractQueuedSynchronizer {...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) // overflowthrow new Error("Maximum lock count exceeded");setState(nextc);return true;}return false;}...}

总结

  • 对于独占锁,AQS的state代表代表锁的状态,为0代表没有线程持有锁,非0代表有线程持有了锁。
  • 获得了锁的线程会将自己设置为exclusiveOwnerThread
  • addWaiter负责new出一个包装当前线程的node,enq负责将node添加到队尾,如果队尾为空,它还负责添加dummy node。
  • acquireQueued是整个获取锁过程的核心,这里是指它的那个死循环。一般情况下,每次循环做的事就是:尝试获取锁,获取锁失败,阻塞,被唤醒。如果某一次循环获取锁成功,那么之后会返回到用户代码调用处。
  • shouldParkAfterFailedAcquire负责自身的前驱节点的状态设置为SIGNAL,这样,当前驱节点释放锁时,会根据SIGNAL来唤醒自身。
  • parkAndCheckInterrupt最简单,用来阻塞当前线程。它也会去检查中断状态。

这篇关于AQS深入理解系列(一) 独占锁的获取过程的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/574697

相关文章

浅析Spring Security认证过程

类图 为了方便理解Spring Security认证流程,特意画了如下的类图,包含相关的核心认证类 概述 核心验证器 AuthenticationManager 该对象提供了认证方法的入口,接收一个Authentiaton对象作为参数; public interface AuthenticationManager {Authentication authenticate(Authenti

Spring Security 从入门到进阶系列教程

Spring Security 入门系列 《保护 Web 应用的安全》 《Spring-Security-入门(一):登录与退出》 《Spring-Security-入门(二):基于数据库验证》 《Spring-Security-入门(三):密码加密》 《Spring-Security-入门(四):自定义-Filter》 《Spring-Security-入门(五):在 Sprin

作业提交过程之HDFSMapReduce

作业提交全过程详解 (1)作业提交 第1步:Client调用job.waitForCompletion方法,向整个集群提交MapReduce作业。 第2步:Client向RM申请一个作业id。 第3步:RM给Client返回该job资源的提交路径和作业id。 第4步:Client提交jar包、切片信息和配置文件到指定的资源提交路径。 第5步:Client提交完资源后,向RM申请运行MrAp

【前端学习】AntV G6-08 深入图形与图形分组、自定义节点、节点动画(下)

【课程链接】 AntV G6:深入图形与图形分组、自定义节点、节点动画(下)_哔哩哔哩_bilibili 本章十吾老师讲解了一个复杂的自定义节点中,应该怎样去计算和绘制图形,如何给一个图形制作不间断的动画,以及在鼠标事件之后产生动画。(有点难,需要好好理解) <!DOCTYPE html><html><head><meta charset="UTF-8"><title>06

认识、理解、分类——acm之搜索

普通搜索方法有两种:1、广度优先搜索;2、深度优先搜索; 更多搜索方法: 3、双向广度优先搜索; 4、启发式搜索(包括A*算法等); 搜索通常会用到的知识点:状态压缩(位压缩,利用hash思想压缩)。

深入探索协同过滤:从原理到推荐模块案例

文章目录 前言一、协同过滤1. 基于用户的协同过滤(UserCF)2. 基于物品的协同过滤(ItemCF)3. 相似度计算方法 二、相似度计算方法1. 欧氏距离2. 皮尔逊相关系数3. 杰卡德相似系数4. 余弦相似度 三、推荐模块案例1.基于文章的协同过滤推荐功能2.基于用户的协同过滤推荐功能 前言     在信息过载的时代,推荐系统成为连接用户与内容的桥梁。本文聚焦于

科研绘图系列:R语言扩展物种堆积图(Extended Stacked Barplot)

介绍 R语言的扩展物种堆积图是一种数据可视化工具,它不仅展示了物种的堆积结果,还整合了不同样本分组之间的差异性分析结果。这种图形表示方法能够直观地比较不同物种在各个分组中的显著性差异,为研究者提供了一种有效的数据解读方式。 加载R包 knitr::opts_chunk$set(warning = F, message = F)library(tidyverse)library(phyl

【机器学习】高斯过程的基本概念和应用领域以及在python中的实例

引言 高斯过程(Gaussian Process,简称GP)是一种概率模型,用于描述一组随机变量的联合概率分布,其中任何一个有限维度的子集都具有高斯分布 文章目录 引言一、高斯过程1.1 基本定义1.1.1 随机过程1.1.2 高斯分布 1.2 高斯过程的特性1.2.1 联合高斯性1.2.2 均值函数1.2.3 协方差函数(或核函数) 1.3 核函数1.4 高斯过程回归(Gauss

【生成模型系列(初级)】嵌入(Embedding)方程——自然语言处理的数学灵魂【通俗理解】

【通俗理解】嵌入(Embedding)方程——自然语言处理的数学灵魂 关键词提炼 #嵌入方程 #自然语言处理 #词向量 #机器学习 #神经网络 #向量空间模型 #Siri #Google翻译 #AlexNet 第一节:嵌入方程的类比与核心概念【尽可能通俗】 嵌入方程可以被看作是自然语言处理中的“翻译机”,它将文本中的单词或短语转换成计算机能够理解的数学形式,即向量。 正如翻译机将一种语言

【C++高阶】C++类型转换全攻略:深入理解并高效应用

📝个人主页🌹:Eternity._ ⏩收录专栏⏪:C++ “ 登神长阶 ” 🤡往期回顾🤡:C++ 智能指针 🌹🌹期待您的关注 🌹🌹 ❀C++的类型转换 📒1. C语言中的类型转换📚2. C++强制类型转换⛰️static_cast🌞reinterpret_cast⭐const_cast🍁dynamic_cast 📜3. C++强制类型转换的原因📝