1

Java がスレッドに contexClassLoader を導入した理由が不思議です。クラスを動的に見つけてロードする必要があるフレームワークとアプリケーションサーバーで通常使用されることを私は知っています。

ただし、必要なクラスローダーを保持するフィールドを追加するだけで同じ機能を実現できるのに、Java が contexClassLoader を導入した理由がわかりません。

class ThreadWithCustomClassloader extends Thread
{
    ClassLoader threadClassLoader;

    public void run()
    {
       //use threadClassLoader to dynamically find and load classes
    }
}
4

2 に答える 2

0

私は混乱しています-クラスローダーのインスタンス変数を持つことは、まさにThreadクラスがこれを実装するために使用するものです。ソリューションの違いは何ですか？

セッターは気になりますか？クラスローダーの設定は、まったく異なる環境（Webアプリケーション）で同じスレッド（サーブレットコンテナなど）を再利用できるようにするために重要です。スレッドインスタンスは高価であると見なされます...

于 2012-05-10T13:11:39.460 に答える
0

JVM のデフォルトのクラス ローダー メカニズムは親委譲です。スレッド コンテキスト クラスローダーは、クラスローディング委譲スキームの周りにバック ドアを提供します。 JNDI を例にとると、その根幹は rt.jar (J2SE 1.3 以降) のブートストラップ クラスによって実装されますが、これらのコア JNDI クラスは、独立したベンダーによって実装され、アプリケーションの -classpath にデプロイされる可能性がある JNDI プロバイダーをロードする可能性があります。このシナリオでは、親クラスローダ (この場合は最初のクラスローダ) が、その子クラスローダの 1 つ (たとえば、システムのクラスローダ) から見えるクラスをロードする必要があります。通常の J2SE 委譲は機能しません。回避策は、コア JNDI クラスでスレッド コンテキスト ローダーを使用することです。これにより、適切な委譲とは反対の方向にクラスローダー階層を効果的に「トンネリング」します。

詳細については、どのクラスローダーを使用する必要があるかを確認してください

于 2016-12-13T10:40:24.880 に答える