In diesem Artikel werden hauptsächlich relevante Informationen zum Vergleich lokaler ThreadLocal-Threads und Synchronisierungsmechanismen in Java vorgestellt. Freunde in Not können sich auf
Das Design von ThreadLocal
Werfen Sie zunächst einen Blick auf die Schnittstelle von ThreadLocal:
Object get() ; // 返回当前线程的线程局部变量副本 protected Object initialValue(); // 返回该线程局部变量的当前线程的初始值 void set(Object value); // 设置当前线程的线程局部变量副本的值
ThreadLocal verfügt über drei Methoden, von denen die bemerkenswerteste initialValue() ist, eine geschützte Methode, die offensichtlich speziell implementiert ist zum Überschreiben von Unterklassen. Diese Methode gibt den Anfangswert der lokalen Variablen des aktuellen Threads im Thread zurück. Diese Methode ist eine Methode mit verzögertem Aufruf, die ausgeführt wird, wenn ein Thread get() oder set(Object) zum ersten Mal aufruft, und nur einmal ausgeführt wird. Die eigentliche Implementierung in ThreadLocal gibt direkt einen null zurück:
protected Object initialValue() { return null; } Wie verwaltet ThreadLocal eine Kopie der Variablen für jeden Thread? Tatsächlich ist die Implementierungsidee sehr einfach. In der ThreadLocal-Klasse gibt es eine Map, die zum Speichern einer Kopie der Variablen jedes Threads verwendet wird.
Zum Beispiel die folgende Beispielimplementierung: Sie entspricht dem Speichern einer Map. Dies ist die Implementierung der get-Methode von ThreadLocal >Vergleich von ThreadLocal und anderen Synchronisationsmechanismen
public T get() {
Thread t = Thread.currentThread();//获取当前线程
ThreadLocalMap map = getMap(t);
if (map != null) {
ThreadLocalMap.Entry e = map.getEntry(this);
if (e != null)
return (T)e.value;
}
return setInitialValue();
}
ThreadLocalMap getMap(Thread t) {
return t.threadLocals;
} Welche Vorteile hat ThreadLocal im Vergleich zu anderen Synchronisationsmechanismen? ThreadLocal und alle anderen Synchronisationsmechanismen sind darauf ausgelegt, Zugriffskonflikte auf dieselbe Variable in mehreren Threads zu lösen. Bei gewöhnlichen Synchronisationsmechanismen wird Objektsperre verwendet, um einen sicheren Zugriff auf dieselbe Variable durch mehrere Threads zu erreichen. Zu diesem Zeitpunkt wird die Variable von mehreren Threads gemeinsam genutzt. Die Verwendung dieses Synchronisierungsmechanismus erfordert eine sehr detaillierte Analyse, wann die Variable gelesen und geschrieben werden soll, wann ein Objekt gesperrt werden soll, wann die Sperre des Objekts aufgehoben werden soll usw. All dies wird dadurch verursacht, dass mehrere Threads Ressourcen gemeinsam nutzen. ThreadLocal löst den gleichzeitigen Zugriff mehrerer Threads aus einem anderen Blickwinkel. ThreadLocal verwaltet eine Kopie der an den Thread gebundenen Variablen und isoliert so die Daten mehrerer Threads Es ist nicht erforderlich, die Variable zu synchronisieren. ThreadLocal stellt ein threadsicheres gemeinsames Objekt bereit. Beim Schreiben von Multithread-Code können Sie die gesamte unsichere Variable in ThreadLocal kapseln oder den threadspezifischen Zustand des Objekts in ThreadLocal kapseln.
Da ThreadLocal Objekte jeden Typs enthalten kann, erfordert die Verwendung von ThreadLocal zum Abrufen des Werts des aktuellen Threads eine erzwungene
. Aber mit der Einführung von Vorlagen in der neuen Java-Version (1.5) wird die neue ThreadLocal
Natürlich kann ThreadLocal den Synchronisationsmechanismus nicht ersetzen, und die beiden Problembereiche sind unterschiedlich. Der Synchronisierungsmechanismus dient dazu, den gleichzeitigen Zugriff mehrerer Threads auf dieselben Ressourcen zu synchronisieren und stellt eine effektive Möglichkeit zur Kommunikation zwischen mehreren Threads dar. ThreadLocal dient dazu, die gemeinsame Nutzung von Daten durch mehrere Threads zu isolieren. Daher ist es natürlich nicht erforderlich, mehrere Threads zu synchronisieren. Wenn Sie daher zwischen mehreren Threads kommunizieren müssen, verwenden Sie den Synchronisierungsmechanismus. Wenn Sie Freigabekonflikte zwischen mehreren Threads isolieren müssen, können Sie ThreadLocal verwenden, wodurch Ihr Programm erheblich vereinfacht und lesbarer und prägnanter wird.
Speichern Sie den aktuellen Sitzungsbenutzer
Speichern Sie einige Kontextvariablen, z. B. den ActionContext von Webwork Speichersitzungen, wie z. B. die Sitzung des Spring Hibernate Orms " (Singletons) ) oder ein Thread-sicheres gemeinsames Objekt, entweder durch Einkapseln der gesamten unsicheren Variablen in ein ThreadLocal oder durch Einkapseln des threadspezifischen Zustands des Objekts in ein ThreadLocal. Beispielsweise müssen in einer Anwendung, die eng mit einer Datenbank verknüpft ist, möglicherweise viele Methoden des Programms auf die Datenbank zugreifen. Es ist unpraktisch, eine Verbindung als Parameter in jede Methode des Systems aufzunehmen – der Zugriff auf die Verbindung über eine „Monade“ ist wahrscheinlich eine gröbere, aber viel bequemere Technik. Allerdings können mehrere Threads eine JDBC-Verbindung nicht sicher gemeinsam nutzen. Wie in Listing 3 gezeigt, können wir es durch die Verwendung von ThreadLocal in einer „Monade“ jeder Klasse in unserem Programm leicht machen, einen Verweis auf eine Verbindung pro Thread zu erhalten. Auf diese Weise können wir uns ThreadLocal so vorstellen, dass es uns ermöglicht, Monaden pro Thread zu erstellen.
Eine einfache Möglichkeit, die Thread-Sicherheit einer MySQL-Verbindung zu erreichen Theoretisch ist ThreadLocal tatsächlich relativ zu jedem Thread, und jeder Thread hat seinen eigenen ThreadLocal. Aber wie oben erwähnt, verwalten allgemeine Anwendungsserver einen Thread-Pool. Daher können verschiedene Benutzer beim Zugriff denselben Thread erhalten. Wenn Sie also auf TheadLocal basieren, müssen Sie darauf achten, den Cache von ThreadLocal-Variablen zu vermeiden, was dazu führt, dass andere Threads auf die Variablen dieses Threads zugreifen.
Das obige ist der detaillierte Inhalt vonDetaillierte Erläuterung von Vergleichsbeispielen für lokale ThreadLocal-Threads und Synchronisationsmechanismen in Java. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!
