Java ローダーについての深い理解-＆＃＆チュートリアル-php.cn

Java ローダーについての深い理解

王林

リリース： 2019-11-29 13:44:29

転載

2618 人が閲覧しました

Java ローダーについての深い理解

1. クラスとクラスローダー

クラスローダー: クラスの完全修飾名による読み込みフェーズの最初のステップです。このクラスのバイナリバイトストリームを jvm にロードします。

クラスとクラスローダー: クラスの一意性は、クラス自体と、それをロードするクラスローダーによって決まります。2 つのクラスが等しいかどうかは、それらが同じクラスローダーによってロードされるという前提によって決まります。

jvm 仮想マシンには 2 つのクラスローダーが含まれています。1 つは C で実装された起動クラスローダー (Bootstrap ClassLoader)、もう 1 つはその他すべて Java クラスローダーで実装されています。

Java プログラムの観点から:

1) クラスローダーを開始します: \lib ディレクトリまたは -Xbootclasspath パラメータで指定されたパスにクラスをロードします。必要なファイルに加えて、名前は仮想マシンによって認識されますが、jvm によって認識されない場合はロードできません。

2) 拡張クラスローダー: \lib\exit ディレクトリまたは java.exit.dirs システム変数で指定されたパスにあるすべてのクラスライブラリをロードします。

3) アプリケーションクラスローダ（システムクラスローダ）：クラスローダのgetSystemClassloader()メソッドの戻り値です。ユーザークラスパスで指定されたクラスライブラリのロードを担当します。アプリケーションにカスタムクラスローダーがない場合、これがプログラムのデフォルトのクラスローダーになります。

無料のオンラインビデオ教育: Java ビデオチュートリアル

2. 保護者委任モデル

Java ローダーについての深い理解

##最上位の起動クラスローダーを除き、他のすべてのクラスローダーには独自の親クラスローダーがあります。親子関係は継承によって実装されるのではなく、親クラスローダーを再利用するための組み合わせ関係によって実装されます。

作業プロセス: クラスローダーはクラスロードリクエストを受信します –> リクエストを親クラスローダーに委任します (トップレベルのクラスローダーが開始されるまで) –> 親クラスはロードを試みます、そして読み込みの失敗は子クラスローダーにフィードバックされます –> サブクラスローダーは

親委任モデルの利点: Java の基礎となる API の安定性を確保し、カスタムの読み込みによって生じる複数の違いを回避します基本クラスと同じ名前のクラス (Object) が存在するため、Java の基本的な動作に混乱が生じます。

親委任モデルのソースコード:

メソッドは、スレッドの安全性を確保するために同期ロックを追加します。まず、クラスがロードされているかどうかを確認します。ロードされていない場合は、親を呼び出しますクラスローダー.loadClass() メソッドで、親クラスローダーが空の場合、それは起動クラスローダーを意味し、起動クラスローダーが呼び出されます。

親クラスのロードに失敗した場合は、ClassNotFoundException がスローされ、独自の findClass() メソッドを呼び出して親クラスをロードします。

protected Class<?> loadClass(String name, boolean resolve)
    throws ClassNotFoundException
{
    //同步锁
    synchronized (getClassLoadingLock(name)) {
        // 首先检车这个类是不是已被加载
        Class<?> c = findLoadedClass(name);
        if (c == null) {
            long t0 = System.nanoTime();
            try {
                if (parent != null) {
                    //如果父类不为空则调用父类加载器的loadClass方法
                    c = parent.loadClass(name, false);
                } else {
                    //没有父类则默认调用启动类加载器加载
                    c = findBootstrapClassOrNull(name);
                }
            } catch (ClassNotFoundException e) {
                //如果父类加载器找不到这个类则抛出ClassNotFoundException
            }


            if (c == null) {
                // 父类加载器失败时调用自身的findClass方法加载
                long t1 = System.nanoTime();
                c = findClass(name);


                //记录
                sun.misc.PerfCounter.getParentDelegationTime().addTime(t1 - t0);
                sun.misc.PerfCounter.getFindClassTime().addElapsedTimeFrom(t1);
                sun.misc.PerfCounter.getFindClasses().increment();
            }
        }
        if (resolve) {
            resolveClass(c);
        }
        return c;
    }
}

ログイン後にコピー

3. 親委任モデルの破棄

1. 親委任モデルの最初の破棄

が表示されました。 JDK1.2以降では、クラスローダと抽象クラスjava.lang.ClassLoaderがすでに存在していました。

したがって、上位互換性を確保するために、JDK1.2 以降、新しい保護されたメソッド findClass が ClassLoader に追加されました。ユーザーは、loadClass メソッドをオーバーライドするのではなく、独自のクラスロードロジックを findClass メソッドに記述して、カスタムクラスのロードが親委任モデルに準拠していることを確認します。

2. 2 番目の破壊

モデル自体に欠陥があります。親の委任により、各クラスローダーの基本クラスを確実に統合できます。これは、ユーザーコードが基本クラスを呼び出すときです。基本クラスがユーザーコードをコールバックする場合には適用されません。たとえば、SPI が関係するシナリオでは、必要な SPI コードをロードします。

SPI メカニズムの概要については、他の記事を参照してください。

この問題を解決するために、スレッドコンテキストローダー (Thread Context ClassLoader) が導入されました。このクラスローダーは、java.lang.Thread クラスの setContextClassLoader() メソッドを通じて設定できます。設定は親スレッドから継承されます。グローバルに何も存在しない場合、デフォルトはアプリケーションクラスローダーです。このローダーは、子クラスローダーにロードを要求する親クラスローダーのアクションを完了するために使用できます。

3. 3 番目の被害

# は、ホットデプロイメント、ホットリプレースなどのプログラムダイナミクスの追求によって引き起こされます。

たとえば、モジュラー標準 OSGi R4.2 では、親の委任のツリー構造がより複雑なネットワーク構造に変更されました。

推奨される Java 記事チュートリアル: Java 入門チュートリアル

以上がJava ローダーについての深い理解の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。