Sperren in Java – Synchronisationssperren und Sperren im JUC-Paket

In diesem Artikel werden hauptsächlich die relevanten Informationen zur Java-Parallelitätssperre im Detail vorgestellt, die einen bestimmten Referenzwert haben.

Je nachdem, wann die Sperre zu Java hinzugefügt wird, können Sperren in Java verwendet werden werden in „Synchronisationssperren“ und „Sperren im JUC-Paket“ unterteilt.

Synchronisationssperre

　 Das heißt, die Synchronisierung erfolgt über das synchronisierte Schlüsselwort, um einen sich gegenseitig ausschließenden Zugriff auf konkurrierende Ressourcen zu erreichen. Synchronisationssperren werden bereits in Java 1.0 unterstützt.

Das Prinzip der Synchronisationssperre besteht darin, dass es für jedes Objekt nur eine Synchronisationssperre gibt, auf die verschiedene Threads gemeinsam zugreifen können. Allerdings kann die Synchronisationssperre zum gleichen Zeitpunkt nur von einem Thread erworben werden. Auf diese Weise können Threads, die die Synchronisationssperre erhalten haben, von der CPU geplant und auf der CPU ausgeführt werden. Threads, die die Synchronisationssperre nicht erhalten haben, müssen warten, bis sie die Synchronisationssperre erhalten, bevor sie weiterlaufen können. Dies ist das Prinzip der Multithread-Synchronisation durch Synchronisationssperre!

Sperren im JUC-Paket

Im Vergleich zu Synchronisationssperren sind die Sperren im JUC-Paket leistungsfähiger Framework, das eine flexiblere Nutzung von Sperren ermöglicht, aber schwieriger zu verwenden ist.

Die Sperren im JUC-Paket umfassen: Lock

Schnittstelle, ReadWriteLock-Schnittstelle, LockSupport-Blockierungsprimitiv, Bedingung, AbstractOwnableSynchronizer/AbstractQueuedSynchronizer/AbstractQueuedLongSynchronizer drei abstrakte Klassen , ReentrantLock-Exklusivsperre, ReentrantReadWriteLock-Lese-/Schreibsperre. Da CountDownLatch, CyclicBarrier und Semaphore ebenfalls über AQS implementiert werden, werde ich sie auch in das Lock-Framework einführen.

Schauen Sie sich zunächst das Rahmendiagramm des Schlosses an, wie unten gezeigt.

01. Lock-Schnittstelle

Die Lock-Schnittstelle im JUC-Paket unterstützt diejenigen mit unterschiedliche Semantik (Wiedereintritt, Fairness usw.) Sperrregeln. Die sogenannte unterschiedliche Semantik bedeutet, dass Sperren „faire Mechanismussperren“, „unfaire Mechanismussperren“, „wiedereintretende Sperren“ usw. umfassen können. „Fairer Mechanismus“ bezieht sich auf „der Mechanismus, mit dem verschiedene Threads Sperren erhalten, ist fair“, während sich „unfairer Mechanismus“ auf „der Mechanismus, mit dem verschiedene Threads Sperren erwerben können, ist unfair“ bezieht, und „wiedereintretende Sperre“ bezieht sich auf die gleichen Sperren können mehrfach von einem Thread erfasst werden.

02. ReadWriteLock

Die ReadWriteLock-Schnittstelle definiert eine Reihe von Lesern, die auf ähnliche Weise gemeinsam genutzt werden können Sperre. Exklusive Schreibsperre. Nur eine Klasse im JUC-Paket implementiert diese Schnittstelle, ReentrantReadWriteLock, da sie für die meisten Standardverwendungskontexte geeignet ist. Aber Programmierer können ihre eigenen Implementierungen erstellen, die für nicht standardmäßige Anforderungen geeignet sind.

03. AbstractOwnableSynchronizer/AbstractQueuedSynchronizer/AbstractQueuedLongSynchronizer

AbstractQueuedSynchronizer ist eine Klasse namens AQS, eine sehr nützliche Oberklasse zum Definieren von Sperren und anderen Synchronisierern, die auf der Warteschlange blockierter Threads basieren, werden Klassen wie ReentrantLock, ReentrantReadWriteLock, CountDownLatch, CyclicBarrier und Semaphore alle basierend auf der AQS-Klasse implementiert. Die AbstractQueuedLongSynchronizer-Klasse bietet die gleiche Funktionalität, erweitert jedoch die Unterstützung für den 64-Bit-Synchronisierungsstatus. Beide erweitern die Klasse AbstractOwnableSynchronizer (eine einfache Klasse, die dabei hilft, den Überblick darüber zu behalten, welcher Thread derzeit die exklusive Synchronisierung aufrechterhält).

04. LockSupport

LockSupport bietet „Sperren erstellen“ und „grundlegende Thread-Blockierungsprimitive für andere Synchronisationsklassen“.

Die Funktion von LockSupport ähnelt in gewisser Weise der von „Thread.suspend() und Thread.resume() in Thread“. Die Funktionen von park() und unpark() in LockSupport dienen zum Blockieren von Threads und Geben Sie sie frei. Blockieren Sie den Thread. Bei park () und unpark () tritt jedoch nicht das Problem eines „Deadlocks auf, der durch Thread.suspend und Thread.resume verursacht werden kann“.

05. Zustand

