Was änderte sich bei Durchsatz, Speicher und Pinning-Vorfällen, nachdem ein JVM-Dienst auf virtuelle Threads umgestellt wurde, und was musste neu geschrieben werden?

Offene Frage

JEP 444 führte virtuelle Threads in Java 21 ein und beschreibt die Situationen, in denen ein virtueller Thread an seinen Carrier gepinnt wird, etwa während der Ausführung innerhalb eines synchronized-Blocks; es hält fest, dass Pinning eine Anwendung nicht fehlerhaft macht, aber ihre Skalierbarkeit behindern kann. JEP 491, ausgeliefert in JDK 24, ändert die Implementierung von synchronized so, dass virtuelle Threads, die dort blockieren, ihren Carrier freigeben. Die Design-Absicht ist klar: Ein Thread-pro-Anfrage-Server muss keinen Platform-Thread-Pool mehr dimensionieren und kann jede Anfrage auf ihrem eigenen günstigen Thread laufen lassen. Was dem Wiki fehlt, ist, was tatsächlich geschah, als reale Dienste diesen Wechsel vollzogen.

Für einen Dienst, der seine Anfragebehandlung oder seine ausgehenden Aufrufe von einem begrenzten Platform-Thread-Pool auf virtuelle Threads umgestellt hat: Stieg der Durchsatz bei gleicher Hardware, blieb er gleich, oder fiel er, und bei welchem Parallelitätsgrad? Was geschah mit Heap- und Off-Heap-Speicher, als die Zahl gleichzeitig laufender Anfragen nicht mehr durch einen Pool gedeckelt war? Welche Vorfälle folgten: Carrier-Pinning unter einem synchronized-Block in einer Treiber- oder Logging-Bibliothek, Erschöpfung eines nachgelagerten Connection-Pools, der früher durch die Grösse des Thread-Pools geschützt war, thread-lokale Caches, die sich mit Tausenden von Threads vervielfachten, oder Deadlocks, die der alte Pool maskiert hatte? Welche Bibliotheken mussten aktualisiert oder ersetzt werden, und reichte die Änderung in JDK 24 aus, um die Pinning-Workarounds zu entfernen? Behielt das Team irgendwo ein begrenztes Semaphor, um den Backpressure zu ersetzen, den früher der Pool lieferte, und wie wurde dessen Grösse gewählt?

Die Antwort ist wichtig, weil die Migration oft als blosses Umlegen eines Schalters dargestellt wird, während der dadurch entfernte Pool mehr als eine Aufgabe erfüllt hat.

Was eine nützliche Antwort enthält

Die JDK-Version vorher und nachher, das Framework und den Server, die Treiber und Clients im Anfragepfad, und die Arbeitslast (Anfragerate, Verhältnis von I/O-Wartezeit zu CPU). Durchsatz und Latenz-Perzentile unter gleicher Last vorher und nachher, mit der Methode der Lasterzeugung und der Anzahl Durchläufe. Speichermessungen (Heap, Metaspace, nativ) bei gleicher Last. Eine Liste beobachteter Pinning-Ereignisse (die JDK kann diese melden) mit der verantwortlichen Bibliothek und der Behebung. Der Migration zugeschriebene Vorfälle, mit dem Mechanismus. Erforderliche Codeänderungen, insbesondere Ersatz für poolbasierten Backpressure und thread-lokalen Zustand. Ein Bericht, der keinen messbaren Unterschied fand, ist ebenso nützlich wie einer, der einen grossen fand, sofern Last und Messmethode angegeben sind.