Lektionen

Das Verhaltensmuster „Beobachter“: die Rollen Subject und Observer, An-/Abmeldung über addObserver/ removeObserver sowie das Versenden von Benachrichtigungen mit notifyObservers. Wir beleuchten den Bezug zum Ereignismodell von Java: button. addActionListener( listener) ; → Aufruf von actionPerformed(). Praxis an Beispielen (Thermometer und Klimaanlage, Mini‑Zähler und Lambdas) sowie warum java.util.Observable/ Observer veraltet sind und welche modernen Ansätze es gibt.

In dieser Vorlesung erklären wir, was der Thread zur Verarbeitung von UI‑Ereignissen — EDT — in Swing ist und welches Pendant es im JavaFX Application Thread gibt, warum UI‑Komponenten nicht threadsicher sind und weshalb das Fenster bei schweren Aufgaben „einfriert“. Wir zeigen richtige Vorgehensweisen: Auslagerung der Berechnungen in den Hintergrund via new Thread(...), Aktualisierung der Oberfläche per Aufrufen von SwingUtilities.invokeLater und Platform.runLater sowie die Nutzung höherstufiger Werkzeuge SwingWorker<T, V> und Task<V>/ Service<V> für Fortschritt, Abbruch und Fehlerbehandlung.

Warum Programme Threads und Nebenläufigkeit brauchen: von einer reaktionsschnellen Oberfläche bis zur Auslastung aller CPU‑Kerne. Wir klären den Unterschied zwischen Prozessen und Threads, die Rolle des Haupt-Threads main in der JVM, praktische Anwendungsfälle (UI, Server, Dateiverarbeitung) und Risiken: race condition, deadlock sowie grundlegende Synchronisationswerkzeuge wie synchronized. Wir zeigen ein einfaches Beispiel mit Thread und dem parallelen Start zweier Aufgaben.

In dieser Vorlesung behandeln wir das Starten von Threads in Java: Wir lernen die Klasse Thread und das Interface Runnable kennen, üben den korrekten Aufruf von start() und verwechseln ihn nicht mit run(), verwenden anonyme Klassen und Lambda-Ausdrücke, starten mehrere Threads und betrachten den Lebenszyklus ( NEW → RUNNABLE → TERMINATED). Außerdem sprechen wir über die Methoden Thread.currentThread(), getName(), das Warten per join() und typische Fehler wie IllegalThreadStateException.

Wir analysieren den Lebenszyklus eines Threads in Java: von Thread.State (

NEW

,

RUNNABLE

,

BLOCKED

,

WAITING

,

TIMED_WAITING

,

TERMINATED

) bis zu den Übergängen zwischen ihnen. Wir lernen, Threads mithilfe von Thread.sleep(...), join(), interrupt() zu steuern, den Zustand über isAlive() und getState() zu diagnostizieren sowie veraltete Methoden wie stop()/ suspend()/ resume() zu vermeiden. Am Ende – praktische Tipps und häufige Fehler.

Wie man Parameter sicher an Threads über den Konstruktor der Klasse, die Runnable implementiert, übergibt, wann Lambda-Ausdrücke sinnvoll sind und warum Felder besser final sein sollten. Wir besprechen Thread-Prioritäten: die Methoden setPriority/ getPriority, die Konstanten Thread.MIN_PRIORITY, Thread.NORM_PRIORITY, Thread.MAX_PRIORITY und ihren Einfluss auf den Scheduler. Außerdem – das Benennen von Threads über den Konstruktor, setName/ getName, ein praktisches Beispiel und typische Fehler (gemeinsames Runnable, Setter, Hoffnungen in Prioritäten).

In dieser Vorlesung erklären wir, was eine Race Condition ist: wenn mehrere Threads gleichzeitig auf gemeinsame Daten zugreifen und das Ergebnis von der Planungsreihenfolge abhängt. Am Beispiel des Inkrements counter ++ zeigen wir, warum die Operation nicht atomar ist und wie Inkremente verloren gehen. Wir besprechen einen Praxisfall mit einem Bankkonto, die Folgen im Produktivbetrieb und Schutzansätze: synchronized, atomare Typen aus java.util.concurrent.atomic (zum Beispiel AtomicInteger) sowie Immutabilität. Wir schließen mit dem Abschnitt „Typische Fehler“ ab, in dem erläutert wird, warum Thread-Bugs von Tests selten erfasst werden und warum es sinnlos ist, sie mit Thread. sleep( 1) zu „heilen“.

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“.