Les fils virtuels Java affectent l'observabilité et les stratégies de surveillance doivent être ajustées pour s'adapter. 1. L'ID de fil n'est plus unique et les outils traditionnels sont difficiles à localiser les problèmes; 2. Le nom de thread dans le journal n'est pas valide, et le suivi MDC et distribué sont nécessaires pour connecter le lien de demande; 3. Les outils APM existants sont insuffisamment pris en charge, donc JDK doit être mis à niveau et de nouveaux outils tels que JFR doivent être utilisés; 4. Le cadre et la communauté sont progressivement adaptés et nous devons continuer à faire attention aux progrès.

Les fils virtuels en Java sont l'une des principales fonctionnalités introduites par Project Loom, qui améliore considérablement les performances et l'évolutivité de Java dans des scénarios de concurrence élevés. Mais en même temps, l'introduction de fils virtuels a également apporté de nouveaux défis à l'observabilité. Les méthodes de surveillance traditionnelles basées sur les threads du système d'exploitation semblent souvent impuissantes lorsqu'ils sont confrontés à des milliers, voire à des centaines de milliers de fils virtuels.

Jetons un coup d'?il à l'impact spécifique des fils virtuels sur l'observabilité et comment nous devons y faire face.

Les threads virtuels modifient le modèle de thread

Les fils virtuels sont essentiellement des threads légers gérés par le JVM. Ils ne mappent pas directement vers les threads du système d'exploitation comme les threads de plate-forme, mais sont réutilisés sur un petit nombre de threads de plate-forme via un planificateur. Cette conception facilite la création de centaines de milliers de fils virtuels, mais cela signifie également:

• L'ID de thread n'identifie plus de manière unique une unité d'exécution
• Le nom de fil traditionnel, l'état du fil et d'autres informations sont devenus insuffisants
• La trace de pile peut contenir de nombreuses informations sur la commutation de threads virtuelles, ce qui rend difficile la localisation rapidement des problèmes.

Si vous aviez l'habitude de vérifier le blocage ou le délai de suppression via des outils jstack ou APM avant de vérifier la pile de threads, vous pouvez maintenant constater que ces outils "ne peuvent pas voir clairement" la relation entre les threads virtuels.

La journalisation nécessite un contexte plus clair

Dans un environnement multithread, le nom de thread est généralement enregistré dans le journal pour aider à suivre le chemin de traitement de la demande. Cependant, dans les scénarios de thread virtuels, le nom de thread change fréquemment et le cycle de vie est court, ce qui fera perdre aux informations du journal sa valeur de référence.

Par exemple: vous voyez un tas de VirtualThread[#234]/runnable dans le journal, et vous ne savez pas à quelle demande ou tache il appartient.

Les solutions à ce problème comprennent:

• Utilisez MDC (contexte de diagnostic mappé) pour enregistrer des identificateurs uniques au niveau de la demande, tels que l'ID de trace ou l'ID de demande
• En conjonction avec des systèmes de suivi distribués (tels que Jaeger et OpenteLelemyt), les chemins d'exécution des threads virtuels sont associés
• Dans une concurrence asynchrone ou structurée, assurez-vous que les informations contextuelles sont passées entre les taches

De cette fa?on, même si le thread change, vous pouvez connecter les opérations connexes et voir clairement le lien d'appel entier.

Les outils de surveillance et de diagnostic nécessitent un support de mise à niveau

à l'heure actuelle, de nombreux outils de surveillance Java ne peuvent pas bien reconna?tre bien les threads virtuels. Par exemple, certains outils APM ne peuvent compter que le nombre de threads de plate-forme et ignorer le fonctionnement réel des threads virtuels.

Pour améliorer l'observabilité, vous pouvez:

• Passer à JDK 21 et utiliser la dernière version des outils de diagnostic qui prennent en charge les threads virtuels (comme JFR)
• Tirez parti de nouvelles API fournies par le JVM (telles que Thread.ofVirtual() ) pour distinguer clairement les threads virtuels et les threads de plate-forme
• Faites attention aux progrès du soutien à l'observation des communautés et des fournisseurs pour les fils virtuels. Par exemple, des cadres tels que Spring, Micronaut, Quarkus ont commencé à s'adapter

JFR (Java Flight Recorder) est un bon choix à cet égard. Il peut déjà prendre en charge l'enregistrement des événements et l'analyse des threads virtuels, et peut être utilisé pour suivre la planification des fils virtuels, le blocage, l'utilisation du processeur, etc.

Résumons

Bien que les threads virtuels de Java améliorent les capacités de concurrence, ils brisent également nos méthodes de surveillance et de débogage précédentes des threads. Pour maintenir une bonne observabilité, nous avons besoin:

• Remplacez la stratégie de journal qui dépend du nom du thread et utilisez plut?t le contexte au niveau de la demande.
• Améliorez votre système de surveillance et de suivi pour prendre en charge le threading virtuel
• Utilisez JFR et les nouvelles API JDK pour mieux comprendre le comportement du fil virtuel

Fondamentalement, c'est tout. Après tout, les fils virtuels n'apportent pas des obstacles insurmontables, mais une nouvelle norme qui nous oblige à ajuster notre réflexion pour nous adapter.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!