Threads und Nebenläufigkeit.

Ein Programm macht normalerweise eine Sache nach der anderen. Mit Threads laufen mehrere Abläufe scheinbar gleichzeitig: ein Download im Hintergrund, während die UI reagiert; mehrere Anfragen parallel bedient. Das ist mächtig, aber sobald sich zwei Threads denselben Speicher teilen, entstehen Fehler, die es im Single-Thread-Code nicht gibt: Race Conditions. Genau die sind der Prüfungsschwerpunkt in Programmieren 2.

Was du können musst:

• einen Thread starten (Runnable, start() vs. run(), join())
• erklären, warum counter++ bei mehreren Threads kaputtgeht (Race Condition)
• eine Race Condition mit synchronized beheben (gegenseitiger Ausschluss)
• volatile von synchronized abgrenzen (Sichtbarkeit vs. Atomarität)
• ein Deadlock-Szenario erkennen

Abgrenzung: hier geht es um die Grundlagen (Thread, synchronized, Race Condition, Deadlock). Tiefe Nebenläufigkeit (java.util.concurrent, Fork/Join, das formale Speichermodell) ist Master-Stoff.

Die Idee in einem Satz

Ein Thread ist ein eigenständiger Ausführungsfaden innerhalb eines Programms. Mehrere Threads teilen sich denselben Speicher, deshalb muss der Zugriff auf gemeinsamen veränderlichen Zustand koordiniert werden, sonst entstehen Race Conditions.

Einen Thread starten

// Runnable (funktionales Interface) ist der bevorzugte Weg
Runnable aufgabe = () -> System.out.println("Laeuft in " + Thread.currentThread().getName());

Thread t = new Thread(aufgabe);
t.start();      // startet einen NEUEN Thread, der run() ausfuehrt
t.join();       // wartet, bis t fertig ist

start() vs. run() ist die häufigste Anfänger-Falle: t.start() erzeugt einen neuen Thread. t.run() ruft die Methode nur direkt im aktuellen Thread auf, also gar kein zweiter Thread. join() lässt den aufrufenden Thread warten, bis der andere fertig ist.

Das Kernproblem: Race Condition

counter++ sieht aus wie eine Operation, ist aber in Wahrheit drei: den Wert lesen, plus eins rechnen, zurückschreiben (read-modify-write). Wenn sich zwei Threads dabei verschränken, lesen beide denselben alten Wert, und ein Update geht verloren.

class Zaehler {
    int counter = 0;
    void inc() { counter++; }   // NICHT atomar!
}
// Zwei Threads rufen je 1x inc() auf. Erwartet: 2. Tatsaechlich: manchmal 1.

Im Stepper siehst du genau, wie ein Update verloren geht.

Die Lösung: synchronized

synchronized sorgt für gegenseitigen Ausschluss (mutual exclusion): immer nur ein Thread ist im geschützten Block, die anderen warten. Java nutzt dafür einen intrinsischen Lock (das Objekt selbst bzw. this).

class Zaehler {
    private int counter = 0;
    synchronized void inc() { counter++; }   // jetzt atomar pro Aufruf
    // oder: void inc() { synchronized (this) { counter++; } }
}

Damit wird der read-modify-write unteilbar: Thread B kommt erst rein, wenn A komplett fertig ist, und liest dann A's aktuelles Ergebnis.

volatile und Deadlock (kurz)

volatile garantiert Sichtbarkeit: schreibt ein Thread ein volatile-Feld, sehen andere Threads den neuen Wert sofort (kein veralteter Cache-Wert). Aber volatile macht NICHT atomar, für counter++ reicht es nicht (das bleibt read-modify-write). Für atomares Zählen: synchronized oder AtomicInteger.

Deadlock: Zwei Threads halten je einen Lock und warten auf den jeweils anderen, beide blockieren für immer.

// Thread 1: synchronized(A) { synchronized(B) { ... } }
// Thread 2: synchronized(B) { synchronized(A) { ... } }   // umgekehrte Reihenfolge!

Lösung: Locks immer in derselben Reihenfolge anfordern.

Klausur-Faustregeln

1. counter++ ist nicht atomar. Es ist read-modify-write (3 Schritte). Gemeinsamer veränderlicher Zustand plus mehrere Threads ergibt eine Race Condition.

2. synchronized = gegenseitiger Ausschluss. Nur ein Thread im Block oder in der Methode, über einen intrinsischen Lock (this bzw. das angegebene Objekt).

3. start() startet einen Thread, run() nicht. t.start() erzeugt einen neuen Thread (der run() ausführt). t.run() ist nur ein normaler Methodenaufruf im selben Thread.

4. join() wartet auf das Ende. Ohne join() läuft der aufrufende Thread (oft main) womöglich weiter, bevor die anderen fertig sind.

5. volatile sichert Sichtbarkeit, nicht Atomarität. Für sichtbaren, aber zusammengesetzten Zugriff (counter++) braucht es synchronized oder AtomicInteger.

6. Deadlock durch gegenläufige Lock-Reihenfolge. Zwei Threads, zwei Locks, umgekehrt angefordert, beide warten ewig. Vorbeugung: konsistente Lock-Reihenfolge.

Häufige Stolpersteine

1. t.run() statt t.start(). Startet keinen neuen Thread, alles läuft im aufrufenden Thread. Klassische Klausur-Falle.

2. Race Condition als "passiert schon nicht" abtun. Sie ist nicht-deterministisch: läuft tausendmal gut, dann unter Last plötzlich falsch. Schwer reproduzierbar, deshalb gefährlich.

3. volatile als Lock missverstehen. Es schützt nicht vor Race Conditions bei counter++, nur vor veralteten Werten. Atomarität braucht synchronized/Atomic*.

4. Über-Synchronisierung. Alles in einen großen synchronized-Block packen serialisiert komplett, dann hätte man auch single-threaded bleiben können. Nur den kritischen Abschnitt schützen.

5. Reihenfolge der Threads annehmen. Es gibt keine Garantie, welcher Thread wann läuft, das entscheidet der Scheduler. Code darf nicht von einer bestimmten Reihenfolge abhängen.

6. Vergessen, dass main auch ein Thread ist. Ohne join() kann main enden oder weiterlaufen, bevor die gestarteten Threads ihr Ergebnis geschrieben haben.

start() oder run()? Die Klausur-Falle

Derselbe Thread, zwei Aufrufe. Einer startet echte Nebenläufigkeit, der andere nicht. Achte im Stepper auf den Namen des ausführenden Threads in der Ausgabe, das verrät, ob ein neuer Thread entstanden ist.

Klausur-Tipp: Wenn eine Aufgabe fragt "wie viele Threads laufen?" oder "in welchem Thread läuft das?", suche nach start() (neuer Thread) versus run() (selber Thread). Und: ohne join() ist die Ausgabe-Reihenfolge mehrerer Threads nicht vorhersagbar.