Virtuelle Threads in Java im Überblick: was sich ändert und was nicht

Worum es geht

JEP 444 beschreibt einen virtuellen Thread als eine Instanz von java.lang.Thread, die nicht eins zu eins an einen Betriebssystem-Thread gebunden ist. Ein Scheduler (ein ForkJoinPool im FIFO-Modus, dessen Parallelität standardmässig der Anzahl verfügbarer Prozessoren entspricht) montiert einen virtuellen Thread auf einen Platform-Thread, seinen Carrier; blockiert der virtuelle Thread bei I/O oder einer anderen blockierenden JDK-Operation, hängt er aus, und der Carrier übernimmt andere Arbeit. Stacks liegen als Stack-Chunk-Objekte im Heap und wachsen und schrumpfen. Thread.ofVirtual(), Thread.startVirtualThread(r) und Executors.newVirtualThreadPerTaskExecutor() erzeugen sie, und sie sind stets Daemon-Threads. Der JEP stellt ausdrücklich klar, dass virtuelle Threads keine schnelleren Threads sind: Sie liefern Skalierung (Durchsatz), nicht Geschwindigkeit (Latenz), und CPU-gebundene Arbeit gewinnt nichts davon, mehr davon zu haben, als es Kerne gibt.

Warum es wichtig ist

Für Entwicklerinnen und Entwickler, die von Go oder von C#-async kommen, liegt der Punkt darin, dass Java den Thread-pro-Anfrage-Stil beibehält, einschliesslich Schleifen, try/catch und gewöhnlicher blockierender JDBC- oder HTTP-Aufrufe, während die Obergrenze bei OS-Threads entfällt, die Code früher in reaktive oder CompletableFuture-Pipelines drängte. Code, der auf ExecutorService aufbaut, migriert durch Austauschen des Executors, weshalb der JEP Executors.newThreadPerTaskExecutor neben der Virtual-Thread-Factory anbietet.

So wird es angewendet

• Virtuelle Threads nicht poolen; pro Aufgabe einen erzeugen. Um die Parallelität gegenüber einer nachgelagerten Ressource zu begrenzen, ein Semaphore verwenden, das sowohl der JEP als auch der Core-Libraries-Leitfaden als vorgesehenes Konstrukt nennen.
• Die Verwendung von ThreadLocal überprüfen: Ein thread-lokaler Cache für ein teures Objekt, sinnvoll in einem Pool von fünfzig Threads, wird bei virtuellen Threads pro Anfrage neu erzeugt. Der JEP verweist auf Scoped Values als Alternative.
• Pinning prüfen: In JDK 21 pinnt ein virtueller Thread, der innerhalb eines synchronized-Blocks oder einer solchen Methode oder innerhalb eines nativen Frames blockiert, seinen Carrier. -Djdk.tracePinnedThreads=full und das JFR-Ereignis jdk.VirtualThreadPinned (standardmässig aktiviert mit einem Schwellenwert von 20 ms) zeigen, wo. JEP 491 in JDK 24 entfernt das Pinning für synchronized und Object.wait() und lässt die Property jdk.tracePinnedThreads fallen (das JFR-Ereignis bleibt bestehen); native Frames, Klassenladen und Klasseninitialisierer pinnen weiterhin.
• Damit rechnen, dass flache Thread-Dumps bei einer Million Threads nutzlos sind; der JEP fügt jcmd <pid> Thread.dump_to_file -format=json hinzu.
• Platform-Threads für CPU-gebundene Schleifen und für Arbeit, die nie blockiert, beibehalten.

Stolpersteine

Manche blockierenden Operationen (viele Dateisystemaufrufe, Object.wait() vor JDK 24) belegen den OS-Thread dauerhaft; der Scheduler gleicht das vorübergehend aus, bis zu jdk.virtualThreadScheduler.maxPoolSize. Bibliotheken, die Monitore um I/O herum halten, begrenzen die Skalierung, bis sie aktualisiert werden. Frameworks müssen dies aktiv unterstützen; ein Server, der weiterhin einen festen Platform-Thread-Pool nutzt, sieht keine Änderung. Structured Concurrency, ein separater JEP, ist der vorgesehene Weg, um Gruppen virtueller Threads zu verwalten.