Was sind Virtual Threads, und wie verändern sie die Art, wie du Server-Code schreibst?

Virtual Threads, final seit Java 21, sind leichtgewichtige Threads, die von der JVM auf einen kleinen Pool von Carrier Threads geschedult werden. Blockiert einer auf I/O, wird er ausgehängt und gibt seinen Carrier frei, deshalb kosten eine Million gleichzeitige Tasks fast nichts. Praktisch heißt das: du schreibst wieder geradlinigen blockierenden Code und nimmst einen Thread pro Request statt eines Executors mit festem Pool, und du poolst Virtual Threads nie, weil das Erzeugen billig ist.

Ein Virtual Thread wird von der JVM geschedult und nicht vom Betriebssystem, deshalb kostet er ein paar hundert Byte statt einem Megabyte Stack. Blockiert er auf einem Socket-Read, hängt er sich von seinem Carrier Platform Thread aus, der Carrier läuft weg und macht etwas anderes, und wenn die Daten da sind, hängt er sich wieder ein. Damit fällt der alte Grund fürs Thread-Pooling weg. Ich nehme einen Executor, der pro Task einen Virtual Thread erzeugt, und der Code bleibt schlichter blockierender Code, der sich viel leichter lesen und debuggen lässt als eine Kette von Callbacks. Zwei Dinge behalte ich im Kopf. Erstens bringen sie bei CPU-lastiger Arbeit nichts, du hast immer noch nur so viele Kerne, wie du hast; der Gewinn liegt bei I/O-lastiger Request-Verarbeitung. Zweitens nehmen sie mir das versehentliche Nebenläufigkeitslimit weg, das ein fester Pool früher gegeben hat. Wenn ich also eine Datenbank mit einem Pool von fünfzig Verbindungen anspreche, setze ich eine Semaphore oder den Pool selbst davor, sonst stürzen sich zehntausend Virtual Threads auf einmal darauf.