Wenn Tomcat Spring-Web-Module lädt, zerstört der SPI-Mechanismus dann das Sichtbarkeitsprinzip der Lader der Java-Klasse?

Ladung von Tomcat und Spring-Web-Modul: Analyse des Klassenbeladungsverhaltens im SPI-Mechanismus

Wenn Tomcat das Spring-Web-Modul lädt, verwendet es den Java SPI-Mechanismus (Service Provider Interface), um ServletContainerInitializer -Schnittstelle zu finden und zu verwenden. Dies beinhaltet die load von ServiceLoader und das Sichtbarkeitsprinzip des Klassenladers. Einige Leute in Frage stellen, dass dieser Ansatz gegen das Sichtbarkeitsprinzip von Klassenladern verstößt. Analysieren wir ihn also ausführlich.

Der Artikel weist darauf hin, dass die LOAD -Methode ServiceLoader.load letztendlich von sun.misc.Launcher.AppClassLoader geladen wird, um die Implementierungsklasse ServletContainerInitializer -Schnittstelle zu laden. Im Code verwendet ServiceLoader.load(service, cl) Thread.currentThread().getContextClassLoader() um den Klassenloader zu erhalten. In Anwendungsservern wie Tomcat ist dieser Klassenlader normalerweise AppClassLoader .

Einige Leute denken, dass ServiceLoader.load(service, cl) dem ServiceLoader.load(service, null) entspricht. Obwohl die Ergebnisse in einigen Fällen ähnlich sind, sind die Prinzipien unterschiedlich. Der erstere legt ausdrücklich den Klassenlader an, während der letztere den Klassenlader des Anrufers verwendet.

Warum glaubt jemand, dass dies das Sichtbarkeitsprinzip von Klassenladern bricht? Der Schlüssel liegt in der Besonderheit des SPI -Mechanismus. Die Schnittstelle in rt.jar wird durch BootstrapClassLoader geladen, aber die Implementierungsklasse befindet sich normalerweise im Klassenpfad und wird von AppClassLoader geladen. BootstrapClassLoader kann nicht nach unten geladen werden, sodass der Lader der Thread -Kontextklasse die Implementierungsklasse laden muss. Dies umgeht die strikte Hierarchie des übergeordneten Delegationsmodells, sodass AppClassLoader Klassen laden kann, die BootstrapClassLoader nicht laden können. Obwohl das Problem gelöst wurde, weichte es auch von der ursprünglichen Absicht des übergeordneten Delegationsmodells ab.

Es sollte betont werden, dass AppClassLoader den Code des übergeordneten Delegationsmechanismus nicht direkt überspringt und die übergeordnete Delegationslogik intern weiterhin folgt. Nur im SPI-Szenario, dass aufgrund der Einschränkungen des BootstrapClassLoader die endgültige Ladearbeiten durch AppClassLoader erfolgen, was ein Kompromiss darstellt. Der JDBC -Mechanismus ist ähnlich. Java bietet nur Schnittstellen. Die spezifische Implementierung wird vom Hersteller bereitgestellt, und die Einschränkungen des übergeordneten Delegationsmechanismus sind ebenfalls erforderlich, um umzugehen.

Daher verstößt der SPI -Mechanismus in gewissem Maße die strengen Regeln des übergeordneten Delegationsmodells, dies ist jedoch ein notwendiger Kompromiss und "zerstören" das Sichtbarkeitsprinzip der Klassenlader nicht vollständig. Es findet eine geeignete Möglichkeit, die Implementierungsklasse über den Thread Context Class Loader zu laden.

Das obige ist der detaillierte Inhalt vonWenn Tomcat Spring-Web-Module lädt, zerstört der SPI-Mechanismus dann das Sichtbarkeitsprinzip der Lader der Java-Klasse?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!