Java Thread-Methoden: start, join, sleep, interrupt

Thread bietet viele Methoden, aber nur eine Handvoll davon ruft man in echtem Code tatsächlich auf. Dieses Kapitel geht diese Handvoll durch — was jede einzelne tut, was sie nicht tut, und welche Fehler korrekt aussehen, bis sie es nicht mehr sind. Die früheren Kapitel haben diese Methoden nur kurz erwähnt; hier werden sie einzeln festgehalten.

Diese Seite behandelt Thread-Lebenszyklus und -Steuerung: start vs. run, sleep, join, das kooperative Abbruchprotokoll mit interrupt, sowie die kleineren Hilfsmethoden (yield, currentThread, Benennung, Daemon-Status, Priorität, holdsLock, onSpinWait). Einen Gesamtüberblick darüber, wie ein Thread die Zustände NEW, RUNNABLE, BLOCKED, WAITING und TERMINATED durchläuft, findet man unter Java Thread Life Cycle.

`start()` vs. `run()`

Der häufigste Multithreading-Bug:

Thread t = new Thread(() -> work(), "worker");
t.run();                                      // wrong: runs work() on the CURRENT thread
t.start();                                    // right: spawns a new OS thread, returns immediately

start() ist die einzige Methode, die einen neuen OS-Thread erzeugt. run() ist der Rumpf der Arbeit — ihn direkt aufzurufen ist nur ein normaler Methodenaufruf, der zurückkehrt, wenn die Arbeit abgeschlossen ist. Wenn kein start() zu sehen ist, findet keine Parallelität statt.

start() ist außerdem nur einmal verwendbar. Nachdem run() zurückgekehrt ist, befindet sich der Thread im Zustand TERMINATED und kann nicht neu gestartet werden. Ein zweiter Aufruf von start() wirft eine IllegalThreadStateException.

`Thread.sleep(ms)`

Der statische Aufruf, der den aktuellen Thread für mindestens die angegebene Dauer anhält:

Thread.sleep(1500);                          // sleep 1.5 seconds
Thread.sleep(0, 250);                        // 250 nanoseconds; precision varies by OS
Thread.sleep(Duration.ofMillis(1500));       // Java 19+ overload

Drei wichtige Punkte:

Er wirft InterruptedException. Sleep ist unterbrechbar — so wird einem Worker mitgeteilt, dass er aufhören soll zu schlafen und sich beenden soll. Man entweder gibt die Exception weiter (mit throws deklarieren) oder fängt sie ab und setzt das Flag mit Thread.currentThread().interrupt() neu.
Er gibt keine Locks frei. Ein schlafender Thread hält jeden Lock, den er vorher gehalten hat. Ruft man Thread.sleep innerhalb eines synchronized-Blocks auf, betritt kein anderer Thread den Block, solange man schläft. Das ist fast immer ein Bug; verwende wait oder Condition.await (siehe Inter-thread Communication), wenn man den Lock freigeben muss.
Das Timing ist "mindestens", nicht "genau". Das OS könnte einen unter Last etwas zu spät aufwecken; früher wird man nie geweckt.

`t.join()` und `t.join(ms)`

Warten, bis ein anderer Thread beendet ist:

t.join();                                    // block until t terminates
t.join(2000);                                // block up to 2 seconds, then continue regardless
boolean done = t.join(Duration.ofSeconds(2));// Java 19+, returns whether it finished

join ist die Art, wie man mehrstufige parallele Arbeit zusammensetzt: ein paar Threads starten, laufen lassen, alle mit join zusammenführen, Ergebnisse lesen. join() kehrt zurück, wenn das run() des Ziel-Threads zurückgekehrt ist (ob normal oder durch Exception). Es wirft ebenfalls InterruptedException, sodass Aufrufer aus dem Warten unterbrochen werden können.

Ein subtiler Punkt: join(0) bedeutet "join ohne Timeout" (d. h. ewig warten), nicht "join mit Null-Timeout". Wenn man wirklich "sofort aufgeben" möchte, verwendet man stattdessen t.isAlive().

`t.interrupt()` und das Flag

Das kooperative Abbruchprotokoll in drei Aufrufen:

t.interrupt();                               // set t's interrupt flag (and unblock sleep/wait/join/park)
t.isInterrupted();                           // ask whether the flag is set (does NOT clear)
Thread.interrupted();                        // static; ask current thread, and CLEAR the flag

Das Flag ist nur ein volatile boolean auf dem Thread-Objekt. interrupt() setzt es. Befindet sich t gerade in sleep, wait, join oder LockSupport.park (oder vielen blockierenden java.nio-Aufrufen), wirft dieser blockierende Aufruf sofort eine InterruptedException. Andernfalls wartet das Flag darauf, dass der Worker es selbst bemerkt.

Ein Worker, der unterbrechbar sein möchte, hat zwei Verantwortlichkeiten:

