Lektionen

Diese Vorlesung erklärt, was eine gemeinsame Ressource in nebenläufigen Anwendungen ist, warum Race Conditions und „verlorene Updates“ auftreten, und wie man Daten mit synchronized schützt. Wir besprechen grundlegende Synchronisationsmuster (Methoden und Blöcke), sprechen über moderne Werkzeuge aus java.util.concurrent ( Lock, ReentrantLock, Semaphore u. a.), sehen praktische Beispiele mit dem Inkrement eines Zählers und typische Fehler (Nicht-Atomarität von i ++, falsches Lock-Objekt, Mythen über volatile).

Praktische Vorlesung zur Nebenläufigkeit: Wir erklären, wie das Schlüsselwort synchronized funktioniert (Blöcke und Methoden, Objektmonitor und Sperre auf Klassenebene ClassName.class), worin sich die Sichtbarkeit von Änderungen über volatile von der Atomarität von Operationen unterscheidet, warum boolean-Flags sich gut als volatile eignen, und warum das Inkrement count ++ Synchronisierung erfordert. Wir stellen gegenüber, wann man synchronized wählt und wann – volatile, und besprechen typische Fehler.

Praktischer Vergleich der klassischen Synchronisation über synchronized mit den flexibleren Primitiven aus dem Paket java.util.concurrent.locks: ReentrantLock und ReadWriteLock. Wir schauen uns an, wie man Sperren explizit steuert ( lock()/ unlock(), tryLock() mit Timeout), wie man das Lesen mit ReentrantReadWriteLock skaliert, was „Fairness“ ( fair-Modus) bedeutet, wo welches Werkzeug sinnvoll ist und welche Fehler am häufigsten vorkommen.

In dieser Vorlesung behandeln wir zentrale Synchronisationsprimitiven in Java: wie man kritische Abschnitte mit synchronized und der Klasse ReentrantLock (Methoden lock()/ unlock(), Konstrukt try- finally) schützt, sowie wie man Parallelität über Semaphore (Methoden acquire()/ release()) begrenzt. Wir vergleichen Mutex und Semaphore in einer Tabelle, betrachten praktische Use-Cases (Bank, Server mit Verbindungs-Limit) und typische Fehler, die zu deadlock und Performanceverlusten führen.

Praktische Analyse häufiger Fehler der Nebenläufigkeit in Java: vergessenes unlock()/ release() bei ReentrantLock und Semaphore (behebbar mit try- finally), die Wahl des falschen Monitors für synchronized, gegenseitige Blockierungen (Deadlock) und die Reihenfolge der Lock-Akquise, übermäßige Synchronisation sowie die Grenzen der Anwendbarkeit von volatile und der Ersatz durch AtomicInteger. Beispiele, Tipps und eingängige Analogien – damit der Code nicht „einfriert“.