Ich habe seit der ersten Beta in Java programmiert; Schon damals standen Threads ganz oben auf meiner Liste meiner Lieblingsfeatures. Java war die erste Sprache, die Thread-Unterstützung in der Sprache selbst einführte; Es war damals eine umstrittene Entscheidung.  Im letzten Jahrzehnt hat sich jede Sprache rasant darum bemüht, async/await zu integrieren, und   … Aber Java ging im Zickzack statt im Zickzack und führte die weitaus besseren   . In diesem Beitrag geht es nicht darum. sogar Java hatte Unterstützung von Drittanbietern dafür virtuellen Threads ein (Projekt Loom)  Ich finde es wunderbar und beweist die Kernleistung von Java. Nicht nur als Sprache, sondern als Kultur. Eine Kultur der bewussten Veränderung, statt sich auf den modischen Trend einzulassen.  In diesem Beitrag möchte ich die alten Methoden des Threadings in Java noch einmal Revue passieren lassen. Ich bin es gewohnt, „   “,   “,   “ usw. zu verwenden. Aber es ist schon lange her, dass sie der überlegene Ansatz für Threading in Java waren. synchronized wait notify  Ich bin Teil des Problems; Ich bin immer noch an diese Ansätze gewöhnt und es fällt mir schwer, mich an einige APIs zu gewöhnen, die es seit Java 5 gibt. Es ist eine Gewohnheit. T  Es gibt viele großartige APIs für die Arbeit mit Threads, die ich in den Videos hier bespreche, aber ich möchte über Sperren sprechen, die grundlegend und dennoch wichtig sind.   https://www.youtube.com/watch?v=pUnX8r-6IIo&embedable=true   https://www.youtube.com/watch?v=pOrhJ8o9TT0&embedable=true  Synchronisiert vs. ReentrantLock  Eine Abneigung, die ich beim Verlassen von Synchronized hatte, ist, dass die Alternativen nicht viel besser sind. Der Hauptgrund dafür, heute damit aufzuhören, besteht darin, dass die Synchronisierung derzeit dazu führen kann, dass Threads in Loom fixiert werden, was nicht ideal ist.  JDK 21 könnte dies beheben (wenn Loom auf GA umgestellt wird), aber es macht immer noch Sinn, es beizubehalten.  Der direkte Ersatz für synchronisiert ist ReentrantLock. Leider hat ReentrantLock gegenüber der Synchronisierung nur sehr wenige Vorteile, sodass der Nutzen der Migration bestenfalls zweifelhaft ist.  Tatsächlich hat es einen großen Nachteil; Um einen Eindruck davon zu bekommen, schauen wir uns ein Beispiel an. So würden wir synchronisiert verwenden:   synchronized(LOCK) { // safe code } LOCK.lock(); try { // safe code } finally { LOCK.unlock(); }  Der erste Nachteil von   ist die Ausführlichkeit. Wir benötigen den try-Block, da die Sperre bestehen bleibt, wenn innerhalb des Blocks eine Ausnahme auftritt. Synchronized erledigt das nahtlos für uns. ReentrantLock  Es gibt einen Trick, den manche Leute anwenden, um das Schloss mit   zu umschließen, der ungefähr so aussieht: AutoClosable   public class ClosableLock implements AutoCloseable { private final ReentrantLock lock; public ClosableLock() { this.lock = new ReentrantLock(); } public ClosableLock(boolean fair) { this.lock = new ReentrantLock(fair); } @Override public void close() throws Exception { lock.unlock(); } public ClosableLock lock() { lock.lock(); return this; } public ClosableLock lockInterruptibly() throws InterruptedException { lock.lock(); return this; } public void unlock() { lock.unlock(); } }  Beachten Sie, dass ich die Lock-Schnittstelle nicht implementiert habe, was ideal gewesen wäre. Das liegt daran, dass die lock-Methode die automatisch schließbare Implementierung anstelle von   zurückgibt. void  Sobald wir das getan haben, können wir prägnanteren Code wie diesen schreiben:   try(LOCK.lock()) { // safe code }  Mir gefällt die reduzierte Ausführlichkeit, aber das ist ein problematisches Konzept, da try-with-resource zum Zweck der Bereinigung konzipiert ist und wir Sperren wiederverwenden. Es ruft close auf, aber wir werden diese Methode erneut für dasselbe Objekt aufrufen.  Ich denke, es wäre schön, den Versuch mit der Ressourcensyntax zu erweitern, um die Sperrschnittstelle zu unterstützen. Aber solange das nicht geschieht, dürfte dieser Trick kein lohnenswerter Trick sein.  Vorteile von ReentrantLock  Der Hauptgrund für die Verwendung   ist die Loom-Unterstützung. Die anderen Vorteile sind nett, aber keines davon ist ein „Killer-Feature“. ReentrantLock  Wir können es zwischen Methoden statt in einem kontinuierlichen Block verwenden. Dies ist wahrscheinlich eine schlechte Idee, da Sie den Sperrbereich minimieren möchten und ein Fehler ein Problem darstellen kann. Ich halte diese Funktion nicht für einen Vorteil.  Es besteht die Möglichkeit der Fairness. Dies bedeutet, dass der erste Thread, der bei einer Sperre angehalten hat, zuerst bedient wird. Ich habe versucht, mir einen realistischen, unkomplizierten Anwendungsfall vorzustellen, bei dem dies von Bedeutung sein wird, und ich ziehe Lücken.  Wenn Sie einen komplexen Scheduler schreiben, bei dem sich viele Threads ständig in der Warteschlange für eine Ressource befinden, kann es zu einer Situation kommen, in der ein Thread „ausgehungert“ ist, weil ständig andere Threads eingehen. Solche Situationen werden jedoch wahrscheinlich besser durch andere Optionen im Concurrency-Paket bedient .  Vielleicht übersehe ich hier etwas ...    können wir einen Thread unterbrechen, während er auf eine Sperre wartet. Dies ist eine interessante Funktion, aber auch hier ist es schwierig, eine Situation zu finden, in der sie realistischerweise einen Unterschied machen würde. lockInterruptibly()  Wenn Sie Code schreiben, der sehr schnell auf Unterbrechungen reagieren muss, müssen Sie die API   verwenden, um diese Fähigkeit zu erhalten. Aber wie lange verbringt man durchschnittlich mit der   Methode? lockInterruptibly() lock()  Es gibt Randfälle, in denen dies wahrscheinlich von Bedeutung ist, aber die meisten von uns werden nicht darauf stoßen, selbst wenn sie fortgeschrittenen Multithread-Code erstellen.  ReadWriteReentrantLock  Ein viel besserer Ansatz ist   . Die meisten Ressourcen folgen dem Prinzip häufiger Lesevorgänge und weniger Schreibvorgängen. Da das Lesen einer Variablen threadsicher ist, ist keine Sperre erforderlich, es sei denn, wir schreiben gerade in die Variable. ReadWriteReentrantLock  Dies bedeutet, dass wir das Lesen extrem optimieren und gleichzeitig die Schreibvorgänge etwas langsamer machen können.  Vorausgesetzt, dies ist Ihr Anwendungsfall, können Sie viel schneller Code erstellen. Wenn wir mit einer Lese-/Schreibsperre arbeiten, haben wir zwei Sperren; eine Lesesperre, wie wir im folgenden Bild sehen können. Es lässt mehrere Threads durch und ist praktisch „kostenlos für alle“.  Sobald wir in die Variable schreiben müssen, müssen wir eine Schreibsperre erhalten, wie wir im folgenden Bild sehen können. Wir versuchen, die Schreibsperre anzufordern, aber es gibt noch Threads, die aus der Variablen lesen, also müssen wir warten.  Sobald die Threads mit dem Lesen fertig sind, werden alle Lesevorgänge blockiert und der Schreibvorgang kann nur von einem einzelnen Thread aus erfolgen, wie in der folgenden Abbildung dargestellt. Sobald wir die Schreibsperre aufheben, kehren wir zur „Frei für alle“-Situation im ersten Bild zurück.  Dies ist ein leistungsstarkes Muster, das wir nutzen können, um Sammlungen viel schneller zu machen. Eine typische synchronisierte Liste ist bemerkenswert langsam. Es synchronisiert alle Vorgänge, ob Lesen oder Schreiben. Wir haben eine CopyOnWriteArrayList, die schnell liest, aber alle Schreibvorgänge sehr langsam ist.  Vorausgesetzt, Sie können die Rückgabe von Iteratoren aus Ihren Methoden vermeiden, können Sie Listenoperationen kapseln und diese API verwenden.  Im folgenden Code stellen wir beispielsweise die Namensliste als schreibgeschützt bereit. Wenn wir dann jedoch einen Namen hinzufügen müssen, verwenden wir die Schreibsperre. Dies kann   Listen leicht übertreffen: synchronized   private final ReadWriteLock LOCK = new ReentrantReadWriteLock(); private Collection<String> listOfNames = new ArrayList<>(); public void addName(String name) { LOCK.writeLock().lock(); try { listOfNames.add(name); } finally { LOCK.writeLock().unlock(); } } public boolean isInList(String name) { LOCK.readLock().lock(); try { return listOfNames.contains(name); } finally { LOCK.readLock().unlock(); } }  StampedLock  Das erste, was wir über   verstehen müssen, ist, dass es nicht reentrant ist. Angenommen, wir haben diesen Block: StampedLock   synchronized void methodA() { // … methodB(); // … } synchronized void methodB() { // … }  Das wird funktionieren. Da synchronisiert wiedereintrittsfähig ist. Wir halten die Sperre bereits aufrecht, sodass das Aufrufen   von   nicht blockiert. Dies funktioniert auch mit ReentrantLock, vorausgesetzt, wir verwenden dieselbe Sperre oder dasselbe synchronisierte Objekt. methodB() methodA()    gibt einen Stempel zurück, mit dem wir die Sperre aufheben. Aus diesem Grund gibt es einige Grenzen. Aber es ist immer noch sehr schnell und leistungsstark. Es enthält auch einen Lese- und Schreibstempel, mit dem wir eine gemeinsam genutzte Ressource schützen können. StampedLock  Aber im Gegensatz zu   können wir damit die Sperre aktualisieren. Warum sollten wir das tun? ReadWriteReentrantLock,  Schauen Sie sich die Methode   von vorhin an ... Was passiert, wenn ich sie zweimal mit „Shai“ aufrufe? addName()  Ja, ich könnte ein Set verwenden ... Aber für den Zweck dieser Übung nehmen wir an, dass wir eine Liste benötigen ... Ich könnte diese Logik mit   schreiben: ReadWriteReentrantLock   public void addName(String name) { LOCK.writeLock().lock(); try { if(!listOfNames.contains(name)) { listOfNames.add(name); } } finally { LOCK.writeLock().unlock(); } }  Das ist scheiße. Ich habe für eine Schreibsperre nur „bezahlt“, um in manchen Fällen   zu überprüfen (vorausgesetzt, es gibt viele Duplikate). Wir können   aufrufen, bevor wir die Schreibsperre erhalten. Dann würden wir: contains() isInList(name)  Schnappen Sie sich die Lesesperre  Geben Sie die Lesesperre frei  Schnappen Sie sich die Schreibsperre  Geben Sie die Schreibsperre frei  In beiden Fällen des Greifens stehen wir möglicherweise in einer Warteschlange, und der zusätzliche Aufwand lohnt sich möglicherweise nicht.  Mit einem   können wir die Lesesperre in eine Schreibsperre aktualisieren und die Änderung bei Bedarf sofort wie folgt durchführen: StampedLock   public void addName(String name) { long stamp = LOCK.readLock(); try { if(!listOfNames.contains(name)) { long writeLock = LOCK.tryConvertToWriteLock(stamp); if(writeLock == 0) { throw new IllegalStateException(); } listOfNames.add(name); } } finally { LOCK.unlock(stamp); } }  Für diese Fälle handelt es sich um eine leistungsstarke Optimierung.  Endlich  Ich behandle viele ähnliche Themen in der Videoserie oben; Schauen Sie es sich an und teilen Sie mir Ihre Meinung mit.  Ich greife oft nach den synchronisierten Sammlungen, ohne darüber nachzudenken. Das kann manchmal sinnvoll sein, aber für die meisten ist es wahrscheinlich nicht optimal. Indem wir ein wenig Zeit mit Thread-bezogenen Grundelementen verbringen, können wir unsere Leistung erheblich verbessern.  Dies gilt insbesondere im Fall von Loom, wo der zugrunde liegende Streit weitaus heikler ist. Stellen Sie sich vor, Lesevorgänge auf 1 Mio. gleichzeitige Threads zu skalieren … In diesen Fällen ist die Reduzierung von Sperrkonflikten weitaus wichtiger.  Sie fragen sich vielleicht, warum   Sammlungen nicht   oder sogar   verwenden können? synchronized ReadWriteReentrantLock StampedLock  Dies ist problematisch, da die Oberfläche der API so groß ist, dass es schwierig ist, sie für einen generischen Anwendungsfall zu optimieren. Hier kann die Kontrolle über die Low-Level-Primitive den Unterschied zwischen hohem Durchsatz und blockierendem Code ausmachen.

