Lorsque Tomcat charge les modules de Spring-Web, le mécanisme SPI détruit-il vraiment le principe de visibilité des chargeurs de classe Java?

Chargement du module Tomcat et Spring-Web: analyse du comportement de chargement des classes sous le mécanisme SPI

Lorsque TomCat charge le module Spring-Web, il utilise le mécanisme Java SPI (Interface du fournisseur de services) pour trouver et utiliser ServletContainerInitializer . Cela implique la méthode load de ServiceLoader et le principe de visibilité du chargeur de classe. Certaines personnes remettent en question cette approche viole le principe de visibilité des chargeurs de classe, alors analysons-le en profondeur.

L'article souligne que la méthode ServiceLoader.load est finalement chargée par sun.misc.Launcher.AppClassLoader pour charger la classe d'implémentation de ServletContainerInitializer . Dans le code, ServiceLoader.load(service, cl) utilise Thread.currentThread().getContextClassLoader() pour obtenir le chargeur de classe. Dans des serveurs d'applications tels que TomCat, ce chargeur de classe est généralement AppClassLoader .

Certaines personnes pensent que ServiceLoader.load(service, cl) équivaut à ServiceLoader.load(service, null) . Bien que les résultats soient similaires dans certains cas, les principes sont différents. Le premier spécifie explicitement le chargeur de classe, tandis que le second utilise le chargeur de classe de l'appelant.

Pourquoi quelqu'un pense-t-il que cela brise le principe de visibilité des chargeurs de classe? La clé réside dans la particularité du mécanisme SPI. L'interface de rt.jar est chargée par BootstrapClassLoader , mais sa classe d'implémentation est généralement dans ClassPath et est chargée par AppClassLoader . BootstrapClassLoader ne peut pas être chargé vers le bas, donc le chargeur de classe de contexte de thread doit charger la classe d'implémentation. Cela contourne la hiérarchie stricte du modèle de délégation parent, permettant AppClassLoader de charger des classes que BootstrapClassLoader ne peut pas charger. Bien que le problème ait été résolu, il a également dévié de l'intention d'origine du modèle de délégation parent.

Il convient de souligner que AppClassLoader ne saute pas directement le code du mécanisme de délégation parent, et il suit toujours la logique de délégation parent en interne. Ce n'est que dans le scénario SPI que, en raison des limites de BootstrapClassLoader , le travail de chargement final est effectué par AppClassLoader , qui est un compromis. Le mécanisme JDBC est similaire. Java fournit uniquement des interfaces. La mise en œuvre spécifique est fournie par le fabricant, et les restrictions du mécanisme de délégation parent sont également nécessaires pour contourner.

Par conséquent, le mécanisme SPI "viole" les règles strictes du modèle de délégation des parents dans une certaine mesure, mais il s'agit d'un compromis nécessaire et ne "détruit pas complètement" le principe de visibilité des chargeurs de classe. Il trouve un moyen approprié de charger la classe d'implémentation via le chargeur de classe de contexte de thread.

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!