Que sont les threads virtuels, et en quoi changent-ils la façon d'écrire du code serveur ?

Les threads virtuels, définitifs depuis Java 21, sont des threads légers ordonnancés par la JVM sur un petit pool de threads porteurs. Quand l'un d'eux se bloque sur une entrée/sortie, il se démonte et libère son porteur, donc un million de tâches concurrentes coûtent très peu. Concrètement, vous réécrivez du code bloquant simple et vous utilisez un thread par requête plutôt qu'un executor à pool fixe, et vous ne mettez jamais les threads virtuels dans un pool parce qu'en créer un ne coûte rien.

Un thread virtuel est ordonnancé par la JVM plutôt que par le système d'exploitation, donc il coûte quelques centaines d'octets au lieu d'un mégaoctet de pile. Quand il se bloque sur une lecture de socket, il se démonte de son thread porteur et ce porteur part exécuter autre chose, puis il se remonte quand les données arrivent. Autrement dit, la vieille raison de mettre les threads dans un pool disparaît. J'utilise un executor qui crée un thread virtuel par tâche, et le code reste du bloquant tout simple, bien plus facile à lire et à déboguer qu'une chaîne de callbacks. Je garde deux choses en tête. D'abord, ils n'apportent rien au travail limité par le CPU, puisque vous n'avez toujours que le nombre de cœurs que vous avez ; le gain est sur le traitement de requêtes lourdes en entrées/sorties. Ensuite, ils suppriment la limite de concurrence accidentelle que me donnait un pool fixe, donc si j'appelle une base de données avec un pool de cinquante connexions, je place un sémaphore ou le pool lui-même devant, sinon dix mille threads virtuels s'y jettent d'un coup.