JetBrains bietet in einem am 27. August 2026 veröffentlichten Blogbeitrag eine praxisnahe Betrachtung von drei Komponenten von Project Loom in IntelliJ IDEA: Virtual Threads, Scoped Values und Structured Concurrency. Die grundlegende Idee besteht nicht darin, voneinander getrennte Programmierschnittstellen hinzuzufügen, sondern drei miteinander verbundene Probleme in nebenläufigen Java-Anwendungen zu lösen: Skalierbarkeit, die Weitergabe des Kontexts sowie die Verwaltung des Lebenszyklus und der Fehler von Threads.
Der Beitrag erläutert, dass das Schreiben von Multithread-Code weiterhin anfällig für Thread-Leaks, verschluckte Ausnahmen, Race Conditions und verspätete Abbrüche ist. Auch die traditionelle Abhängigkeit von Thread-Pools und CompletableFuture kann dazu führen, dass die Logik für Abbrüche und Fehlerbehandlung auf mehrere Zweige verteilt wird. Dadurch steigt die Wahrscheinlichkeit, dass sie beim Hinzufügen einer neuen nebenläufigen Aufgabe nicht aktualisiert wird.
Virtuelle Threads senken die Kosten des Wartens
Virtuelle Threads basieren auf JEP 444 und sind seit Java 21 stabil. Im Gegensatz zu Plattform-Threads, die an Betriebssystem-Threads gebunden sind, werden virtuelle Threads von der JVM verwaltet und können mit deutlich geringeren Kosten erstellt werden. JetBrains weist darauf hin, dass die Erstellung eines virtuellen Threads Mikrosekunden statt Millisekunden dauert und der Thread den Plattform-Thread freigibt, wenn er auf eine Datenbank, eine Netzwerkverbindung, eine Datei oder einen Synchronisationsmechanismus wartet.
Das macht sie besonders für Workloads geeignet, die auf blockierenden Vorgängen beruhen, da der Bedarf sinkt, die Größe von Thread-Pools im Voraus festzulegen. Der Beitrag erwähnt außerdem, dass Java 24 mit JEP 491 eine Verbesserung eingeführt hat, durch die blockierte virtuelle Threads innerhalb von synchronized-Methoden oder -Anweisungen den Plattform-Thread freigeben können, anstatt ihn zu blockieren.
Gemeinsamer Kontext ohne ThreadLocal-Probleme
Scoped Values, die gemäß JEP 506 seit Java 25 stabil sind, behandeln ein anderes Problem. Anwendungen müssen häufig Daten wie eine Sitzungs-ID oder eine Trace-ID an mehrere Teile einer Anfrage weitergeben. Dies geschah üblicherweise über ThreadLocal, dessen Werte jedoch veränderbar sind und an die Lebensdauer des Threads gebunden bleiben, sofern sie nicht manuell entfernt werden. Das kann zu Speicherlecks oder Sicherheitsproblemen führen. JetBrains weist darauf hin, dass Frameworks wie Spring ThreadLocal intern verwenden können, selbst wenn der Entwickler es nicht direkt nutzt.
ScopedValue bietet ein Modell, bei dem der Wert einmal innerhalb eines bestimmten Gültigkeitsbereichs gebunden und anschließend dem darin ausgeführten Code automatisch zur Verfügung gestellt wird. Nach Ende des Gültigkeitsbereichs wird er bereinigt. Die Bindung kann innerhalb des Gültigkeitsbereichs nicht geändert werden, und bei der Verwendung mit strukturierter Nebenläufigkeit wird der Wert an untergeordnete Aufgaben weitergegeben, ohne dass der Kontext explizit übergeben werden muss. In der Praxis reduziert dies die Zahl der Kontrollpunkte, die der Entwickler bei der Ausführung paralleler Aufgaben im Blick behalten muss.
Strukturierte Nebenläufigkeit verbindet Aufgaben mit einer klaren Lebensdauer
Structured Concurrency, die auf JEP 533 basiert, zielt auf strukturelle Probleme in nebenläufigem Code. Sie befindet sich jedoch in Java 27 weiterhin in der siebten Preview und wird von JetBrains daher derzeit nicht für den Einsatz in Produktionsumgebungen empfohlen. Das Konzept besteht darin, eine Gruppe verbundener Aufgaben als eine einzige Arbeitseinheit zu behandeln, die einen Besitzer, eine Lebensdauer und eine klare Fehlerstrategie besitzt.
Im von JetBrains vorgestellten Beispiel ruft die Anwendung parallel die Bestellungen eines Kunden und Produktempfehlungen ab, um ein Kundenprofil zu erstellen. Mit StructuredTaskScope lassen sich ein Zeitlimit von zwei Sekunden festlegen, der erfolgreiche Abschluss beider Aufgaben verlangen und die jeweils andere Aufgabe automatisch abbrechen, wenn eine von ihnen fehlschlägt oder das Zeitlimit abläuft. Statt cancel()-Aufrufe in Zweigen der Ausnahmebehandlung zu wiederholen, wird die Abbruchstrategie zu einem Bestandteil des Aufgabengültigkeitsbereichs.
Der Beitrag erläutert außerdem einen anderen Fall, in dem nicht alle Aufgaben erfolgreich sein müssen: Wenn die Anwendung Empfehlungen aus zwei Caches bezieht und die erste erfolgreiche Antwort genügt, kann anySuccessfulOrThrow() verwendet werden. Sobald ein erfolgreiches Ergebnis eintrifft, wird der Gültigkeitsbereich geschlossen und die andere Aufgabe automatisch abgebrochen. Schlagen beide Aufgaben fehl, wird eine Ausnahme ausgelöst, die den Grund des Fehlschlags angibt.
Was ändert sich innerhalb von IntelliJ IDEA?
Der Nutzen beschränkt sich nicht auf die Syntax des Codes. Seit IntelliJ IDEA 2026.1 werden virtuelle Threads, die innerhalb von StructuredTaskScope erstellt werden, in Containern zusammengefasst, die ihre Gültigkeitsbereiche darstellen. Dadurch wird die Beziehungsstruktur zwischen der übergeordneten Aufgabe und den untergeordneten Aufgaben im Debugger sichtbar. Der Thread Dump zeigt somit nicht nur eine flache Liste von Threads aus einem allgemeinen Pool, sondern liefert einen besseren Hinweis darauf, welche Aufgaben zu derselben Anfrage gehören.
Um diese Funktionen auszuprobieren, benötigt der Entwickler Java 27, das dem Beitrag zufolge eine Early-Access-Version ist, sowie die Einstellung des Sprachlevels zur Verwendung der Preview-Funktionen. IntelliJ IDEA ermöglicht das Herunterladen eines JDK über die Projekteinstellungen und zeigt integrierte Hinweise an, wenn Tools wie SDKMAN! oder asdf zur Verwaltung von JDK-Versionen verwendet werden. Eine Grundstruktur für StructuredTaskScope kann mit der Live-Vorlage sts erstellt werden.
Die redaktionelle Einordnung von certi.news
Die eigentliche Veränderung besteht darin, dass ein Teil der Verwaltung von Nebenläufigkeit aus der manuellen Verantwortung des Entwicklers in ein Modell übergeht, in dem die Struktur des Codes die Lebensdauer der Aufgabe und ihre Fehlerstrategie ausdrückt. Virtual Threads behandeln die Kosten der Skalierung, Scoped Values regeln die Weitergabe des Kontexts, während Structured Concurrency versucht, Abbrüche und die Weitergabe von Fehlern vorhersehbar zu machen. Das Zusammenspiel dieser Funktionen kann redundanten Code in Anwendungen reduzieren, die mehrere Wartevorgänge parallel ausführen.
Die Grenzen der Entwicklung sind jedoch deutlich: Structured Concurrency ist noch nicht stabil, und Java 27 war zum Zeitpunkt der Veröffentlichung des Beitrags eine Early-Access-Version. Der Blogbeitrag belegt daher nicht, dass jede Anwendung automatisch eine Verbesserung erzielen wird, und macht Tests des Verhaltens der verwendeten Bibliotheken und Frameworks mit diesen Modellen nicht überflüssig. Der aktuelle Wert für Entwickler besteht darin, das Muster zu verstehen und sicher auszuprobieren, während experimentelle Funktionen bis zur Stabilisierung ihrer Schnittstellen und dem Vorliegen ausreichender Betriebserfahrung außerhalb der Produktion bleiben sollten.