Fragen zum Java-Lock-Interview (ReentrantLock, synchronisiert)

---

1. sperren

Häufig verwendete Tools im Zusammenhang mit Sperren und Thread-Sicherheit: synchronisiert, ReentrantLock, AtomicInteger, AtomicLong, CopyOnWriteArrayList, CopyOnWriteArraySet, ConcurrentHashMap, ConcurrentSkipListMap, ConcurrentSkipListSet

2. ReentrantLock

[Bildübertragung mit externem Link fehlgeschlagen, die Quellseite verfügt möglicherweise über einen Anti-Leeching-Mechanismus. Es wird empfohlen, das Bild zu speichern und direkt hochzuladen (img-gkCZHf8l-1685216539209)(…/images/imagehello.png)]

2.1 Das Realisierungsprinzip von ReentrantLock

ReentrantLock wird basierend auf AQS (AbstractQueuedSynchronizer) implementiert. AQS ist ein Framework zum Erstellen von Sperren und Synchronisierern. Mit AQS kann eine große Anzahl weit verbreiteter Synchronisierer einfach und effizient erstellt werden, z. B. häufig verwendete ReentrantLock, Semaphore, CountDownLatch, ReentrantReadWriteLock und ThreadPoolExecutor , usw.

2.2 Was ist AQS?

AQS verwaltet intern einen flüchtigen int-Status und eine FIFO-Warteschlange. Der Status wird zur Darstellung des Synchronisierungsstatus verwendet, und die FIFO-Warteschlange wird zum Speichern von Threads verwendet, die den Synchronisierungsstatus nicht erhalten.

2.3 Was ist CAS?

CAS (Compare And Swap) ist ein sperrfreier Algorithmus. Wenn mehrere Threads versuchen, CAS zu verwenden, um dieselbe Variable gleichzeitig zu aktualisieren, kann nur einer der Threads den Wert der Variablen aktualisieren, während andere Threads fehlschlagen Der fehlgeschlagene Thread wird nicht gelöscht. Anstatt zu hängen, wird Ihnen mitgeteilt, dass Sie diesen Wettbewerb nicht bestanden haben, und Sie können es erneut versuchen.

3. synchronisiert

3.1 Das Realisierungsprinzip der Synchronisation

Implementiert durch Objektmonitore in Java. Jedes Objekt verfügt über einen Monitor, und der Monitor kann einer beliebigen Anzahl von Threads zugeordnet werden. Der Thread kann mit dem Monitor interagieren, indem er die Methoden wait() und notify() des Objekts aufruft.

Der Thread führt wait() aus: Er lässt sich in die Warteschlange des Monitors eintreten und gibt alle Sperren auf dem Monitor frei.

Der Thread führt notify() aus: Er wählt zufällig einen Thread aus der Warteschlange aus und weckt ihn auf. Der aufgeweckte Thread tritt in die Sperrwarteschlange des Monitors ein und wartet darauf, die Sperre auf dem Monitor zu erhalten. Wenn der Thread die Ausführung beendet und den synchronisierten Codeblock verlässt, werden alle Sperren auf dem Monitor freigegeben. Zu diesem Zeitpunkt kann der aufgeweckte Thread die Sperren auf dem Monitor erwerben und mit der Ausführung fortfahren.

3.2 Aktualisierungsprozess des synchronisierten Schlosses

[Externer Link-Bildtransfer fehlgeschlagen, die Quellseite verfügt möglicherweise über einen Anti-Diebstahl-Link-Mechanismus, es wird empfohlen, das Bild zu speichern und direkt hochzuladen (img-1amvKo6G-1685216539210)(.../images/image-111.png) ] Der synchronisierte Sperraktualisierungsprozess ist in
vier Phasen unterteilt: keine Sperre, voreingenommene Sperre, leichte Sperre und schwere Sperre.