Thread.currentThread().isInterrupted() zwischen lang laufenden Schritten prüfen.
In jedem catch (InterruptedException e) entweder die Exception weitergeben oder das Flag mit Thread.currentThread().interrupt() neu setzen — es niemals still schlucken.

while (!Thread.currentThread().isInterrupted()) {
  try {
    doOneUnit();
    Thread.sleep(100);
  } catch (InterruptedException e) {
    Thread.currentThread().interrupt();        // restore flag for the loop check
  }
}

`Thread.yield()` — fast nie das richtige Mittel

Thread.yield();                              // hint: please run someone else

Ein unverbindlicher Hinweis an den Scheduler. Das OS kann ihn ignorieren. Es gibt im Wesentlichen keinen Produktionscode, der yield benötigt — wenn man auf ein Ereignis warten will, verwendet man wait, eine Condition oder ein Semaphore. yield greift man nur für Mikro-Benchmarks, Deadlock-Test-Harnesses oder beim Schreiben der JVM selbst heraus.

`Thread.currentThread()`

Der statische Zugriff auf den Thread, auf dem der aufrufende Code läuft. Die zwei Verwendungsweisen, die man sieht:

String who = Thread.currentThread().getName();
Thread.currentThread().interrupt();          // re-arm the flag after catching InterruptedException

getName() ist auch der Standardweg, Log-Zeilen zu beschriften, damit man Threads in der Produktionsausgabe unterscheiden kann.

`getName` / `setName`

Namen sind wichtig für das Debugging. Der Standardname (Thread-3) ist in einem Thread-Dump nutzlos.

Thread t = new Thread(this::flush, "flush-loop");      // name at construction (preferred)
t.setName("flush-loop-2");                              // rename later if a role changes

Man kann jederzeit umbenennen, aber der Wert zum Zeitpunkt des Dumps oder Logs ist das, was der Leser sieht. Immer einen Namen an den Konstruktor übergeben.

`setDaemon(true)`

Thread t = new Thread(this::poll, "metrics-poller");
t.setDaemon(true);                           // BEFORE start(); else IllegalThreadStateException
t.start();

Daemon-Threads halten die JVM nicht am Leben — wenn der letzte Nicht-Daemon-Thread beendet wird, reißt die JVM die Daemons einfach heraus. Man verwendet sie für Haushaltsarbeiten, die mit dem Programm sterben sollen (Timer, Metrik-Flusher, Polling-Schleifen). Man verwendet sie nicht für Arbeit, deren Abschluss man tatsächlich braucht.

`setPriority(int)`

t.setPriority(Thread.MAX_PRIORITY);          // 10
t.setPriority(Thread.MIN_PRIORITY);          // 1
t.setPriority(Thread.NORM_PRIORITY);         // 5 (default)

Größtenteils beratend. Das nächste Kapitel behandelt Prioritäten im Detail; vorerst das Wichtigste: Man verlässt sich nicht auf sie für Korrektheit, das OS entscheidet, was sie bedeuten.

`Thread.holdsLock(obj)`

Eine statische Debug-Hilfsmethode:

assert Thread.holdsLock(monitor) : "expected to be inside a synchronized block on monitor";

Gibt true zurück, wenn der aufrufende Thread den intrinsischen Monitor von obj hält. Nützlich, um zu behaupten "diese Methode darf nur von innerhalb eines synchronized-Blocks aufgerufen werden", ohne auf dem Happy-Path Lock-Akquisitionskosten zu zahlen.

`Thread.onSpinWait()` — Java 9+

while (!done) {
  Thread.onSpinWait();                       // hint to the CPU: I'm spinning, slow down
}

Ein Hinweis auf CPU-Ebene, der Pipelines pausiert und den Stromverbrauch während einer engen Spin-Schleife reduziert. Es ist speziell für den sehr engen Fall gedacht, in dem man einige Mikrosekunden dreht und darauf wartet, dass ein anderer Thread ein Flag kippt; es ist kein allgemeines "CPU aufgeben"-Signal. Für alles Längere verwendet man LockSupport.park oder eine Condition.

Ein praktisches Beispiel: die meisten davon an einem Ort

Das Programm unten verwendet start, join mit Timeout, interrupt, sleep, isInterrupted und setName zusammen — die Methoden, die man in der Produktion tatsächlich aufrufen würde.

java— editable, runs on the server

