When Tomcat loads Spring-Web modules, does the SPI mechanism really destroy the visibility principle of Java class loaders?

Tomcat and Spring-Web module loading: Analysis of class loading behavior under SPI mechanism

When Tomcat loads Spring-Web module, it uses the Java SPI (Service Provider Interface) mechanism to find and use ServletContainerInitializer interface implementation class. This involves the load method of ServiceLoader and the visibility principle of class loader. Some people question this approach violates the visibility principle of class loaders, so let's analyze it in depth.

The article points out that the ServiceLoader.load method is ultimately loaded by sun.misc.Launcher.AppClassLoader to load the implementation class of ServletContainerInitializer interface. In the code, ServiceLoader.load(service, cl) uses Thread.currentThread().getContextClassLoader() to get the class loader. In application servers such as Tomcat, this class loader is usually AppClassLoader .

Some people think that ServiceLoader.load(service, cl) is equivalent to ServiceLoader.load(service, null) . Although the results are similar in some cases, the principles are different. The former explicitly specifies the class loader, while the latter uses the caller's class loader.

Why do anyone think this breaks the visibility principle of class loaders? The key lies in the particularity of the SPI mechanism. The interface in rt.jar is loaded by BootstrapClassLoader , but its implementation class is usually in classpath and is loaded by AppClassLoader . BootstrapClassLoader cannot be loaded downward, so the thread context class loader needs to load the implementation class. This bypasses the strict hierarchy of the parent delegation model, enabling AppClassLoader to load classes that BootstrapClassLoader cannot load. Although the problem was solved, it also deviated from the original intention of the parent delegation model.

It should be emphasized that AppClassLoader does not directly skip the code of the parent delegation mechanism, and it still follows the parent delegation logic internally. It is only in the SPI scenario that due to the limitations of BootstrapClassLoader , the final loading work is done by AppClassLoader , which is a trade-off. The JDBC mechanism is similar. Java only provides interfaces. The specific implementation is provided by the manufacturer, and the restrictions of the parent delegation mechanism are also required to bypass.

Therefore, the SPI mechanism "violates" the strict rules of the parent delegation model to some extent, but this is a necessary compromise and does not completely "destroy" the visibility principle of class loaders. It finds a suitable way to load the implementing class through the thread context class loader.

The above is the detailed content of When Tomcat loads Spring-Web modules, does the SPI mechanism really destroy the visibility principle of Java class loaders?. For more information, please follow other related articles on the PHP Chinese website!