Java Threads verstehen: Plattform-Threads, Virtual Threads und sichere Nebenläufigkeit

Von Guido Zeuner · Softwareentwickler und Autor von tiny-tool.de

Threads ermöglichen mehreren Aufgaben, innerhalb eines Java-Prozesses nebenläufig zu arbeiten. Entscheidend ist dabei nicht nur, wie du einen Thread startest, sondern wie du Aufgaben trennst, gemeinsamen Zustand schützt und zwischen Plattform- und Virtual Threads auswählst.

Nebenläufigkeit wird schnell missverständlich: Zwei Aufgaben können sich zeitlich überlappen, ohne in jedem Moment wirklich parallel auf verschiedenen Prozessorkernen zu laufen. Gleichzeitig bringt das Teilen von Daten neue Fehlerklassen mit sich. Dieser Guide führt deshalb vom ersten Thread über Zustände und Synchronisation bis zu Executor Services, Virtual Threads und einem kurzen Kotlin-Vergleich.

Prozess, Thread und Nebenläufigkeit

Ein laufendes Java-Programm ist ein Prozess. Innerhalb dieses Prozesses können mehrere Threads existieren. Jeder Thread besitzt unter anderem einen eigenen Aufrufstapel, aber die Threads eines Prozesses teilen sich den Heap. Dadurch können sie dieselben Objekte sehen und verändern.

Dieses gemeinsame Arbeiten ist leistungsfähig, aber nicht automatisch sicher. Wenn zwei Threads denselben Wert gleichzeitig lesen und schreiben, kann das Ergebnis von der zufälligen zeitlichen Reihenfolge abhängen. Solche Fehler sind häufig schwer reproduzierbar.

Mehr Threads bedeuten nicht automatisch mehr Geschwindigkeit. Bei CPU-intensiver Arbeit begrenzen die verfügbaren Kerne den sinnvollen Parallelismus; zu viele Plattform-Threads erzeugen zusätzlich Verwaltungs- und Kontextwechselkosten.

Die Zustände eines Java-Threads

Die JVM beschreibt den Zustand eines Threads mit Thread.State. Diese Zustände sind JVM-Zustände und nicht identisch mit den Zuständen, die ein Betriebssystem intern verwendet.

Einen Thread richtig starten

Für eine einzelne Aufgabe genügt ein Runnable. Da es ein funktionales Interface ist, kannst du eine Lambda-Expression verwenden. Der moderne Thread-Builder macht zugleich sichtbar, ob du einen Plattform- oder Virtual Thread erzeugst.

public class ThreadStartDemo {
    public static void main(String[] args) throws InterruptedException {
        Runnable task = () -> System.out.println(
                "Läuft in: " + Thread.currentThread().getName());

        Thread worker = Thread.ofPlatform()
                .name("report-worker")
                .start(task);

        worker.join();
        System.out.println("Aufgabe beendet");
    }
}

Der Haupt-Thread wartet mit join(), bis worker beendet ist. Ohne dieses Warten kann die Reihenfolge der Ausgaben variieren. Ein nicht gestarteter Thread kann nur einmal mit start() gestartet werden.

start(), run() und join()

Gemeinsamen Zustand sicher behandeln

Die Operation counter++ besteht aus Lesen, Erhöhen und Schreiben. Zwei Threads können denselben alten Wert lesen und anschließend beide denselben neuen Wert speichern. Ein Update geht dann verloren. Das Schlüsselwort volatile macht eine zusammengesetzte Operation nicht atomar.

import java.util.concurrent.atomic.AtomicInteger;

public final class RequestCounter {
    private final AtomicInteger value = new AtomicInteger();

    public int incrementAndGet() {
        return value.incrementAndGet();
    }

    public int currentValue() {
        return value.get();
    }
}

AtomicInteger passt zu einfachen atomaren Aktualisierungen. Sobald mehrere Werte gemeinsam eine Invariante bilden, brauchst du meist eine umfassendere Strategie.

• Unveränderlichkeit: Geteilte Objekte können nach ihrer Konstruktion nicht mehr verändert werden.
• Thread-Beschränkung: Veränderlicher Zustand gehört genau einem Thread.
• synchronized oder Lock: Zusammengehörige Zugriffe werden als kritischer Abschnitt geschützt.
• Concurrent Collections: Klassen wie ConcurrentHashMap stellen geeignete atomare Operationen bereit.