Beschreiben Sie kurz den Upgrade-Prozess:
Keine Sperre
↓
Voreingenommene Sperre: Wenn ein Thread auf den Synchronisationsblock zugreift und die Sperre erhält und der Synchronisationsblock nicht gesperrt ist, versucht der Thread, die voreingenommene Sperre des Synchronisationsblocks zu erhalten und die Markierung festzulegen Im Objektheader Word ist eine voreingenommene Sperre festgelegt. Wenn der synchronisierte Block bereits von einem anderen Thread gesperrt ist, versucht der Thread, die Lightweight-Sperre des synchronisierten Blocks zu erhalten.
↓
Leichte Sperre: Wenn ein Thread versucht, die Sperre eines Synchronisationsblocks zu erlangen und der Synchronisationsblock nicht gesperrt ist, versucht der Thread, die leichte Sperre des Synchronisationsblocks zu erlangen und setzt das Mark Word im Objektheader auf is ein Zeiger auf den Stapelrahmen des Threads. Wenn der Synchronisationsblock bereits von anderen Threads gesperrt ist, versucht der Thread, die schwere Sperre des Synchronisationsblocks zu erlangen.
↓
Schwergewichtige Sperre: Wenn ein Thread versucht, die Sperre eines Synchronisationsblocks zu erlangen und der Synchronisationsblock von anderen Threads gesperrt wurde, wechselt der Thread in den blockierten Zustand, bis die Sperre des Synchronisationsblocks aufgehoben wird. Bei der Implementierung schwerer Sperren verweist die JVM auf das Markierungswort des Objekts auf einen Mutex, um das Blockieren und Erwachen von Threads zu realisieren.

3.2.1 Sperrfrei

Im sperrfreien Zustand können Threads ohne Synchronisierungsvorgänge nach Belieben in den kritischen Abschnitt gelangen.

3.2.2 Bias-Sperre

Voreingenommene Sperre (wird nur in konkurrenzlosen Szenarien verwendet). Wenn eine Szene eine Sperre erhält, kann der Thread in Zukunft die Sperre hier erwerben, und die JVM wird diesen Thread bevorzugen.

3.2.3 Leichte Schlösser

Leichte Sperren (wird nur in konkurrenzlosen Szenarien verwendet). Wenn eine Szene eine Sperre erhält, kann der Thread in Zukunft die Sperre hier erwerben, und die JVM wird diesen Thread bevorzugen.

3.2.4 Schwergewichtsschlösser

Schwere Sperren (wird nur in Wettbewerbsszenarien verwendet). Wenn eine Szene eine Sperre erhält, kann der Thread in Zukunft die Sperre hier erwerben, und die JVM wird diesen Thread bevorzugen.

3.2.5 Spinlocks

Eine Spin-Sperre bedeutet, dass ein Thread, wenn er versucht, eine Sperre zu erhalten, in einer Schleife wartet, bis die Sperre aufgehoben wird, wenn die Sperre bereits von anderen Threads belegt ist. Der Thread wird nicht angehalten, sondern befindet sich in einer beschäftigten Warteschleife Daher eignen sich Spin-Locks im Allgemeinen für Situationen, in denen der durch die Sperre geschützte kritische Abschnitt relativ klein ist.

3.2 Der Unterschied zwischen synchronisiert und volatil

synchronisiert wird verwendet, um sicherzustellen, dass jeweils nur ein Thread auf den von synchronisiert geänderten Code zugreifen kann, während flüchtig verwendet wird, um die Sichtbarkeit von Variablen zwischen mehreren Threads sicherzustellen.

4. Der Unterschied zwischen synchronisiert und ReentrantLock

1. synchronisiert ist ein Java-Schlüsselwort, ReentrantLock ist eine Klasse
2. Im Vergleich zu synchronisiert bietet ReentrantLock einige erweiterte Funktionen, hauptsächlich die folgenden drei Elemente:
   1. Das Warten kann unterbrochen werden. Wenn der Thread, der die Sperre hält, längere Zeit nicht freigegeben wird, kann der wartende Thread das Warten aufgeben, was der Vermeidung von Deadlocks in Bezug auf die Synchronisierung entspricht
   2. Faire Sperre. Wenn mehrere Threads auf dieselbe Sperre warten, müssen sie die Sperre in der Reihenfolge erwerben, in der sie die Sperre beantragt haben. Synchronisierte Sperren sind unfaire Sperren. Der Standardkonstruktor von ReentrantLock ist eine unfaire Sperre, die durch Übergabe von true an erstellt wird Erstellen Sie eine faire Sperre.
   3. Die Sperre ist an mehrere Bedingungen gebunden, und ein ReentrantLock-Objekt kann mehrere Condition-Objekte gleichzeitig binden