Shai is a Developer Advocate at Lightrun, where he's busy explaining why hotfixing just to add a log line needs to be a thing of the past. He is also a JavaOne rockstar that has been developing software professionally for ~30 years, a published author, an open-source hacker (founder and long-time maintainer of Codename One) , an experienced Java trainer and a public speaker. When he's not in front of his machine you can find him making food for his two kids or doing Yoga with his wife (well, at least attempting to).

2021 - HackerNoon Contributor of the Year - DEBUGGING

2022 - HackerNoon Contributor of the Year - Coding Skills

2022 - HackerNoon Contributor of the Year - Debugging

2022 - HackerNoon Contributor of the Year - Java

2022 - HackerNoon Contributor of the Year - Monitoring

2022 - HackerNoon Contributor of the Year - Software Testing

Debug Agent

Buy My Book

Learn on my YouTube Channel

Read My Stories

Newsletter

Follow me on Twitter

Author/DevRel/Entrepreneur/Hacker

Dieses Audio ist in der Originalsprache der Geschichte produziert!

Zu lang; Lesen

Der wesentliche Leitfaden zum Umlernen von Java-Thread-Primitiven

Der wesentliche Leitfaden zum Umlernen von Java-Thread-Primitiven

About Author

KOMMENTARE

Hängeetiketten

DIESER ARTIKEL WURDE VORGESTELLT IN

Related Stories

HackerNoon Decoded 2024: Celebrating Our Startups Community!

Welcome to HackerNoon Decoded: The Best of 2024 Tech Blogging

HackerNoon Decoded 2024: Wir feiern unsere Gaming-Community!

HackerNoon Decoded 2024: Celebrating Our AI Community!

HackerNoon Decoded 2024: Celebrating Our Startups Community!

Welcome to HackerNoon Decoded: The Best of 2024 Tech Blogging

HackerNoon Decoded 2024: Wir feiern unsere Gaming-Community!

HackerNoon Decoded 2024: Celebrating Our AI Community!

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps