Les threads virtuels Java sont arrivés avec Java 21 pour résoudre un problème qui a coûté tranquillement au MarocÉquipes Fintech et BPO
De l’argent réel : les threads de plate-forme sont coûteux et les API bancaires à haut niveau de concurrence s’exécutant sur Spring Boot ont été
Payer ce coût à chaque demande. Fils virtuels Java 21 — Une partie de Project Loom — Inversez le modèle de filetage
Entièrement, vous permettant de gérer des dizaines de milliers de tâches simultanées sans augmenter la pression ou le réglage du tas
Tailles de pool de fils. Si votre équipe est toujours sur Java 11 ou Java 17 et compte tenu du saut LTS, ce guide fait
Le cas avec des chiffres, pas du marketing.
Quels sont les threads virtuels et pourquoi ils sont importants pour la fintech
Le problème avec les threads de plate-forme
Traditional Java threads map 1:1 to OS threads. Chacun consomme environ 1 Mo de mémoire de pile par défaut.
Un service de démarrage Spring Boot gère 500 requêtes HTTP simultanées alloue 500 threads de système d’exploitation, un plafond dur qui
vous oblige à une programmation réactive (Webflux, ComplétableFutur) Juste pour rester dans les limites des ressources.
Pour les équipes basées à Casablanca, construisant des passerelles de paiement ou des API de pointage de crédit pour les clients européens, ce
Se traduit directement par une infrastructure surprovisionnée et des chaînes d’appels réactives complexes et difficiles à déboguer.
Threads virtuels : le concept de base
Les threads virtuels sont Fils légers gérés par la JVM, pas les threads du système d’exploitation. La JVM les multiplexe sur un petit
Pool de threads de support (plate-forme). Lorsqu’un thread virtuel bloque les E/S – un appel de base de données, une requête HTTP,
Un sondage Kafka – Le thread de transporteur est publié et récupère un autre thread virtuel. Pas de blocage, pas de gaspillage
cycles.
selon le Documentation sur le projet OpenJDK, une seule JVM
L’instance peut soutenir Des millions de threads virtuels Avec une surcharge négligeable par fil.
Configurer des threads virtuels dans Spring Boot 3.x
Les prérequis
- Java 21 (LTS) — Installer via skmman:
Installer le SDK Java 21.0.3-TEM - Chaussure de printemps 3.2+
- Maven ou Gradle
Activation des threads virtuels sur une seule ligne
Spring Boot 3.2 est livré avec un support de thread virtuel de première classe. Ajoutez ceci à votre Application.Propriétés:
spring.threads.virtual.enabled=true
Ce drapeau unique remplace le pool de threads Tomcat par défaut par des threads virtuels. Aucune configuration d’exécuteur,
Pas de migration réactive. Votre existant @RestController Le code fonctionne tel quel.
Vérification de la configuration
@RestController
public class threadInfoController {
@GetMapping("/thread-info")
chaîne publique ThreadInfo() {
thread current = thread.currentThread();
return string.format("Thread : %s | Virtual : %s",
current.getName(),
current.isVirtual());
}
}
Appuyez sur le point de terminaison et confirmez Virtuelle : Vrai dans la réponse.
Benchmarks de performances : threads virtuels vs threads de plate-forme
Configuration de référence
Les résultats suivants sont basés sur un service Spring Boot 3.2 simulant un point de terminaison de requête de compte FinTech
Avec une latence de DB simulée de 50 ms (représentant d’un backend bancaire typiquement marocain sur un réseau local).
- Outil: Apache JMeter, 1 000 utilisateurs simultanés, montée en puissance de 60 secondes
- Plate-forme: 4 cœurs / 8 Go de RAM (spécification standard de la machine de développement offshore)
Résultats
| Configuration | Débit (req/s) | Latence moyenne (ms) | taux d’erreur |
|---|---|---|---|
| Fils de plate-forme (200 max) | 187 | 532 | 4,2 % |
| Fils virtuels (Java 21) | 1 340 | 74 | 0,0 % |
7x Amélioration du débit Sur le même matériel, avec un taux d’erreur nul et une latence chutant à partir de 532 ms
à 74 ms. Pour une API de paiement où le SLA est de 200 ms, c’est la différence entre le passage et l’échec d’un
Audit des clients européens.
Les Guide des fils virtuels de Baeldung fournit
Méthodologie de référence supplémentaire pour ceux qui souhaitent reproduire cela dans leur propre environnement.
Migration de Java 17 vers Java 21 : que rechercher
Liste de vérification de la migration LTS
Java 17 → Java 21 est une mise à niveau LTS-to-LTS prise en charge. La plupart des projets Spring Boot 3.x migrent avec un minimum
friction. Concentrez-vous sur ces domaines :
- API obsolètes supprimées: vérifier
Gestionnaire de sécuritéUtilisation (supprimée en Java 17+) et finalisé
Soleil.*Dépendances de l’API interne. - Collections séquencées: Java 21 introduit
SéquencedCollection,Ensemble de séquences,SéquenceMap.
Le code existant n’est pas affecté, mais examinez si vous remplacezListe/LinkedHashSetméthodes. - Correspondance de motifs pour
INTERRUPTEUR(finalisé en Java 21) : Refactoriser verbeuxinstanceofchaînes pour
Logique de domaine de nettoyage.
Enregistrements et classes scellées pour les modèles de domaine FinTech
Les enregistrements Java 17+ éliminent les DTO de passe-partout. Associez-les à des classes scellées pour une modélisation de domaine exhaustive :
Interface publique scellée PaymentResult
Permet PaymentResult.Success, PaymentResult.Failure {
Enregistrer le succès (String TransactionID, BigDecimal Montant) implémente PaymentResult {}
Record Failure(String ErrorCode, String Message) implémente PaymentResult {}
}
Ce modèle est particulièrement efficace dans les microservices où chaque contexte borné a besoin d’être bien typé,
Charges utiles d’événements immuables – une exigence courante dans les architectures axées sur les événements au service de la banque européenne
clients.
voir le Spring.io Blog sur Java 21 et Spring Boot
Pour les conseils officiels de migration de l’équipe de printemps.
Threads virtuels dans une architecture de microservices
Le modèle de fil par requête est de retour – et évolutif
Cadres réactifs (Webflux, rxjava) ont été adoptés au Marocs Les équipes offshore en grande partie comme solution de contournement
for platform thread limits. Les threads virtuels restaurent Modèle de fil par requête sans le
Pénalité d’évolutivité, sens :
- Traces d’empilage plus simples (pas de déroulement de chaîne mono/flux)
- Débogage plus facile en production
- Les développeurs juniors et intermédiaires peuvent contribuer sans expertise réactive
Quand garder WebFlux
Les threads virtuels font pas Remplacez WebFlux dans chaque scénario. Restez réactif si :
- Vous devez contre-pression (p. ex., diffusion de grands ensembles de données financières)
- vous utilisez R2DBC Pour un accès réactif à la base de données
- Votre architecture nécessite SSE (événements envoyés par serveur) Pour les tableaux de bord en temps réel
Pour les API REST standard et les consommateurs Kafka — la majorité des microservices FinTech — les threads virtuels sont
la valeur par défaut pragmatique.
Concurrence structurée (aperçu en Java 21)
Java 21 introduit Concurrence structurée En tant que fonctionnalité de prévisualisation, vous permettant d’étendre la portée simultanée
Sous-tâches d’une tâche parents cycle de vie :
try (var scope = new StructuredTaskScope.ShutDownOnFailure()) {
Future<compte de compte> balance = scope.fork(() -> accountService.getBalance(id));
Future<créditscore> score = scope.fork(() -> creditservice.getScore(id));
scope.join().throwFailed();
renvoie le nouveau clientProfile(balance.resultNow(), score.resultNow());
}
Si une sous-tâche échoue, la portée annule automatiquement l’autre. C’est beaucoup plus propre que
CompletableFuture.AllOf() Gestion des erreurs et correspond bien aux points de terminaison d’agrégation FinTech qui appellent
Plusieurs services de backend en parallèle.
Intégration de threads virtuels avec Spring AI et LangChain4j
La communauté Java marocaines Intérêt croissant pour l’IA — souligné à Devoxx Maroc —
Met une nouvelle charge de travail sur la JVM : Les appels d’inférence LLM sont liés par I/O et à latence élevée.
Les threads virtuels sont un choix naturel pour les couches d’intégration d’IA. Un point de terminaison Spring AI appelant une API LLM
(OpenAI, Mistral ou un modèle auto-hébergé) bloque les E/S du réseau pendant des centaines de millisecondes. Avec
Les threads virtuels sont activés, ces appels bloquants ne bloquent plus le pool de threads de l’opérateur.
@service
Public Classe de prêtSummaryService {
Chatclient final privé ChatClient ;
Chaîne publique résumer (application LoanApplication) {
// Cet appel de blocage est géré en toute sécurité par un thread virtuel
return chatclient.prompt()
.user("résumez cette demande de prêt : " + application.tojson())
.Appeler()
.Contenu();
}
}
Aucun emballage réactif n’est nécessaire. Le thread virtuel gère l’attente et le thread de transporteur reste libre
pour d’autres travaux.
Considérations relatives à la production
Épingler : celui qui a pris le dessus
Un thread virtuel est épinglé à son thread de support lorsqu’il tient un synchronisé Verrouiller ou appels
Code natif. L’épinglage élimine l’avantage de démontage et peut dégrader le débit.
Diagnose pinning Avec le drapeau JVM :
-djdk.tracepinnedthreads=full
Répare le en remplaçant synchronisé bloque avec réentradaire:
// Avant (épingle le fil porteur)
Synchronisé (ceci) {
// Section critique
}
// Après (sécurité virtuelle-thread)
Private Final Reentrant Lock = new ReentrantLock();
lock.lock();
essayez {
// Section critique
} enfin {
lock.unlock();
}
La plupart des bibliothèques modernes (hikaricp 5.x+, laitue pour Redis) ont déjà mis à jour leurs internes pour
éviter synchronisé sur les chemins d’E/S.
Dimensionnement du pool de connexions
Avec les threads virtuels, votre application émettra beaucoup plus de connexions de base de données simultanées qu’auparavant.
Réduisez la taille de votre pool de connexion — Dont Augmentez-le. Un pool de 10 à 20 connexions suffit
Pour la plupart des charges de travail, car les threads virtuels attendent (hors du transporteur) une connexion plutôt que
tenant un fil de système d’exploitation.
# hikaricp - réduisez cela lors de la migration vers des threads virtuels
spring.datasource.hikari.maximum-pool-size=20
Conclusion
Fils virtuels Java 21 ne sont pas une optimisation mineure – ils sont un changement fondamental dans la façon dont
La JVM gère la concurrence. Pour le Marocs Les équipes FinTech et Offshore Java, les gains sont
Immédiatement pratique : débit plus élevé sur l’infrastructure existante, code plus simple sans réactif
Complexité, et un chemin d’accès propre à l’intégration des charges de travail d’IA dans les services Spring Boot.
La migration LTS de Java 17 vers Java 21 est à faible risque et à haute récompense. Le drapeau de propriété unique
spring.threads.virtual.enabled=true est sans doute le changement de configuration de ROI le plus élevé disponible
Dans l’écosystème des bottes de printemps en ce moment.
Avez-vous activé les threads virtuels sur un service de démarrage de printemps de production ? Drop your benchmark
Les chiffres ou l’expérience de la migration dans les commentaires — La communauté Jug Maroc apprend le mieux de
Données du monde réel. Et si votre équipe est toujours sur Java 11 ou Java 8, c’est le signe de commencer
Planification de votre feuille de route LTS.
Full-Stack Developer & Solutions Architect · Casablanca, Morocco
7+ years building Java/Spring Boot/Angular enterprise solutions. Former Senior Software Engineer at NTT Data and Satec. Authorized Google Workspace and Microsoft 365 Partner for Morocco.