Bedingung muss in Verbindung mit Lock verwendet werden. Ihre Funktion besteht darin, die Monitormethode Object zu ersetzen. Sie können Threads über waiting() und signal() in den Ruhezustand versetzen. Die
Bedingungsschnittstelle beschreibt die Bedingungs-Variablen , die mit der Sperre verknüpft sein können. Die Verwendung dieser Variablen ähnelt impliziten Monitoren, auf die über Object.wait zugegriffen wird, sie bieten jedoch eine leistungsfähigere Funktionalität. Es ist wichtig zu beachten, dass eine einzelne Sperre mehreren Bedingungsobjekten zugeordnet sein kann. Um Kompatibilitätsprobleme zu vermeiden, unterscheiden sich die Namen der Bedingungsmethoden von denen in der entsprechenden Objektversion.

06. ReentrantLock

ReentrantLock ist eine exklusive Sperre. Die sogenannte exklusive Sperre bezieht sich auf eine Sperre, die nur von sich selbst belegt werden kann, dh sie kann gleichzeitig nur von einer Thread-Sperre erworben werden. Zu den ReentrantLock-Sperren gehören „fair ReentrantLock“ und „unfair ReentrantLock“. „Fair ReentrantLock“ bedeutet „der Mechanismus für verschiedene Threads zum Erwerb von Sperren ist fair“, während „unfair ReentrantLock“ bedeutet „der Mechanismus für verschiedene Threads zum Erwerb von Sperren ist unfair“ und ReentrantLock ist eine „Wiedereintrittssperre“.

Das UML-Klassendiagramm von ReentrantLock lautet wie folgt:

(01) ReentrantLock implementiert die Lock-Schnittstelle.
　(02) Es gibt eine Mitgliedsvariable sync in ReentrantLock, sync ist der Sync-Typ und erbt von AQS.
　(03) In ReentrantLock gibt es die „faire Sperrklasse“ FairSync und die „unfaire Sperrklasse“ NonfairSync, die beide Unterklassen von Sync sind. Das Synchronisierungsobjekt in ReentrantReadWriteLock ist eines von FairSync und NonfairSync. Dies bedeutet auch, dass ReentrantLock standardmäßig eine „faire Sperre“ oder eine „unfaire Sperre“ ist.

07. ReentrantReadWriteLock

ReentrantReadWriteLock ist die Implementierungsklasse der Lese-/Schreibsperrschnittstelle ReadWriteLock, die Unterklassen ReadLock enthält und WriteLock. ReentrantLock ist eine gemeinsame Sperre, während WriteLock eine exklusive Sperre ist.

Das UML-Klassendiagramm von ReentrantReadWriteLock lautet wie folgt:

(01) ReentrantReadWriteLock implementiert die ReadWriteLock-Schnittstelle.
　(02) ReentrantReadWriteLock enthält ein Synchronisierungsobjekt, eine Lesesperre „readerLock“ und eine Schreibsperre „writerLock“. Sowohl die Lesesperre ReadLock als auch die Schreibsperre WriteLock implementieren die Lock-Schnittstelle.
　(03) Sync ist wie „ReentrantLock“ ein Sync-Typ; darüber hinaus ist Sync auch eine von AQS geerbte abstrakte Klasse. Sync umfasst auch „Fair Lock“ FairSync und „Unfair Lock“ NonfairSync.

08. CountDownLatch

CountDownLatch ist eine Synchronisations-Hilfsklasse, die eine Reihe von Vorgängen abschließt, die zuvor in anderen Threads ausgeführt wurden Abschluss: Dadurch können ein oder mehrere Threads ewig warten.
　Das UML-Klassendiagramm von CountDownLatch lautet wie folgt:

　CountDownLatch enthält das Sync-Objekt und sync ist der Sync-Typ. CountDownLatchs Sync ist eine Instanzklasse, die von AQS erbt.

09. CyclicBarrier

CyclicBarrier ist eine Synchronisationshilfsklasse, die es einer Gruppe von Threads ermöglicht, aufeinander zu warten bis zu einem bestimmten Ein gemeinsamer Barrierepunkt. Da diese Barriere nach der Freigabe des wartenden Threads wiederverwendet werden kann, wird sie als Schleifenbarriere bezeichnet.

Das UML-Klassendiagramm von CyclicBarrier lautet wie folgt:

CyclicBarrier enthält „ReentrantLock-Objektsperre“ und „Bedingungsobjektauslösung“. . Es wird durch exklusive Sperren implementiert.
Der Unterschied zwischen CyclicBarrier und CountDownLatch ist:
(01) Die Funktion von CountDownLatch besteht darin, 1 oder N Threads darauf zu warten, dass andere Threads die Ausführung abschließen; CyclicBarrier ermöglicht es N Threads, aufeinander zu warten.
　(02) Der Zähler von CountDownLatch kann nicht zurückgesetzt werden; der Zähler von CyclicBarrier kann zurückgesetzt und verwendet werden, daher wird er als zyklische Barriere bezeichnet.

10. Semaphore

Semaphor ist ein Zählsemaphor und sein Wesen ist ein „gemeinsames Schloss“.

Ein Semaphor verwaltet einen Semaphor-Berechtigungssatz. Der Thread kann die Berechtigung des Semaphors erhalten, indem er acquire() aufruft. Wenn eine Berechtigung im Semaphor verfügbar ist, muss der Thread andernfalls warten, bis eine Berechtigung verfügbar ist. Ein Thread kann die von ihm gehaltene Semaphor-Lizenz über release() freigeben.

Das UML-Klassendiagramm von Semaphore lautet wie folgt:

Wie „ReentrantLock“ enthält Semaphore Synchronisierungsobjekte, Sync ist ein Sync-Typ und Sync ist ebenfalls eine von AQS geerbte abstrakte Klasse. Sync umfasst auch „Fair Semaphore“ FairSync und „Unfair Semaphore“ NonfairSync.

Das obige ist der detaillierte Inhalt vonSperren in Java – Synchronisationssperren und Sperren im JUC-Paket. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!