August 7, 2025
Comment multiplier par 100 la capacité de votre app Spring Boot sans changer une ligne de code métier
Vous connaissez le problème : votre app Spring Boot plante à 100 utilisateurs simultanés. Threads saturés, paramètres compliqués à ajuster, serveur qui rame.
Java 21 change tout avec les Virtual Threads. Le principe ? Au lieu de créer de vrais threads système (2MB chacun), Java génère des threads virtuels ultra-légers (quelques KB). Résultat : vous passez de 50 threads max à des millions.
Concrètement :
• Avant : 100 requêtes simultanées = serveur saturé
• Maintenant : 10 000 requêtes simultanées = aucun problème
Et le plus beau ? Aucun changement dans votre code métier. Juste une configuration Spring différente et c'est parti.
Plus besoin de calculer des tailles de pools. Plus de tuning complexe. Java s'occupe de créer et détruire les threads à la demande.
L'impact business est immédiat : votre API supporte x100 plus d'utilisateurs avec le même serveur, le même code.
C'est probablement l'évolution la plus importante de Java depuis les lambdas. Pour tous ceux qui font du web, de l'API, du microservice... c'est un game changer.
200 Likes
August 7, 2025
Discussion about this post
ismail Fochive
1 month ago
Developpeurs Full stack Java || DevOps
Infos utiles et post très intéressante.
Marc Collin
1 month ago
Architecte de solutions / Développeur Java
Il faut faire attention au test qui montre des requêtes qui font pratiquement 0 traitement... avec un grand nombre d'utilisateur alors que c'est pas la réalité
Par défaut tomcat sous spring boot la valeur par défaut pour le max de thread est de 200, , la valeur par défaut de thread a garder en vie est de 10, la valeur par défaut que le max de thread a été atteint et qu'on désire en mettre en attente est de 100
les valeurs pour jetty, undertow, reactor-netty... peuvent être différent
Il faut voir si ton système est orienté cpu bound... ou i/o bound
donc par défaut après 200 requête simultanés, le temps de réponse augmente
les virtual sont utile pour les système avec du i/o bound
alors qu'ils sont à éviter pour du cpu bound ( plutôt uitlisé ForkJoinPool), ou bien des blocs synchronized ( car tu tombes dans le pièges des thread pinning)
https://careers.edicomgroup.com/techblog/backend-virtual-threads-and-the-concurrency-model-in-spring/
https://filia-aleks.medium.com/microservice-performance-battle-spring-mvc-vs-webflux-80d39fd81bf0
https://www.javacodegeeks.com/2025/04/spring-boot-performance-with-java-virtual-threads.html
https://filia-aleks.medium.com/microservice-performance-battle-spring-mvc-vs-webflux-80d39fd81bf0
Kevin NZUGUEM
1 month ago
Cloud Software Engineer | {3xAWS , 1xAZURE, 1xK8S, 1xHashiCorp} Certified | {Quarkus, LLM} Lover
C'est en effet une partie de Projet Loom qui remet sur la table les fameux Green Threads (pour les vieux 👴🏼).
Contrairement aux Green Threads qui avaient un model de concurrence N <-> 1 (N Green Threads pour 1 OS Thread), les Virtual Threads ont un model M <-> N (M Virtual Threads pour N OS Thread). Ce qui permet de profiter des resources présentes et d'améliorer le parallélisme.
⚠️ Attention quand même, il faut bien préciser que c'est pour des charges de travail de type IO / Bloquants (écriture sur disque, appel BDD, etc...). IL NE FAUT SURTOUT PAS L'UTILISER POUR DES CHARGES DE TRAVAIL CPU INTENSIVE, SINON FORTE DEGRADATION DE PERFORMANCE.
⚠️ Autre point d'attention, il faut éviter de faire du pinning de OS Thread. C'est le cas quand on utilise le bloc synchronize, autant vous dire que beaucoup de libs utilisent ce bloc. C'est le cas du Driver JDBC PostgreSQL.
Ce n'est qu'en Java 24 qu'ils ont apporté le patch pour supporter ce bloc (https://openjdk.org/jeps/491)
📄 Doc Virtual Thread -> https://openjdk.org/jeps/444
