Du hast einen bestehenden Service auf einem Pool mit zweihundert Threads, der die meiste Zeit auf Downstream-Calls wartet. Würdest du ihn auf Virtual Threads umstellen, und wie?

Ja, wenn die Arbeit blockierendes I/O ist und nicht CPU-lastig. Stell den Server und alle Task-Executors auf einen Executor um, der pro Task einen Virtual Thread erzeugt, und nimm dann die Annahmen weg, die der alte Pool geliefert hat: setz explizite Limits auf die Downstream-Nebenläufigkeit mit Semaphoren oder Connection Pools, prüf synchronized-Blöcke und native Calls, die einen Carrier pinnen können, und schau dir die Nutzung von Thread Locals an. Roll es hinter einem Flag aus und vergleich Durchsatz und Tail-Latenz.

Wenn die Threads überwiegend geparkt auf HTTP- oder Datenbank-Calls warten, dann ja, denn zweihundert Threads sind auch zweihundert gleichzeitige Requests, und alles andere staut sich dahinter. Die Änderung selbst ist klein: den Webserver auf Virtual Threads laufen lassen und Task-Executors gegen einen tauschen, der pro Task einen Virtual Thread erzeugt. Die Arbeit steckt in dem, was der Pool implizit gemacht hat. Er war ein Nebenläufigkeitslimit, sobald das weg ist, können also plötzlich zehntausend Requests auf eine Datenbank mit einem Pool von fünfzig Verbindungen einprasseln, und statt einer Warteschlange am Thread-Pool bekomme ich Timeouts am Connection Pool. Ich setze die expliziten Limits also dorthin, wo sie hingehören, meist eine bewusst dimensionierte Semaphore pro Downstream-Abhängigkeit. Dann prüfe ich auf Pinning, was auf neueren Versionen deutlich weniger Thema ist, weil synchronized nicht mehr pinnt, native Calls aber schon. Ich schaue außerdem, ob Thread Locals etwas Großes halten, denn Caches pro Thread, die über zweihundert Threads in Ordnung waren, sind es über hunderttausend nicht. Danach fahre ich den Traffic hinter einem Flag hoch und beobachte die Tail-Latenz, nicht nur den Durchsatz.