In diesem Artikel werden hauptsächlich relevante Informationen zum Vergleich zwischen Java notify und notifyAll vorgestellt. Freunde in Not können sich auf
java notify und notifyAll beziehen
Zuallererst können Sie anhand des Namens verstehen, dass notify einen Thread benachrichtigt, eine Sperre zu erhalten, und notifyAll alle zugehörigen Threads benachrichtigt, um um die Sperre zu konkurrieren.
notify garantiert nicht, dass der Thread, der die Sperre erhält, die Sperre tatsächlich benötigt, und kann zu einem Deadlock führen.
Beispiel 1:
Alle (Verbraucherthread) sind zum Essen bereit, die Kantine ist nicht geöffnet (die Sperre ist nicht freigegeben), das Essensfenster (Sperre) , alle warten (WARTEN).
Die Kantine öffnet das Essensfenster (gibt die Sperre frei) und sendet die Nachricht „Abendessen ist serviert“ (notifyAll). Alle wetteifern darum, sich in einer Reihe aufzustellen und auf das Essen zu warten (BLOCKIERT). Jede Person spielt nacheinander (RUNNABLE) im Kochfenster (erhält die Sperre). Wenn Sie essen möchten, beenden Sie einfach die Mahlzeit und gehen Sie (Sperre aufheben). Wenn Sie nicht essen möchten, gehen Sie einfach direkt (Sperre aufheben). Wenn Sie nach dem Essen noch etwas essen möchten, ergreifen Sie die Initiative und warten Sie auf die nächste „Abendessen ist fertig“-Meldung (warten).
Die Kantine benachrichtigt eine Person, zum Essen zu kommen (benachrichtigen), und diese Person kommt zum Essensfenster (erhält das Schloss), um Essen zuzubereiten (RUNNABLE), und alle anderen warten auf die Nachricht, dass das Essen geöffnet ist (WARTEN). Wenn Sie essen möchten, beenden Sie einfach die Mahlzeit und gehen Sie (Sperre aufheben). Wenn Sie nicht essen möchten, gehen Sie einfach direkt (Sperre aufheben). Wenn Sie nach dem Essen noch etwas essen möchten, ergreifen Sie die Initiative und warten Sie auf die nächste „Abendessen“-Nachricht (WAITING).
notify kann nicht garantieren, dass Personen benachrichtigt werden, die wirklich essen möchten.
Beispiel 2:
Zwei Produzenten P1 und P2 und zwei Konsumenten C1 und C2 betreiben gemeinsam eine Warteschlange mit einer maximalen Warteschlangenlänge von 1.
Starten Sie P1, P2, C1 und C2 im laufenden Status (RUNNABLE).
C1 erhält zuerst die Sperre und P1, P2 und C2 befinden sich im Status BLOCKIERT. C1 stellt fest, dass die Warteschlange leer ist und geht aktiv in den Wartezustand über. C2 erhält dann die Sperre, wechselt in den Status RUNNABLE, stellt fest, dass die Warteschlange leer ist, und wechselt aktiv in den Status WAITING.
P1 erhält dann die Sperre, wechselt in den RUNNABLE-Status, fügt ein Element in die Warteschlange ein und benachrichtigt einen anderen Produzenten P2. P1 produziert in einer Schleife und stellt fest, dass die Warteschlange nicht leer ist und wird zu WAITING.
P2 wechselt in den Status RUNNABLE, stellt fest, dass die Warteschlange einen Wert hat, und wechselt aktiv in den Status WAITING.
Zu diesem Zeitpunkt wurde die Sperre aufgehoben, aber P1, P2, C1 und C2 befinden sich alle im Wartestatus. Es gibt keinen Thread zum Erlangen der Sperre und sie sind tot.
Verwandte Artikel:
Warten, Korrigieren Verwendung von notify und notifyAll
Besprechen Sie den wesentlichen Unterschied zwischen notify() und notifyAll() anhand von Beispielen
Das obige ist der detaillierte Inhalt vonEine detaillierte Einführung in den Vergleich zwischen Java Notify und NotifyAll. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!
