Tomcat は親の委任メカニズムを破壊して Web アプリケーションの分離を実現します。

Tomcat は、カスタム クラス ローダー WebAppClassLoader を通じて親の委任を解除します。つまり、JVM クラス ローダー ClassLoader の findClass メソッドと loadClass メソッドを書き換えて、Web アプリケーション ディレクトリ内のクラスのロードを優先します。

Tomcat は、サーブレット クラスと、サーブレットが依存する JAR パッケージをロードする役割を担います。 Tomcat 自体も Java プログラムなので、独自のクラスと依存する JAR パッケージをロードする必要があります。

Tomcat 上で 2 つの Web アプリケーションを実行し、それらのアプリケーションに同じ名前で機能が異なるサーブレットがある場合、Tomcat は、競合が発生しないように、同じ名前のこれらの 2 つのサーブレット クラスを同時にロードして管理する必要があります。したがって、Webアプリケーション間のクラスは分離する必要がある。

2 つの Web アプリケーションが両方とも Spring などの同じサードパーティ jar に依存している場合、Spring jar がメモリにロードされた後、Tomcat は 2 つの Web アプリケーションがそれを共有できること、つまり Spring jar が 1 回だけロードされることを保証する必要があります。そうしないと、サードパーティ jar の数が増えるにつれて、JVM のメモリが大きくなりすぎます。
そのため、JVM と同様に、Tomcat 自体のクラスと Web アプリケーションのクラスを分離する必要があります。

Tomcat クラスローダー階層

Tomcat のクラスローダー階層

最初の 3 つはクラス名ではなく、ローダー インスタンス名です。

WebAppクラスローダー

JVM のデフォルトの AppClassLoader を使用して Web アプリケーションをロードする場合、AppClassLoader は 1 つの Servlet クラスのみをロードできます。同じ名前の 2 番目の Servlet クラスをロードする場合、AppClassLoader は最初の Servlet クラスの Class インスタンスを返します。
AppClassLoader の観点からは、同じ名前の Servlet クラスは 1 回しかロードできないためです。

そのため、Tomcat はクラス ローダーWebAppClassLoaderをカスタマイズし、各 Web アプリケーションに対してWebAppClassLoaderインスタンスを作成します。

各 Web アプリケーションの独自の Java クラスと依存する JAR パッケージは、それぞれWEB-INF/classesとWEB-INF/libディレクトリに配置され、すべて WebAppClassLoader によってロードされます。

Context コンテナ コンポーネントは Web アプリケーションに対応します。したがって、各 Context コンテナは WebAppClassLoader ローダー インスタンスを作成して維持します。
異なるローダー インスタンスによってロードされたクラスは、クラス名が同じであっても、異なるクラスと見なされます。これは、JVM 内に相互に分離された Java クラス空間を作成することと同じです。各 Web アプリケーションには独自のクラス空間があり、Web アプリケーションは独自のクラス ローダーによって互いに分離されています。

共有クラスローダー

2 つの Web アプリケーションがライブラリ クラスを共有し、同じクラスを繰り返しロードしないようにするにはどうすればよいですか?

親委任メカニズムの各子ローダーは親ローダーを介してクラスをロードできるため、共有するクラスを親ローダーのロード パスに配置することを検討してください。

これは、アプリケーションが JRE コア クラスを共有する方法です。
Tomcat は、Web アプリケーション間で共有されるクラスをロードするために、WebAppClassLoader の親ローダーとしてクラス ローダー SharedClassLoader を作成しました。

WebAppClassLoader がクラスをロードしない場合は、親ローダー SharedClassLoader にクラスのロードを委託します。SharedClassLoader は指定されたディレクトリに共有クラスをロードし、それを WebAppClassLoader に返して共有の問題を解決します。

カタリナクラスローダー

Tomcat 独自のクラスを Web アプリケーションのクラスから分離するにはどうすればよいですか?

兄弟関係: 2 つのクラス ローダーは並列です。親ローダーは同じである場合もありますが、2 つの兄弟クラス ローダーによってロードされるクラスは分離されています。

そのため、Tomcat は Tomcat 独自のクラスをロードするために CatalinaClassLoader を作成しました。

問題は、Tomcat とさまざまな Web アプリケーション間でいくつかのクラスを共有する必要がある場合にはどうすればよいかということです。

共通クラスローダー

共有は依然として父と息子の関係に依存しています。
CatalinaClassLoader と SharedClassLoader の親ローダーとして別の CommonClassLoader を追加します。

CommonClassLoader がロードできるクラスは CatalinaClassLoader と SharedClassLoader で使用できますが、CatalinaClassLoader と SharedClassLoader がロードできるクラスは互いに分離されています。 WebAppClassLoader は SharedClassLoader によってロードされたクラスを使用できますが、各 WebAppClassLoader インスタンスは互いに分離されています。

バネ荷重の問題

