TomcatがSpring-Webモジュールをロードすると、SPIメカニズムはJavaクラスローダーの可視性の原理を本当に破壊しますか？

TomcatおよびSpring-Webモジュールの読み込み：SPIメカニズムの下でのクラス負荷動作の分析

TomcatがSpring-Webモジュールをロードすると、Java SPI（サービスプロバイダーインターフェイス）メカニズムを使用して、 ServletContainerInitializer Interfaceの実装クラスを見つけて使用します。これには、 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によってロードされますが、その実装クラスは通常クラスパスで、 AppClassLoaderによってロードされます。 BootstrapClassLoaderを下向きにロードすることはできないため、スレッドコンテキストクラスローダーは実装クラスをロードする必要があります。これにより、親の委任モデルの厳格な階層が回転し、 AppClassLoader BootstrapClassLoaderがロードできないクラスをロードできるようになります。問題は解決されましたが、親の委任モデルの元の意図からも逸脱しました。

AppClassLoader 、親の委任メカニズムのコードを直接スキップせず、親の委任ロジックを内部的に追跡することを強調する必要があります。 BootstrapClassLoaderの制限により、最終的な読み込み作業はAppClassLoaderによって行われることがSPIシナリオのみです。これはトレードオフです。 JDBCメカニズムは似ています。 Javaはインターフェイスのみを提供します。特定の実装はメーカーによって提供され、親委任メカニズムの制限もバイパスするために必要です。

したがって、SPIメカニズムは、親委任モデルの厳格なルールにある程度「違反」しますが、これは必要な妥協であり、クラスローダーの視認性の原則を完全に「破壊」しません。スレッドコンテキストクラスローダーを介して実装クラスをロードする適切な方法を見つけます。

以上がTomcatがSpring-Webモジュールをロードすると、SPIメカニズムはJavaクラスローダーの可視性の原理を本当に破壊しますか？の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。