Les threads virtuels de Java en résumé : ce qui change et ce qui ne change pas

Ce que c'est

La JEP 444 décrit un thread virtuel comme une instance de java.lang.Thread qui n'est pas liée un pour un à un thread du système d'exploitation. Un ordonnanceur (un ForkJoinPool en mode FIFO dont le parallélisme vaut par défaut le nombre de processeurs disponibles) monte un thread virtuel sur un thread de plateforme, son thread porteur (carrier) ; lorsque le thread virtuel bloque sur une E/S ou sur une autre opération bloquante du JDK, il se démonte et le thread porteur prend en charge d'autre travail. Les piles résident dans le tas sous forme d'objets stack-chunk et croissent ou diminuent. Thread.ofVirtual(), Thread.startVirtualThread(r) et Executors.newVirtualThreadPerTaskExecutor() les créent, et ce sont toujours des threads démons. La JEP précise explicitement que les threads virtuels ne sont pas des threads plus rapides : ils apportent du passage à l'échelle (débit), pas de la vitesse (latence), et le travail lié au CPU ne gagne rien à en avoir davantage que de cœurs disponibles.

Pourquoi c'est important

Pour les personnes venant de Go ou de l'async de C#, l'intérêt est que Java conserve le style à un thread par requête — boucles, try/catch et appels bloquants ordinaires à JDBC ou HTTP compris — tout en supprimant le plafond de threads du système d'exploitation qui poussait le code vers des pipelines réactifs ou fondés sur CompletableFuture. Le code construit sur ExecutorService migre en changeant simplement d'exécuteur, c'est pourquoi la JEP propose Executors.newThreadPerTaskExecutor à côté de la fabrique de threads virtuels.

Comment l'appliquer

• Ne pas mettre les threads virtuels en pool ; en créer un par tâche. Pour limiter la concurrence vers une ressource en aval, utiliser un Semaphore, que la JEP et le guide des bibliothèques de base désignent tous deux comme la construction prévue à cet effet.
• Réexaminer l'usage de ThreadLocal : un cache thread-local d'un objet coûteux, judicieux dans un pool de cinquante threads, se retrouve créé à chaque requête avec des threads virtuels. La JEP indique les valeurs scopées (scoped values) comme alternative.
• Vérifier le pinning : dans JDK 21, un thread virtuel qui bloque à l'intérieur d'un bloc ou d'une méthode synchronized, ou dans un cadre natif, épingle son thread porteur. -Djdk.tracePinnedThreads=full et l'événement JFR jdk.VirtualThreadPinned (activé par défaut avec un seuil de 20 ms) montrent où cela se produit. La JEP 491, dans JDK 24, supprime le pinning pour synchronized et Object.wait() et retire la propriété jdk.tracePinnedThreads (l'événement JFR subsiste) ; les cadres natifs, le chargement de classes et les initialiseurs de classe continuent d'épingler.
• S'attendre à ce que les dumps de threads plats deviennent inutilisables avec un million de threads ; la JEP ajoute jcmd <pid> Thread.dump_to_file -format=json.
• Conserver les threads de plateforme pour les boucles liées au CPU et pour le travail qui ne bloque jamais.

Pièges

Certaines opérations bloquantes (de nombreux appels au système de fichiers, Object.wait() avant JDK 24) capturent le thread du système d'exploitation ; l'ordonnanceur compense temporairement jusqu'à jdk.virtualThreadScheduler.maxPoolSize. Les bibliothèques qui maintiennent des moniteurs autour d'E/S limitent le passage à l'échelle tant qu'elles ne sont pas mises à jour. Les frameworks doivent adopter explicitement le mécanisme ; un serveur qui reste sur un pool fixe de threads de plateforme ne voit aucun changement. La concurrence structurée, une JEP distincte, est le moyen prévu pour gérer des groupes de threads virtuels.