Vous avez un service existant sur un pool de deux cents threads qui passe l'essentiel de son temps à attendre des appels en aval. Le feriez-vous passer aux threads virtuels, et comment ?

Oui, si le travail est bloquant en entrées/sorties plutôt que limité par le CPU. Passez le serveur et les executors de tâches à un executor qui crée un thread virtuel par tâche, puis retirez les hypothèses que l'ancien pool fournissait : ajoutez des limites explicites de concurrence en aval avec des sémaphores ou des pools de connexions, auditez les blocs synchronized et les appels natifs qui peuvent épingler un porteur, et vérifiez l'usage des ThreadLocal. Déployez derrière un drapeau et comparez le débit et la latence de queue.

Si les threads sont surtout en attente sur des appels HTTP ou base de données, oui, parce que deux cents threads, c'est aussi deux cents requêtes concurrentes, et tout le reste fait la queue derrière. Le changement en lui-même est petit : faire tourner le serveur web sur des threads virtuels et remplacer les executors de tâches par un executor qui crée un thread virtuel par tâche. Le vrai travail porte sur ce que le pool faisait implicitement. C'était une limite de concurrence, donc une fois qu'elle disparaît je peux d'un coup avoir dix mille requêtes qui tapent une base avec un pool de cinquante connexions, et au lieu d'une file d'attente au pool de threads j'obtiens des expirations au pool de connexions. Donc je remets des limites explicites là où elles ont leur place, en général un sémaphore par dépendance en aval, dimensionné délibérément. Ensuite j'audite le pinning, beaucoup moins problématique sur les versions récentes puisque synchronized n'épingle plus, mais les appels natifs si. Je vérifie aussi que les ThreadLocal ne retiennent rien de volumineux, parce que des caches par thread qui allaient bien sur deux cents threads ne vont plus sur cent mille. Puis j'augmente le trafic derrière un drapeau et je surveille la latence de queue, pas seulement le débit.