Heim  >  Artikel  >  Java  >  Was sind die Unterschiede zwischen Java-Sperren?

Was sind die Unterschiede zwischen Java-Sperren?

爱喝马黛茶的安东尼
爱喝马黛茶的安东尼Original
2019-11-12 16:31:081983Durchsuche

Was sind die Unterschiede zwischen Java-Sperren?

Fair Lock/Unfair Lock

Fair Lock bedeutet, dass mehrere Threads die Sperre in der Reihenfolge erhalten, die sie beantragen es Sperren.

Unfaire Sperre bedeutet, dass die Reihenfolge, in der mehrere Threads Sperren erhalten, nicht mit der Reihenfolge übereinstimmt, in der sie Sperren anwenden. Es ist möglich, dass der Thread, der später angewendet wurde, die Sperre vor dem Thread erhält, der zuerst angewendet wurde. Es ist möglich, dass es zu einer Prioritätsumkehr oder einem Aushungern kommt.

Für Java ReentrantLock geben Sie über den Konstruktor an, ob die Sperre eine faire Sperre ist, und der Standardwert ist eine unfaire Sperre. Der Vorteil unfairer Sperren besteht darin, dass der Durchsatz größer ist als bei fairen Sperren.

Für Synchronized handelt es sich ebenfalls um eine unfaire Sperre. Da es keine Thread-Planung über AQS wie ReentrantLock implementiert, gibt es keine Möglichkeit, es in eine faire Sperre umzuwandeln.

Wiedereintrittssperre

Wiedereintrittssperre, auch als rekursive Sperre bekannt, bedeutet, dass, wenn derselbe Thread die Sperre in der äußeren Methode erhält, er in die innere Methode eintritt Die Sperre wird automatisch übernommen. Es ist etwas abstrakt, aber unten finden Sie ein Codebeispiel.

Für Java ReentrantLock kann der Name als Wiedereintrittssperre angesehen werden und lautet Reentrant Lock.

Für Synchronized handelt es sich auch um eine Wiedereintrittssperre. Ein Vorteil von Wiedereintrittssperren besteht darin, dass Deadlocks bis zu einem gewissen Grad vermieden werden können.

synchronized void setA() throws Exception{
    Thread.sleep(1000);
    setB();
}
synchronized void setB() throws Exception{
    Thread.sleep(1000);
}

Der obige Code ist eine Funktion einer Wiedereintrittssperre. Wenn es sich nicht um eine Wiedereintrittssperre handelt, wird setB möglicherweise nicht vom aktuellen Thread ausgeführt, was zu einem Deadlock führen kann.

Exklusive Sperre/gemeinsame Sperre

Exklusive Sperre bedeutet, dass die Sperre jeweils nur von einem Thread gehalten werden kann.

Geteilte Sperre bedeutet, dass die Sperre von mehreren Threads gehalten werden kann.

Für Java ReentrantLock handelt es sich um eine exklusive Sperre. Aber für eine andere Implementierungsklasse von Lock, ReadWriteLock, ist die Lesesperre eine gemeinsame Sperre und die Schreibsperre eine exklusive Sperre.

Die gemeinsame Sperre der Lesesperre stellt sicher, dass das gleichzeitige Lesen sehr effizient ist und sich die Prozesse Lesen, Schreiben, Schreiben und Schreiben gegenseitig ausschließen.

Exklusive Sperren und gemeinsame Sperren werden ebenfalls über AQS implementiert, und es werden verschiedene Methoden implementiert, um exklusive oder gemeinsame Sperren zu erreichen.

Für Synchronized handelt es sich natürlich um eine exklusive Sperre.

Mutex-Sperre/Lese-/Schreibsperre

Die oben erwähnte exklusive Sperre/gemeinsame Sperre ist ein weit gefasster Begriff, und die Mutex-Sperre/Lese-/Schreibsperre ist eine spezifische Realisierung .

Die spezifische Implementierung der Mutex-Sperre in Java ist ReentrantLock.

Die spezifische Implementierung der Lese-/Schreibsperre in Java ist ReadWriteLock.

Optimistische Sperre/pessimistische Sperre

Optimistische Sperre und pessimistische Sperre beziehen sich nicht auf bestimmte Arten von Sperren, sondern auf die Perspektive der Betrachtung von Parallelität und Synchronisation.

Die pessimistische Sperre geht davon aus, dass gleichzeitige Vorgänge an denselben Daten definitiv geändert werden. Auch wenn keine Änderung vorliegt, wird sie als geändert betrachtet. Daher erfolgt bei gleichzeitigen Vorgängen mit denselben Daten die pessimistische Sperre in Form einer Sperre. Pessimistisch gesehen glaube ich, dass gleichzeitige Vorgänge ohne Sperren definitiv Probleme verursachen werden.

