もっと多くのクラスローダーが必要なのはなぜですか？

Question

私は、Javaのクラスローダの階層があることを知っている：

1.Bootstrap（ネイティブコードで）クラスローダ
2.拡張クラスローダ（sun.misc.Launcher$ExtClassLoader）
3.システムクラスローダ（sun.misc.Launcher$AppClassLoader class）
4 。カスタムクラスローダー（アプリサーバー、earクラスローダー、warクラスローダー）

追加の子クラスローダーが必要な理由は明らかではありません。ネイティブコードの後に​​「純粋なjava」クラスローダーの必要性を理解できました。
私は考えられる理由をいくつか考えていますが、誰かがこの動作/クラスローダーの階層の必要性を明確に説明してくれますか？
一般的にはj2eeにも適用されます。

Answer 1

クラスローダーは、さまざまな動作を提供し、同じVMで実行されているさまざまなJavaプログラムを互いに保護するのに便利です。

• クラスローダーは、クラスを異なる方法でロードするプロセスを実装できます。たとえば、あるサーバからクラスのバイトコードを取得してJVMにインストールするクラスローダ、またはファイルから読み込む代わりに実際にgenerates the bytecode on the flyというクラスローダを持つクラスローダがあります。
• クラスローダーは、異なるコード "ツリー"が同じ名前のクラスの異なるコピーを持つことができるように、単一のJVM内にパーティションを形成することができます。これの一般的な例はTomcatのようなサーブレットコンテナで、複数の異なるバージョンのライブラリ（Apache Commons-Langなど）を持つ複数のwarがインストールされている可能性があります。 OSGiは、この方法を使用して、各バンドルが、特に要求されたクラスにのみアクセスし、APIを「リーク」できないようにします。
• クラスローダーを使用して、実際のクラスそのものをガベージコレクトするときのさまざまなポリシーを実装できます。デフォルトのクラスローダーだけを使用すると、クラスが無限に保持され、恐ろしいPermGenエラーが発生します。多くの一時的なクラス（多分、オンザフライで生成されたもの）を使用したアプリケーションは、使い捨てのクラスローダーを使用して不要になったときにそれらが解放されたことを確認したいかもしれません。

Answer 2

使用しているクラスローダーは、特定のアプリケーションサーバーに依存していると思います。ここにはTomcat class loadersのドキュメントがあります。

Tomcatでは、さまざまな場所からクラスをロードするさまざまなクラスローダを基本的に作成しています。例えば、共通クラスローダは、$CATALINA_HOME/libから共有ライブラリをロードします。各Webアプリケーションクラスローダーは、それぞれのWEB-INFディレクトリからクラスをロードします。

クラスローダーの必要性は、いくつかの優先ルール（たとえば、WEB-INFのクラスがCATALINA_HOME/libよりも優先されます）を使用して、さまざまな場所からロードする必要性が主に発生します。また、異なるバージョンのクラスを異なるクラスローダーにロードすることもできます。例えば、2つのWebアプリケーションでは、このように2種類の異なるバージョンのLog4jを使用できます。

他のアプリサーバーでは、クラスローダーの階層が異なる可能性がありますが、同じ理由も同じです。