public class ThreadMethodsDemo {
  public static void main(String[] args) throws InterruptedException {
    // 1. start vs run
    Thread bad = new Thread(() ->
        System.out.println("   bad.run() ran on: " + Thread.currentThread().getName()),
        "bad");
    System.out.println("1. calling bad.run() directly:");
    bad.run();                                          // executes on main, NOT a new thread
    System.out.println("   bad.isAlive()? " + bad.isAlive());

Thread good = new Thread(() ->
        System.out.println("   good.run() ran on: " + Thread.currentThread().getName()),
        "good");
    System.out.println("\n   calling good.start():");
    good.start();
    good.join();

// 2. join with a timeout
    System.out.println("\n2. join with timeout:");
    Thread slow = new Thread(() -> {
      try { Thread.sleep(2000); }
      catch (InterruptedException e) { Thread.currentThread().interrupt(); }
    }, "slow");
    slow.start();
    long t0 = System.nanoTime();
    slow.join(300);                                     // wait at most 300 ms
    long waited = (System.nanoTime() - t0) / 1_000_000;
    System.out.println("   waited ~" + waited + " ms; slow still alive? " + slow.isAlive());

// 3. cooperative interrupt
    System.out.println("\n3. interrupting 'slow':");
    slow.interrupt();
    slow.join();
    System.out.println("   slow now alive? " + slow.isAlive());

// 4. swallowed interrupt vs re-armed interrupt
    System.out.println("\n4. interrupt-flag bookkeeping:");
    Thread bookkeeper = new Thread(() -> {
      try { Thread.sleep(2000); }
      catch (InterruptedException e) {
        Thread.currentThread().interrupt();             // re-arm so the rest of the code can see it
      }
      System.out.println("   inside worker, isInterrupted()? "
          + Thread.currentThread().isInterrupted());
    }, "bookkeeper");
    bookkeeper.start();
    Thread.sleep(50);
    bookkeeper.interrupt();
    bookkeeper.join();

// 5. yield (rarely matters; here just to show the call exists)
    System.out.println("\n5. Thread.yield() — a hint, not a guarantee");
    Thread.yield();

// 6. daemon set BEFORE start
    System.out.println("\n6. daemon thread:");
    Thread daemon = new Thread(() -> {
      try { Thread.sleep(60_000); }
      catch (InterruptedException ignored) {}
      System.out.println("   daemon woke up (won't be printed)");
    }, "housekeeping");
    daemon.setDaemon(true);                             // must be set before start()
    daemon.start();
    System.out.println("   main is finished; JVM exits because the only remaining thread is a daemon");
  }
}

Was man aus dem Ablauf mitnehmen kann:

Die Zeile bad.run() hat ran on: main ausgegeben. Es wurde kein neuer Thread erstellt. bad.isAlive() war danach false, weil start() nie aufgerufen wurde. Jedes Multithreading-Programm hat diesen Bug irgendwann; wenn man ihn einmal gemacht hat, macht man ihn nie wieder.
Das slow.join(300) ist nach etwa 300 ms zurückgekehrt, obwohl slow 2000 ms geschlafen hätte. isAlive() war noch true. join(ms) ist das zeitbegrenzte Warten — nützlich, wenn man einem Worker eine faire Chance geben will, fertig zu werden, bevor man eskaliert.
slow.interrupt() hat seinen Thread.sleep sofort durch Werfen einer InterruptedException im Worker beendet. Das ist der Vertrag: unterbrechbare blockierende Aufrufe reagieren auf interrupt(), indem sie mit der Exception aussteigen — so funktioniert kooperatives Abbrechen in der Praxis.
Der bookkeeper-Worker hat InterruptedException gefangen und das Flag mit Thread.currentThread().interrupt() neu gesetzt. Das nachfolgende isInterrupted() hat true zurückgegeben. Ohne dieses Neusetzen geht das Flag verloren und jeder Code weiter oben im Call-Stack denkt, es sei nie ein Interrupt passiert.
daemon.setDaemon(true) wurde vor start() aufgerufen — danach hätte es eine IllegalThreadStateException geworfen. Und als main zurückkehrte, wurde der Daemon mitten im Schlaf beendet; die JVM ist beendet, weil kein Nicht-Daemon-Thread mehr vorhanden war. Das ist der Daemon-Kompromiss: blockiert niemals den JVM-Exit, hat niemals eine Garantie auf Fertigstellung.

Was kommt als Nächstes

Das nächste Kapitel, Java Thread Priority, behandelt die setPriority-Methode auf Thread, was die Prioritäten auf echten Betriebssystemen tatsächlich tun, und warum man sie eher als Hinweis denn als Garantie behandeln sollte.

Übungen

Übung

Du fängst `InterruptedException` in einem Worker, willst aber nicht aus der Schleife herauswerfen. Was solltest du mit dem Interrupt-Flag tun?

Rufe `Thread.currentThread().interrupt()` auf, um das Flag neu zu setzen, damit Code weiter oben im Call-Stack den Interrupt noch siehtNichts — `InterruptedException` wurde gefangen, die Abbruchanforderung ist jetzt erledigtRufe `Thread.interrupted()` auf, um zu bestätigen, dass das Flag gelöscht ist, da `catch` es bereits gelöscht hatWirf eine `RuntimeException`, damit der Thread stirbt — das ist die einzige Möglichkeit, den Abbruch zu ehren

start() vs. run()

Thread.sleep(ms)

t.join() und t.join(ms)

t.interrupt() und das Flag

Thread.yield() — fast nie das richtige Mittel

Thread.currentThread()

getName / setName

setDaemon(true)

setPriority(int)

Thread.holdsLock(obj)

Thread.onSpinWait() — Java 9+