3. Synchronized gibt die Sperre automatisch frei. ReentrantLock muss die Sperre manuell aufheben. Wenn die Sperre nicht aufgehoben wird, kann es zu einem Deadlock kommen

4.1 Was ist eine Wiedereintrittssperre?

Eine wiedereintretende Sperre bedeutet, dass derselbe Thread dieselbe Sperre mehrmals erhalten kann, ohne blockiert zu werden. Sowohl ReentrantLock als auch synchronisiert sind Wiedereintrittssperren.

4.2 Was sind optimistische Sperren und pessimistische Sperren? (kurze Antwort)

Es gibt viele Konzepte und spezifische Implementierungsmethoden.
Beim optimistischen Sperren wird davon ausgegangen, dass Daten im Allgemeinen keine Konflikte verursachen und daher nicht gesperrt werden. Beim pessimistischen Sperren wird davon ausgegangen, dass Daten im Allgemeinen Konflikte verursachen und daher gesperrt werden.

4.3 Was ist ein Spinlock? (kurze Antwort)

Spin-Lock bedeutet, dass der Thread, der versucht, die Sperre zu erlangen, nicht sofort blockiert wird, sondern versucht, die Sperre zyklisch zu erlangen. Der Vorteil davon besteht darin, den Verbrauch des Thread-Kontextwechsels zu reduzieren. Der Nachteil ist, dass die Schleife dies tut verbrauchen CPU.

4.4 Was sind faire Sperren und unfaire Sperren? (kurze Antwort)

Faire Sperren bedeuten, dass mehrere Threads Sperren in der Reihenfolge erhalten, in der sie Sperren beantragen. Unfaire Sperren sind nicht sequentiell. Der Vorteil unfairer Sperren besteht darin, dass der Durchsatz größer ist als bei fairen Sperren.

4.5 Was ist Deadlock? So vermeiden Sie es (kurze Antwort)

Deadlock bezieht sich auf ein Phänomen, bei dem zwei oder mehr Threads aufgrund des Wettbewerbs um Ressourcen während der Ausführung aufeinander warten. Wenn keine äußere Kraft vorhanden ist, können diese Threads nicht vorankommen.
Möglichkeiten zur Vermeidung von Deadlocks:

1. Timeout einstellen
2. Deadlock-Erkennung tryLock
   usw.

Meine Github-Adresse . Begrüßen Sie alle, die meinem Open-Source-Projekt beitreten möchten, oder (kontaktieren Sie mich auf meiner Homepage), um Ihrem Open-Source-Projekt beizutreten, und klicken Sie auf Github-Stars.

\	Name des Open-Source-Projekts	abhängiger Typ	Versionsnummer	beschreiben
1	Spring-Boot-Starter-Versuch	pom	1.0.0-SNAPSHOT	Die Abfragegeschwindigkeit unter bestimmten Anforderungen übertrifft die von Open-Source-Suchtools bei weitem, und der B + -Baum unter innodb oder der invertierte Index in ES können nicht damit verglichen werden.
2	Spring-Boot-Starter-Versuch	Krug	1.0.0-M1	Stellt SpringCloud-basierte Dienstknoten bereit, die für die Diensterkennung über die Nacos-Registrierung verwendet werden können und eine dynamische Erweiterung und Kontraktion des Baums sowie dynamische Online- und Offline-Dienste realisieren.
3	Datenanbieter	pom	1.0.0-SNAPSHOT	Es bietet Abfragen aus mehreren Datenquellen und die Synchronisierung von Datentypen. Als Jar kann es sich auf die dynamische Bereitstellung von Daten für andere Dienste verlassen.