Optimistisches Sperren geht davon aus, dass gleichzeitige Vorgänge an denselben Daten nicht geändert werden. Beim Aktualisieren von Daten werden die Daten aktualisiert, indem versucht wird, die Daten zu aktualisieren und die Daten ständig neu zu aktualisieren. Optimistisch gesehen wird es bei gleichzeitigen Vorgängen ohne Sperren kein Problem geben.

Aus der obigen Beschreibung können wir ersehen, dass pessimistisches Sperren für Szenarien mit vielen Schreibvorgängen geeignet ist und optimistisches Sperren für Szenarien mit vielen Lesevorgängen geeignet ist Verbesserungen.

Die Verwendung pessimistischer Sperren in Java besteht darin, verschiedene Sperren zu verwenden.

Die Verwendung von optimistischem Sperren in Java ist eine sperrenfreie Programmierung, und der CAS-Algorithmus wird häufig verwendet. Ein typisches Beispiel ist die Atomklasse, die die Aktualisierung atomarer Operationen durch CAS-Spin implementiert.

Segmentierte Sperre

Segmentierte Sperre ist eigentlich ein Sperrenentwurf, keine spezifische Sperre. Für ConcurrentHashMap ist die Parallelitätsimplementierung effizient. Gleichzeitige Vorgänge werden durch segmentierte Sperren erreicht.

Nehmen wir ConcurrentHashMap, um über die Bedeutung und Designidee der Segmentsperre zu sprechen. Die Segmentsperre in ConcurrentHashMap heißt Segment und ähnelt der Struktur von HashMap (der Implementierung von HashMap in JDK7 und JDK8). Das heißt, das interne Es gibt ein Eintragsarray, und jedes Element im Array ist eine verknüpfte Liste und ein ReentrantLock (Segment erbt ReentrantLock).

Wenn Sie ein Element einfügen müssen, sperrt es nicht die gesamte Hashmap, sondern verwendet zunächst den Hashcode, um zu ermitteln, in welchem ​​Segment es platziert werden soll, und sperrt dann dieses Segment, also wann Wenn Multithread-Put Solange es nicht in einem Segment platziert wird, wird eine echte parallele Einfügung erreicht.

Wenn Sie jedoch die Größe zählen und die globalen Informationen der Hashmap erhalten, müssen Sie alle zu zählenden Segmentsperren erhalten.

Der Entwurfszweck der segmentierten Sperre besteht darin, die Granularität der Sperre zu verfeinern. Wenn der Vorgang nicht das gesamte Array aktualisieren muss, wird nur ein Element im Array gesperrt.

Bias Lock/Lightweight Lock/Heavyweight Lock

Diese drei Arten von Schlössern beziehen sich auf den Status des Schlosses und sind für Synchronisiert. In Java 5 wird eine effiziente Synchronisierung durch die Einführung eines Sperraktualisierungsmechanismus erreicht. Der Status dieser drei Sperren wird durch die Felder im Objektkopf des Objektmonitors angezeigt.

Voreingenommene Sperre bedeutet, dass immer ein Thread auf einen Teil des Synchronisationscodes zugreift und der Thread dann automatisch die Sperre erhält. Reduzieren Sie die Kosten für die Anschaffung von Schlössern.

Lightweight-Sperre bedeutet, dass, wenn die Sperre eine voreingenommene Sperre ist und von einem anderen Thread darauf zugegriffen wird, die voreingenommene Sperre zu einer leichten Sperre aufgewertet wird. Andere Threads werden versuchen, die Sperre durch Spin zu erhalten, was die Leistung verbessert.

Schwergewichtssperre bedeutet, dass die Drehung nicht für immer fortgesetzt wird, wenn es sich um eine Leichtgewichtssperre handelt tritt in die Blockierung ein und das Schloss wird zu einem Schwergewichtsschloss erweitert. Schwere Sperren blockieren andere Anwendungsthreads und verringern die Leistung.

Spin-Lock

In Java bedeutet ein Spin-Lock, dass der Thread, der versucht, die Sperre zu erlangen, nicht sofort blockiert, sondern versucht, die Sperre in einer Schleife zu erlangen . Der Vorteil besteht darin, den Verbrauch des Thread-Kontextwechsels zu reduzieren, der Nachteil besteht jedoch darin, dass die Schleife CPU verbraucht.

php Chinesische Website, eine große Anzahl kostenloser Java-Einführungs-Tutorials, willkommen zum Online-Lernen!

Das obige ist der detaillierte Inhalt vonWas sind die Unterschiede zwischen Java-Sperren?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!

Stellungnahme:
Der Inhalt dieses Artikels wird freiwillig von Internetnutzern beigesteuert und das Urheberrecht liegt beim ursprünglichen Autor. Diese Website übernimmt keine entsprechende rechtliche Verantwortung. Wenn Sie Inhalte finden, bei denen der Verdacht eines Plagiats oder einer Rechtsverletzung besteht, wenden Sie sich bitte an admin@php.cn