デフォルトでは、クラスがクラス ローダー A によってロードされると、そのクラスの依存クラスも同じクラス ローダーによってロードされます。
たとえば、Bean ファクトリとしての Spring は、ビジネス クラスのインスタンスを作成し、ビジネス クラスのインスタンスを作成する前にこれらのクラスをロードする必要があります。 Spring は Class.forName を呼び出してビジネス クラスをロードします。forName のソース コードを見てみましょう。

パブリック静的クラス<?> forName(String className) {
    クラス<?> 呼び出し元 = Reflection.getCallerClass();
    forName0(className, true, ClassLoader.getClassLoader(caller), caller) を返します。
}

呼び出し元である Spring のローダーは、ビジネス クラスをロードするために使用されます。

Web アプリケーション間で共有される JAR ファイルは、繰り返しの読み込みを回避するために SharedClassLoader によって読み込むことができます。共有サードパーティ jar として、Spring は SharedClassLoader によってロードされます。Spring はビジネス クラスもロードする必要があります。前のルールによると、Spring をロードするクラス ローダーはビジネス クラスのロードにも使用されます。ただし、ビジネス クラスは Web アプリケーション ディレクトリにあり、SharedClassLoader のロード パスにはありません。どうすればよいでしょうか。

スレッドコンテキストローダー

そのため、スレッド コンテキスト ローダー、クラス ローダー転送メカニズムが存在します。クラスローダーはスレッドのプライベートデータに格納されるため、同一スレッドであれば、一度スレッドコンテキストローダーを設定すれば、以降のスレッド実行時にクラスローダーを取り出して使用することができます。そこで、Tomcat は Web アプリケーションごとに WebAppClassLoader クラスローダーを作成し、Web アプリケーションを起動するスレッドにスレッドコンテキストローダーを設定します。このようにして、Spring は起動時にスレッドコンテキストローダーを取り出して Bean をロードします。 Spring スレッド コンテキストのロードのコードは次のとおりです。

cl = Thread.currentThread().getContextClassLoader();

StandardContext の起動メソッドでは、現在のスレッドのコンテキスト ローダーが WebAppClassLoader に設定されます。

開始メソッドの終了時に、スレッドのコンテキスト ローダーが復元されます。

Thread.currentThread().setContextClassLoader(originalClassLoader);

これはなぜでしょうか?

スレッド コンテキスト ローダーは、実際にはスレッドのプライベート データであり、スレッドにバインドされています。スレッドがコンテキスト コンポーネントの開始を完了すると、スレッド プールにリサイクルされ、他の処理に使用されます。他の処理に影響を与えないようにするには、以前のスレッド コンテキスト ローダーを復元する必要があります。
Web アプリケーション クラスの読み込みを優先し、読み込みが完了したら元のクラスに戻します。

スレッド コンテキスト ローダーは、JDBC ドライバーなどの特定のブリッジ クラスをロードするためのサブクラス ローダーを指定します。

要約する

Tomcat Context コンポーネントは、Web アプリケーションごとに WebAppClassLoader クラス ローダーを作成します。異なるクラス ローダー インスタンスによってロードされたクラスは互いに分離されるため、Web アプリケーションを分離するという目的が達成されます。同時に、サードパーティの JAR パッケージは、CommonClassLoader などの親ローダーを通じて共有されます。共有サードパーティ JAR パッケージは、特定の Web アプリケーションのクラスをどのようにロードしますか?これは、スレッド コンテキスト ローダーを設定することで解決できます。

複数のアプリケーションで共有される Java クラス ファイルと JAR パッケージは、Web コンテナによって指定された共有ディレクトリに配置されます。

共通クラスローダー
<Tomcat>/common/*に相当します

カタリナクラスローダー
<Tomcat >/server/*に相当します

共有クラスローダー
<Tomcat >/shared/*に相当します

WebAppクラスローダー
<Tomcat >/webapps/<app>/WEB-INF/*に相当します。

Tomcat conf ディレクトリの Catalina.properties ファイルで、さまざまなクラス ローダーの読み込みパスを設定できます。

ClassNotFound エラーが発生した場合は、クラスローダーが正しいことを確認する必要があります。
スレッド コンテキスト ローダーは、Tomcat および Spring のクラス読み込みシナリオで使用できるだけでなく、コア フレームワーク クラスが特定の実装クラスを読み込む必要がある場合にも使用できます。たとえば、よく知られている JDBC は、コンテキスト クラス ローダーを通じてさまざまなデータベース ドライバーを読み込みます。

Tomcat が親の委任メカニズムを破って分離された Web アプリケーションを実現する方法について説明したこの記事はこれで終わりです。Tomcat の分離された Web アプリケーションに関するより関連性の高いコンテンツについては、123WORDPRESS.COM の以前の記事を検索するか、次の関連記事を引き続き参照してください。今後とも 123WORDPRESS.COM をよろしくお願いいたします。