Aufgaben mit ExecutorService ausführen

Direkt erzeugte Threads sind für Lernbeispiele hilfreich. In Anwendungen sollte der Code, der eine Aufgabe beschreibt, aber häufig nicht selbst entscheiden, wie viele Threads entstehen. Ein ExecutorService trennt Einreichen, Ausführen und Beenden von Aufgaben.

import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
import java.util.concurrent.Future;

public class ExecutorDemo {
    public static void main(String[] args) throws Exception {
        try (ExecutorService executor = Executors.newFixedThreadPool(4)) {
            Future result = executor.submit(() -> 21 * 2);

            System.out.println(result.get()); // 42
        }
    }
}

Runnable liefert kein Ergebnis. Callable darf dagegen einen Wert zurückgeben und eine Exception auslösen. Future.get() wartet auf das Ergebnis und macht einen Fehlschlag über eine ExecutionException sichtbar.

Ein ExecutorService ist AutoCloseable. Der try-with-resources-Block leitet deshalb ein geordnetes Herunterfahren ein. Bei langlebigen Diensten gehört die Lebensdauer des Executors zur Lebensdauer der Anwendungskomponente.

Virtual Threads sinnvoll einsetzen

Java kennt Plattform-Threads und Virtual Threads. Ein Plattform-Thread ist typischerweise eng an einen Betriebssystem-Thread gebunden. Ein Virtual Thread wird von der Java-Laufzeit verwaltet und kann beim blockierenden Warten von seinem sogenannten Carrier Thread gelöst werden.

Dadurch kann eine Anwendung sehr viele überwiegend wartende Aufgaben in einem einfachen Thread-pro-Aufgabe-Stil ausführen. Das erhöht bei passenden Server-Workloads den Durchsatz, nicht automatisch die Geschwindigkeit einer einzelnen Anfrage.

import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;

public class VirtualThreadDemo {
    public static void main(String[] args) throws Exception {
        try (ExecutorService executor =
                     Executors.newVirtualThreadPerTaskExecutor()) {

            var first = executor.submit(() -> loadCustomer(17));
            var second = executor.submit(() -> loadOrders(17));

            System.out.println(first.get());
            System.out.println(second.get());
        }
    }

    private static String loadCustomer(int id) {
        return "Customer " + id; // Stellvertretend für blockierende I/O
    }

    private static String loadOrders(int customerId) {
        return "Orders for " + customerId;
    }
}

Virtual Threads sind kein größerer Thread-Pool. Sie sollten normalerweise nicht gepoolt werden. Begrenze stattdessen ausdrücklich die knappe Zielressource, etwa über einen Semaphore für eine externe Schnittstelle.

Unterbrechung und kooperativer Abbruch

interrupt() beendet einen Thread nicht gewaltsam. Es setzt ein Unterbrechungssignal. Blockierende Methoden wie sleep(), join() oder viele Queue-Operationen reagieren darauf mit InterruptedException.

try {
    processNextItem();
} catch (InterruptedException e) {
    Thread.currentThread().interrupt();
    return;
}

Kann die Methode die Exception nicht weitergeben, stellt sie den Interrupt-Status in der Regel wieder her. Dadurch können aufrufende Ebenen erkennen, dass ein Abbruch gewünscht ist. Die veralteten Methoden stop(), suspend() und resume() sind keine sichere Alternative.

Daemon Threads und Programmende

Die JVM beginnt mit dem Herunterfahren, wenn alle gestarteten Non-Daemon-Plattform-Threads beendet sind. Daemon-Threads sind deshalb nur für unterstützende Arbeit geeignet, die beim Programmende nicht zuverlässig abgeschlossen werden muss. Virtual Threads sind immer Daemon-Threads.

Java und Kotlin: Threads und Coroutines

Kotlin läuft auf der JVM und kann dieselben Java-Thread- und Executor-APIs verwenden. Die Standardbibliothek bietet mit kotlin.concurrent.thread eine kompakte Hilfsfunktion. Häufiger setzen Kotlin-Anwendungen jedoch Coroutines ein.

Eine Coroutine ist nicht einfach ein anderer Name für einen JVM-Thread. Coroutines werden durch eine Bibliothek geplant und können suspendieren, ohne einen Thread zu blockieren. Virtual Threads bleiben dagegen vollständige Thread-Objekte mit den bekannten Java-Regeln.

Best Practices und typische Anti-Patterns