Tomcat加載Spring-Web模塊時，SPI機制真的破壞了Java類加載器的可見性原則嗎？

Tomcat與Spring-Web模塊加載：SPI機制下的類加載行為分析

Tomcat加載Spring-Web模塊時，利用Java SPI（Service Provider Interface）機制查找並使用ServletContainerInitializer接口的實現類。 這涉及到ServiceLoader的load方法和類加載器的可見性原則。 有人質疑這種方式違反了類加載器的可見性原則，讓我們深入分析。

文章指出， ServiceLoader.load方法最終由sun.misc.Launcher.AppClassLoader加載ServletContainerInitializer接口的實現類。代碼中， ServiceLoader.load(service, cl)使用Thread.currentThread().getContextClassLoader()獲取類加載器，在Tomcat等應用服務器中，該類加載器通常是AppClassLoader 。

有人認為ServiceLoader.load(service, cl)等同於ServiceLoader.load(service, null) 。雖然在某些情況下結果相似，但原理不同。前者明確指定類加載器，而後者使用調用者的類加載器。

為什麼有人認為這破壞了類加載器的可見性原則？關鍵在於SPI機制的特殊性。 rt.jar中的接口由BootstrapClassLoader加載，但其實現類通常在classpath中，由AppClassLoader加載。 BootstrapClassLoader無法向下委託加載，因此需要線程上下文類加載器加載實現類。 這繞過了雙親委派模型的嚴格層次，使AppClassLoader能夠加載BootstrapClassLoader無法加載的類。雖然解決了問題，但也偏離了雙親委派模型的本意。

需要強調的是， AppClassLoader並沒有直接跳過雙親委派機制的代碼，它內部仍然遵循雙親委派邏輯。只是在SPI場景下，由於BootstrapClassLoader的限制，最終加載工作由AppClassLoader完成，這是一種權衡之舉。 JDBC機制類似，Java只提供接口，具體實現由廠商提供，同樣需要繞過雙親委派機制的限制。

因此，SPI機制在某種程度上“違反”了雙親委派模型的嚴格規則，但這是一種必要的妥協，並非完全“破壞”了類加載器的可見性原則。它通過線程上下文類加載器找到了加載實現類的合適途徑。

以上是Tomcat加載Spring-Web模塊時，SPI機制真的破壞了Java類加載器的可見性原則嗎？的詳細內容。更多資訊請關注PHP中文網其他相關文章！