Heim  >  Artikel  >  Java  >  Wie gibt die Java-Synchronizer-AQS-Architektur Sperren frei und synchronisiert Warteschlangen?

Wie gibt die Java-Synchronizer-AQS-Architektur Sperren frei und synchronisiert Warteschlangen?

WBOY
WBOYnach vorne
2023-05-11 17:16:151517Durchsuche

    Einführung

    AQS hat zu viel Inhalt, deshalb haben wir es in zwei Kapitel aufgeteilt der AQS-Studenten in diesem Kapitel können zurückblicken. In der ersten Hälfte des Kapitels werden viele grundlegende Konzepte von Sperren, grundlegende Eigenschaften, das Erhalten von Sperren usw. besprochen. In diesem Kapitel sprechen wir hauptsächlich über das Aufheben von Sperren und die Synchronisierung Warteschlangen.

    1. Lösen Sie die Sperre

    Der Auslösezeitpunkt für die Freigabe der Sperre ist unsere häufig verwendete Lock.unLock()-Methode. Der Zweck besteht darin, dem Thread den Zugriff auf Ressourcen freizugeben (Siehe die violette Route des Gesamtprozessarchitekturdiagramms).

    Die Freigabe von Sperren ist ebenfalls in zwei Kategorien unterteilt: Die eine ist die Freigabe exklusiver Sperren und die andere die Freigabe gemeinsamer Sperren.

    1.1. Die Freigabe der exklusiven Sperre ist relativ einfach. Beginnen Sie am Anfang der Warteschlange und suchen Sie den nächsten Knoten ist Wenn es leer ist, beginnt es am Ende und findet den Knoten, dessen Status nicht aufgehoben ist, und gibt dann den Knoten frei. Der Quellcode lautet wie folgt:

    // unlock 的基础方法
    public final boolean release(int arg) {
        // tryRelease 交给实现类去实现,一般就是用当前同步器状态减去 arg,如果返回 true 说明成功释放锁。
        if (tryRelease(arg)) {
            Node h = head;
            // 头节点不为空,并且非初始化状态
            if (h != null && h.waitStatus != 0)
                // 从头开始唤醒等待锁的节点
                unparkSuccessor(h);
            return true;
        }
        return false;
    }
    // 很有意思的方法,当线程释放锁成功后,从 node 开始唤醒同步队列中的节点
    // 通过唤醒机制,保证线程不会一直在同步队列中阻塞等待
    private void unparkSuccessor(Node node) {
        // node 节点是当前释放锁的节点,也是同步队列的头节点
        int ws = node.waitStatus;
        // 如果节点已经被取消了,把节点的状态置为初始化
        if (ws < 0)
            compareAndSetWaitStatus(node, ws, 0);
        // 拿出 node 节点的后面一个节点
        Node s = node.next;
        // s 为空,表示 node 的后一个节点为空
        // s.waitStatus 大于0,代表 s 节点已经被取消了
        // 遇到以上这两种情况,就从队尾开始,向前遍历,找到第一个 waitStatus 字段不是被取消的
        if (s == null || s.waitStatus > 0) {
            s = null;
            // 这里从尾迭代,而不是从头开始迭代是有原因的。
            // 主要是因为节点被阻塞的时候,是在 acquireQueued 方法里面被阻塞的,唤醒时也一定会在 acquireQueued 方法里面被唤醒,唤醒之后的条件是,判断当前节点的前置节点是否是头节点,这里是判断当前节点的前置节点,所以这里必须使用从尾到头的迭代顺序才行,目的就是为了过滤掉无效的前置节点,不然节点被唤醒时,发现其前置节点还是无效节点,就又会陷入阻塞。
            for (Node t = tail; t != null && t != node; t = t.prev)
                // t.waitStatus <= 0 说明 t 没有被取消,肯定还在等待被唤醒
                if (t.waitStatus <= 0)
                    s = t;
        }
        // 唤醒以上代码找到的线程
        if (s != null)
            LockSupport.unpark(s.thread);
    }

    1.2, geben Sie die gemeinsame Sperre frei releaseShared

    release shared Die Sperrmethode ist releaseShared, die hauptsächlich in zwei Schritte unterteilt ist:

    tryReleaseShared versucht, die aktuelle gemeinsame Sperre aufzuheben, gibt false zurück, wenn dies fehlschlägt, und geht zu 2 bei Erfolg;

    weckt den nachfolgenden Blockierungsknoten des aktuellen Knotens. Wir haben diese Methode schon einmal gesehen. Wenn ein Thread eine gemeinsame Sperre erhält, wird er den Knoten dahinter aufwecken ist: doReleaseShared.

    Werfen wir einen Blick auf den Quellcode von releaseShared:

    // 共享模式下,释放当前线程的共享锁
    public final boolean releaseShared(int arg) {
        if (tryReleaseShared(arg)) {
            // 这个方法就是线程在获得锁时,唤醒后续节点时调用的方法
            doReleaseShared();
            return true;
        }
        return false;
    }

    2. Wichtige Methoden der bedingten Warteschlange

    Bevor wir uns die Methoden der bedingten Warteschlange ansehen Warteschlange, wir müssen zunächst verstehen, warum wir eine bedingte Warteschlange benötigen, wenn wir eine Synchronisationswarteschlange haben?

    Hauptsächlich, weil nicht alle Szenarien von einer Synchronisationswarteschlange verarbeitet werden können. Wenn Sie auf ein Szenario stoßen, in dem Sperre + Warteschlange kombiniert sind, ist Sperre + Bedingung erforderlich, um zu bestimmen, welche Threads eine Sperre erhalten. Welche Threads müssen in der Synchronisationswarteschlange in die Warteschlange gestellt und blockiert werden? Wenn mehrere Threads, die die Sperre erhalten, auf eine volle oder leere Warteschlange stoßen, können Sie diese Threads mithilfe von Condition verwalten, diese Threads blockieren und warten lassen und dann zum entsprechenden Zeitpunkt warten . , wird normal geweckt.

    Das Szenario, in dem Synchronisationswarteschlange + bedingte Warteschlange zusammen verwendet werden, wird am häufigsten im Szenario von Sperre + Warteschlange verwendet.

    Daher ist auch die bedingte Warteschlange ein unverzichtbarer Bestandteil.

    Als nächstes werfen wir einen Blick auf einige der wichtigeren Methoden der Bedingungswarteschlange. Die folgenden Methoden befinden sich alle in der internen Klasse ConditionObject.

    2.1, in die Warteschlange stellen und auf Warten warten

    // 线程入条件队列
    public final void await() throws InterruptedException {
        if (Thread.interrupted())
            throw new InterruptedException();
        // 加入到条件队列的队尾
        Node node = addConditionWaiter();
        // 标记位置 A
        // 加入条件队列后,会释放 lock 时申请的资源,唤醒同步队列队列头的节点
        // 自己马上就要阻塞了,必须马上释放之前 lock 的资源,不然自己不被唤醒的话,别的线程永远得不到该共享资源了
        int savedState = fullyRelease(node);
        int interruptMode = 0;
        // 确认node不在同步队列上,再阻塞,如果 node 在同步队列上,是不能够上锁的
        // 目前想到的只有两种可能:
        // 1:node 刚被加入到条件队列中,立马就被其他线程 signal 转移到同步队列中去了
        // 2:线程之前在条件队列中沉睡,被唤醒后加入到同步队列中去
        while (!isOnSyncQueue(node)) {
            // this = AbstractQueuedSynchronizer$ConditionObject
            // 阻塞在条件队列上
            LockSupport.park(this);
            if ((interruptMode = checkInterruptWhileWaiting(node)) != 0)
                break;
        }
        // 标记位置 B
        // 其他线程通过 signal 已经把 node 从条件队列中转移到同步队列中的数据结构中去了
        // 所以这里节点苏醒了,直接尝试 acquireQueued
        if (acquireQueued(node, savedState) && interruptMode != THROW_IE)
            interruptMode = REINTERRUPT;
        if (node.nextWaiter != null) // clean up if cancelled
            // 如果状态不是CONDITION,就会自动删除
            unlinkCancelledWaiters();
        if (interruptMode != 0)
            reportInterruptAfterWait(interruptMode);
    }

    Die Wait-Methode erfordert mehrere Punkte, die besondere Aufmerksamkeit erfordern:

    Der obige Code markiert Position A, die Der Knoten bereitet sich vor, bevor er in die Bedingungswarteschlange eintritt. Andernfalls können andere Threads die Sperre nicht erhalten, wenn Sie in die Bedingungswarteschlange gelangen Der Knoten wird durch die Methode „Condition.signal“ oder „signalAll“ aktiviert. Zu diesem Zeitpunkt wurde der Knoten erfolgreich in die Synchronisierungswarteschlange übertragen (blauer Prozess im Gesamtarchitekturdiagramm), sodass die Methode „acquireQueued“ direkt ausgeführt werden kann Verwenden Sie Waiter, um den Knoten in der bedingten Warteschlange zu benennen. Wenn Sie Waiter in der bedingten Warteschlange sehen, handelt es sich tatsächlich um Node.

    await Es gibt zwei wichtige Methoden in der Await-Methode: addConditionWaiter und unlinkCancelledWaiters. Schauen wir uns sie einzeln an.

    2.1.1, addConditionWaiter

    addConditionWaiter-Methode stellt hauptsächlich Knoten in die Bedingungswarteschlange ein:
    // 增加新的 waiter 到队列中,返回新添加的 waiter
    // 如果尾节点状态不是 CONDITION 状态,删除条件队列中所有状态不是 CONDITION 的节点
    // 如果队列为空,新增节点作为队列头节点,否则追加到尾节点上
    private Node addConditionWaiter() {
        Node t = lastWaiter;
        // If lastWaiter is cancelled, clean out.
        // 如果尾部的 waiter 不是 CONDITION 状态了,删除
        if (t != null && t.waitStatus != Node.CONDITION) {
            unlinkCancelledWaiters();
            t = lastWaiter;
        }
        // 新建条件队列 node
        Node node = new Node(Thread.currentThread(), Node.CONDITION);
        // 队列是空的,直接放到队列头
        if (t == null)
            firstWaiter = node;
        // 队列不为空,直接到队列尾部
        else
            t.nextWaiter = node;
        lastWaiter = node;
        return node;
    }

    Das Ganze Der Prozess ist relativ einfach und wird an das Ende der Warteschlange angehängt. Es gibt eine wichtige Methode namens unlinkCancelledWaiters. Diese Methode löscht alle Knoten in der bedingten Warteschlange, deren Status nicht CONDITION ist Methode wie folgt:

    2.1.2. unlinkCancelledWaiters

    // 会检查尾部的 waiter 是不是已经不是CONDITION状态了
    // 如果不是,删除这些 waiter
    private void unlinkCancelledWaiters() {
        Node t = firstWaiter;
        // trail 表示上一个状态,这个字段作用非常大,可以把状态都是 CONDITION 的 node 串联起来,即使 node 之间有其他节点都可以
        Node trail = null;
        while (t != null) {
            Node next = t.nextWaiter;
            // 当前node的状态不是CONDITION,删除自己
            if (t.waitStatus != Node.CONDITION) {
                //删除当前node
                t.nextWaiter = null;
                // 如果 trail 是空的,咱们循环又是从头开始的,说明从头到当前节点的状态都不是 CONDITION
                // 都已经被删除了,所以移动队列头节点到当前节点的下一个节点
                if (trail == null)
                    firstWaiter = next;
                // 如果找到上次状态是CONDITION的节点的话,先把当前节点删掉,然后把自己挂到上一个状态是 CONDITION 的节点上
                else
                    trail.nextWaiter = next;
                // 遍历结束,最后一次找到的CONDITION节点就是尾节点
                if (next == null)
                    lastWaiter = trail;
            }
            // 状态是 CONDITION 的 Node
            else
                trail = t;
            // 继续循环,循环顺序从头到尾
            t = next;
        }
    }
    Um es für alle einfacher zu machen, diese Methode zu verstehen, habe ich ein Erklärungsdiagramm wie folgt gezeichnet: # 🎜🎜#

    2.2 , Einzelnes Wecksignal Wie gibt die Java-Synchronizer-AQS-Architektur Sperren frei und synchronisiert Warteschlangen?

    Signalmethode bedeutet Wecken. Zum Beispiel war die Warteschlange vorher voll, Einige Threads wurden aufgrund von Take-Vorgängen in der bedingten Warteschlange blockiert, und plötzlich wurden die Elemente in der Warteschlange von Thread A verbraucht. Thread A ruft die Signalmethode auf, um den zuvor blockierten Thread aufzuwecken, der am Kopfknoten von beginnt die Bedingungswarteschlange (siehe den blauen Teil im Gesamtarchitekturdiagramm für den Prozess).

    // 唤醒阻塞在条件队列中的节点
    public final void signal() {
        if (!isHeldExclusively())
            throw new IllegalMonitorStateException();
        // 从头节点开始唤醒
        Node first = firstWaiter;
        if (first != null)
            // doSignal 方法会把条件队列中的节点转移到同步队列中去
            doSignal(first);
    }
    // 把条件队列头节点转移到同步队列去
    private void doSignal(Node first) {
        do {
            // nextWaiter为空,说明到队尾了
            if ( (firstWaiter = first.nextWaiter) == null)
                lastWaiter = null;
            // 从队列头部开始唤醒,所以直接把头节点.next 置为 null,这种操作其实就是把 node 从条件队列中移除了
            // 这里有个重要的点是,每次唤醒都是从队列头部开始唤醒,所以把 next 置为 null 没有关系,如果唤醒是从任意节点开始唤醒的话,就会有问题,容易造成链表的割裂
            first.nextWaiter = null;
            // transferForSignal 方法会把节点转移到同步队列中去
            // 通过 while 保证 transferForSignal 能成功
            // 等待队列的 node 不用管他,在 await 的时候,会自动清除状态不是 Condition 的节点(通过 unlinkCancelledWaiters 方法)
            // (first = firstWaiter) != null  = true 的话,表示还可以继续循环, = false 说明队列中的元素已经循环完了
        } while (!transferForSignal(first) &&
                 (first = firstWaiter) != null);
    }

    Nachdem wir den gesamten Quellcode gelesen haben, können wir sehen, dass das Aufwecken der Knoten in der Bedingungswarteschlange tatsächlich die Knoten in der Bedingungswarteschlange in die Synchronisationswarteschlange überträgt und den Status seines vorherigen Knotens auf SIGNAL setzt .

    2.3. Alle Knoten aufwecken

    signalAll wird verwendet, um alle Knoten in der Bedingungswarteschlange aufzuwecken:

    // 返回 true 表示转移成功, false 失败
    // 大概思路:
    // 1. node 追加到同步队列的队尾
    // 2. 将 node 的前一个节点状态置为 SIGNAL,成功直接返回,失败直接唤醒
    // 可以看出来 node 的状态此时是 0 了
    final boolean transferForSignal(Node node) {
        /*
         * If cannot change waitStatus, the node has been cancelled.
         */
        // 将 node 的状态从 CONDITION 修改成初始化,失败返回 false
        if (!compareAndSetWaitStatus(node, Node.CONDITION, 0))
            return false;
        // 当前队列加入到同步队列,返回的 p 是 node 在同步队列中的前一个节点
        // 看命名是 p,实际是 pre 单词的缩写
        Node p = enq(node);
        int ws = p.waitStatus;
        // 状态修改成 SIGNAL,如果成功直接返回
        // 把当前节点的前一个节点修改成 SIGNAL 的原因,是因为 SIGNAL 本身就表示当前节点后面的节点都是需要被唤醒的
        if (ws > 0 || !compareAndSetWaitStatus(p, ws, Node.SIGNAL))
            // 如果 p 节点被取消,或者状态不能修改成SIGNAL,直接唤醒
            LockSupport.unpark(node.thread);
        return true;
    }
    #🎜🎜 #Sie können es dem Quellcode entnehmen. Das Wesentliche ist, dass die for-Schleife die transferForSignal-Methode aufruft, um die Knoten in der Bedingungswarteschlange zyklisch an die Synchronisationswarteschlange zu übertragen.

    3. Zusammenfassung

    Verstehen Sie das AQS-Architekturdiagramm jetzt im Stillen?

    Wie gibt die Java-Synchronizer-AQS-Architektur Sperren frei und synchronisiert Warteschlangen?

    Das obige ist der detaillierte Inhalt vonWie gibt die Java-Synchronizer-AQS-Architektur Sperren frei und synchronisiert Warteschlangen?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!

    Stellungnahme:
    Dieser Artikel ist reproduziert unter:yisu.com. Bei Verstößen wenden Sie sich bitte an admin@php.cn löschen