Les threads virtuels : la concurrence sans pool

Un serveur Java classique traite chaque requête sur un thread pris dans un pool. Ce thread est un thread du système d'exploitation : il coûte environ un mégaoctet de pile réservée, sa création se compte en centaines de microsecondes, et le noyau doit l'ordonnancer. On en garde donc peu — deux cents, quatre cents — et on les recycle. Or que fait ce thread pendant la requête ? Il attend. Il attend PostgreSQL pendant huit millisecondes, puis un service HTTP tiers pendant cent, puis Redis. Sur une requête de cent cinquante millisecondes, le processeur travaille peut-être trois millisecondes. Le reste du temps, une ressource rare et chère est immobilisée à ne rien faire.

Quand la charge dépasse la taille du pool, les requêtes s'empilent dans une file. Le temps de réponse s'effondre alors que les processeurs sont à dix pour cent d'utilisation. La réponse habituelle à ce mur consiste à passer en programmation réactive : plus de blocage, des rappels, CompletableFuture ou des flux réactifs. Cela fonctionne, et cela coûte cher — le code se retourne, les piles d'appels deviennent inexploitables, le débogueur ne suit plus, et l'ensemble de la chaîne doit devenir non bloquante sous peine de perdre tout le bénéfice. Les threads virtuels, stabilisés en Java 21, proposent de garder le code bloquant, séquentiel et lisible, en rendant le thread lui-même quasi gratuit.