Le conflit de chargeur de classe Springboot provoque LinkageError: pourquoi est-ce un linkageError au lieu de classcastException?

Analyse approfondie de LinkageError: la cause profonde du conflit de chargeur de classe à Springboot

Cet article analyse le problème java.lang.LinkageError qui se produit dans une application Springboot. Ce problème se produit lors de l'intégration du système de gestion des journaux, en raison de la personnalisation du mécanisme de chargement des délégués de LaunchedURLClassLoader .

Le problème provient du développeur qui essaie de gérer les journaux de manière unifiée, de modifier la relation de délégation de LaunchedURLClassLoader et de déléguer explicitement les packages liés aux journaux tels que org.slf4j , ch.qos.logback.core au chargeur de classe parent. Cependant, le package ch.qos.logback.classic.spi est manqué, ce qui fait que le temps d'exécution lance java.lang.LinkageError: loader constraint violation . Le message d'erreur indique que la classe ch.qos.logback.classic.spi.TurboFilterList est chargée de différentes versions par LaunchedURLClassLoader et son chargeur de classe parent.

Le développeur se demande pourquoi il est LinkageError plutôt que ClassCastException . Ceci est étroitement lié au mécanisme de chargement de la classe Java et au modèle de délégation parent. Lorsque LaunchedURLClassLoader essaie de charger TurboFilterList , il est constaté que le chargeur de classe parent a chargé une version différente de la classe, violant le modèle de délégation parent. Le chargeur de classe tente de définir une classe existante, ce qui soulève LinkageError . Ce n'est pas une erreur de conversion de type simple, mais une classe du même nom chargée par différents chargeurs de classe a des conflits de différentes définitions.

LinkageError n'est pas dû à l'erreur de type d'objet renvoyée getTurboFilterList() (bien que l'objet soit en effet chargé par le chargeur de classe parent), mais le JVM détecte que TurboFilterList a été chargée par un autre chargeur de classe pendant ClassLoader.defineClass LaunchedURLClassLoader Cela reflète la rigueur du JVM pour le chargement des classes, assure le caractère unique de la classe et évite les erreurs d'exécution causées par des conflits dans différentes versions de la classe.

La solution consiste à s'assurer que tous les packages de journal pertinents sont correctement délégués au chargeur de classe parent, ou uniformément chargés par le même chargeur de classe pour éviter les conflits de chargeur de classe.

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!