詳細親クラスローダ委譲モデル

転載元を明記してくださいについてこの記事ではまず、個人的なウェブサイトが登場：クラスローダ委譲モデルは両親、これを見るために十分です

前回の記事では、我々はコーマ基本的なクラスローダの概念：クラスのライフサイクル、クラスローダ、クラスのロードとアンロード時間の役割を、というように、この記事では、我々はクラスローダの前のテキストを確認し続けますJVMクラスローダーは何を持っている：を含む知識、？それらの間の関係は何ですか？メカニズムを委任する親は何ですか？

親委譲モデル

四種類のローダー

JVM、クラスローダの観点から2つのカテゴリがあります。クラスローダや負荷の他のタイプのブートストラップ、ブートストラップクラスローダは、C ++言語である、仮想マシン自体の一部であり、他のJavaクラスローダは言語ではなく、仮想マシンで、すべての抽象クラスjava.lang.ClassLoaderの由来。

Java開発者の観点からは、以下に示すように、親クラスローダ委譲モデルを知る必要があります。

親委譲モデル

ブートストラップクラスローダ：クラスローダがで店舗を担当する、クラスローダーを起動します / Libディレクトリ、-Xbootclasspathパラメータが指定されているパスと機会の認識ジャー仮想ライブラリがメモリにロードされます。もっとぶっきらぼうにそれは、私たちはしばしばクラスjava.langの始まりということで、入れて、それがブートストラップクラスローダにロードする必要があります。
拡張クラスローダ：拡張クラスローダは、クラスローダがsun.misc.Launcher $ ExtClassLoaderによって実現され、それがロードする責任があります / libに/のextディレクトリ、またはライブラリのjava.ext.dirsすべてのシステム変数は、パスを指定しています。
アプリケーションクラスローダ：アプリケーションクラスローダは、クラスローダはで指定されたすべてのライブラリー・パス・ロードのCLASSPATHユーザー環境変数を担当してsun.misc.Launcher $ AppClassLoader、によって実装されます。アプリケーションは、そのカスタムクラスローダを住んでいない場合、これがデフォルトのクラスローダでのJavaプログラムです。
ユーザ定義のクラスローダ：（1）アイソレーション負荷クラス：必要な場合、ユーザは、一般的には、以下の場合にカスタムクラスローダを必要とする、独自のクラスローダを達成することができます。（2）クラスロード様式を変更する、特定の分離モジュールミドルウェアやアプリケーション、ミドルウェアを達成するために、フレームワーク、アプリケーションは、異なるクラスローダを使用する必要があります。（4）ソースコードは、漏れを防ぐために、例えば、クラスがデータベースネットワークからロードされる、（3）拡張クラスローダ源;親クラスローディング委任モデルは、ある時点で、必要に応じてユーザークラスを動的にロードすることができ、必須ではありません。Javaコードは簡単にソースコードの漏洩を防ぐために、バイトコードファイルのクラスを暗号化し、アプリケーションのクラスをロードするために、カスタムクラスローダを書くことができ、逆コンパイルおよび改ざんすることができます。

例1：異なるクラスローダ

クラスローダがnullになるように、次のコードでは、java.util.HashMapをのrt.jarのは、カテゴリに含まれている、DNSNameServiceクラスは、JARパッケージextディレクトリクラスに置かれているので、そのクラスローダそれはExtClassLoaderであり、MyClassLoaderTestクラスローダーは、アプリケーションクラスローダです。

import java.util.HashMap;

import sun.net.spi.nameservice.dns.DNSNameService;

public class MyClassLoaderTest {

    public static void main(String[] args) {

        System.out.println("class loader for HashMap: " + HashMap.class.getClassLoader());
        System.out.println(
            "class loader for DNSNameService: " + DNSNameService.class.getClassLoader());
        System.out.println("class loader for this class: " + MyClassLoaderTest.class.getClassLoader());
        System.out.println("class loader for Blob class: " + com.mysql.jdbc.Blob.class.getClassLoader());

    }
}

図ランに示す上述したコードを介してアクセス：

画像-20191013141845449

例2：パス管理異なるクラスローダ

このプログラムに従うことにより、あなたが見ることができ、各クラスローダは、jarファイルのパスを担当して同じではありません。

public class JVMClassLoader {

    public static void main(String[] args) {
        System.out.println("引导类加载器加载路径：" + System.getProperty("sun.boot.class.path"));
        System.out.println("扩展类加载器加载路径：" + System.getProperty("java.ext.dirs"));
        System.out.println("系统类加载器加载路径：" + System.getProperty("java.class.path"));
    }
}

画像-20191013140720888

例3：注文のクラスローダでArthasは

Arthasはは、以下に示すようにクラスローダコマンドは、現在のアプリケーションに関連するクラスローダ統計情報を表示するために使用することができ提供しました

クラスローダを示すテーブルが、現在のクラスローダアプリケーションを要約入力した後、各クラスローダのインスタンスの数の数は、クラスローダは、各クラスをロードします。
クラスローダ-tを入力した後、現在のクラスローダアプリケーションの階層を示し、それは見ることができ、拡張クラスローダーが続くブートストラップクラスローダ実際トップクラスローダシステム、アプリケーション・クラス・ローダに、ここでArthasClassLoaderはArthasはが独自のカスタムクラスローダの実現でもあります。

画像-20191013135633962

両親は、プロセスモデルを委任することができます

如果一个类加载器收到了类加载的请求，它首先不会自己去尝试加载这个类，而是把这个请求委派给父类加载器去完成，每一个层次的类加载器都是如此，因此所有的加载请求最终都应该传送到顶层的启动类加载器中，只有当父加载器反馈自己无法完成这个加载请求（它的搜索范围中没有找到所需的类）时，子加载器才会尝试自己去加载。

使用双亲委派模型来组织类加载器之间的关系，有一个显而易见的好处就是Java类随着它的类加载器一起具备了一种带有优先级的层次关系。例如类java.lang.Object，它存放在rt.jar之中，无论哪一个类加载器要加载这个类，最终都是委派给处于模型最顶端的启动类加载器进行加载，因此Object类在程序的各种类加载器环境中都是同一个类。相反，如果没有使用双亲委派模型，由各个类加载器自行去加载的话，如果用户自己编写了一个称为java.lang.Object的类，并放在程序的Class Path中，那系统中将会出现多个不同的Object类，Java类型体系中最基础的行为也就无法保证，应用程序也将会变得一片混乱。

双亲委派模型的实现非常简单，实现双亲委派的代码在java.lang.ClassLoader的loadClass()方法之中，如下面的代码所示：

    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) {
                        c = parent.loadClass(name, false);
                    } else {
                        c = findBootstrapClassOrNull(name);
                    }
                } catch (ClassNotFoundException e) {
                    // 如果父类加载器抛出ClassNotFoundException，
                    // 说明父类加载器无法完成加载请求
                }

                if (c == null) {
                    // 在父类加载器无法加载的时候，再调用本类的findClass方法进行类加载请求
                    long t1 = System.nanoTime();
                    c = findClass(name);

                    // this is the defining class loader; record the stats
                    // 当前类加载器是该类的define class loader
                    sun.misc.PerfCounter.getParentDelegationTime().addTime(t1 - t0);
                    sun.misc.PerfCounter.getFindClassTime().addElapsedTimeFrom(t1);
                    sun.misc.PerfCounter.getFindClasses().increment();
                }
            }
            if (resolve) {
                resolveClass(c);
            }
            return c;
        }
    }

破坏双亲委派模型

线程上下文加载器

如上所述，双亲委派模型很好得解决了各个类加载器的基础类的统一问题（越基础的类由越上层的加载器进行加载），如果基础类又要回调用户的类该怎么办？一个非常经典的例子就是SQL的驱动管理类——java.sql.DriverManager。

java.sql.DriverManager是Java的标准服务，该类放在rt.jar中，因此是由启动类加载器加载的，但是在应用启动的时候，该驱动类管理是需要加载由不同数据库厂商实现的驱动，但是启动类加载器找不到这些具体的实现类，为了解决这个问题，Java设计团队提供了一个不太优雅的设计：线程上下文加载器（Thread Context ClassLoader）。这个类加载器可以通过java.lang.Thread类的setContextClassLoader()方法进行设置，如果创建线程时候它还没有被设置，就会从父线程中继承一个，如果再应用程序的全局范围都没有设置过的话，那这个类加载器就是应用程序类加载器。

有了线程上下文加载器，就可以解决上面的问题——父类加载器需要请求子类加载器完成类加载的动作，这种行为实际上就是打破了双亲委派的加载规则。

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

源码分析

接下来，我们以java.sql.DriverManager为例，看下线程上下文加载器的用法，在java.sql.DriverManager类的下面这个静态块中，是JDBC驱动加载的入口。

    /**
     * Load the initial JDBC drivers by checking the System property
     * jdbc.properties and then use the {@code ServiceLoader} mechanism
     */
    static {
        loadInitialDrivers();
        println("JDBC DriverManager initialized");
    }

顺着loadInitialDrivers()方法往下看，使用线程上下文加载器的地方在ServiceLoader.load里

    private static void loadInitialDrivers() {
                // ……省去别的代码
        AccessController.doPrivileged(new PrivilegedAction<Void>() {
            public Void run() {
                            
                ServiceLoader<Driver> loadedDrivers = ServiceLoader.load(Driver.class);
                Iterator<Driver> driversIterator = loadedDrivers.iterator();
              
                try{
                    while(driversIterator.hasNext()) {
                        driversIterator.next();
                    }
                } catch(Throwable t) {
                // Do nothing
                }
                return null;
            }
        });
      //…… 省去别的代码

ServiceLoader.load方法的代码如下，JDBC的sqlDriverManager就是这里获得的上下文加载器来驱动用户代码加载指定的类的。

    public static <S> ServiceLoader<S> load(Class<S> service) {
          // 获取当前线程中的上下文类加载器
        ClassLoader cl = Thread.currentThread().getContextClassLoader();
        return ServiceLoader.load(service, cl);
    }

那么这个上下文加载器是什么时候设置进去的呢？前面我们提到了：

这个类加载器可以通过java.lang.Thread类的setContextClassLoader()方法进行设置，如果创建线程时候它还没有被设置，就会从父线程中继承一个，如果再应用程序的全局范围都没有设置过的话，那这个类加载器就是应用程序类加载器。

看下setContextClassLoader()方法别谁调用了，最终我们在Launcher中找到了如下代码：

public class Launcher {
        //……省去别的代码
    public Launcher() {
        Launcher.ExtClassLoader var1;
        try {
            var1 = Launcher.ExtClassLoader.getExtClassLoader();
        } catch (IOException var10) {
            throw new InternalError("Could not create extension class loader", var10);
        }

        try {
            this.loader = Launcher.AppClassLoader.getAppClassLoader(var1);
        } catch (IOException var9) {
            throw new InternalError("Could not create application class loader", var9);
        }

        Thread.currentThread().setContextClassLoader(this.loader);
        //……省去别的代码
    }
}

总结

この記事では、親クラスローダ委譲モデルは、親が仕事のプロセスモデルを委任確認し、ソースコード解析だけでなく、親が委任モデルを打破するために必要。最初の部分の終わりに、我々はまた、彼らは実際に使用することを検討する際の問題のトラブルシューティングにArthasはクラスローダコマンドの使用方法を示しています。

参考資料

https://www.journaldev.com/349/java-classloader#java-classloader-hierarchy
https://www.cnblogs.com/joemsu/p/9310226.html
「Java仮想マシンの深い理解」
「コード効率的なJavaの開発のマニュアル」

バックエンド技術、JVMのトラブルシューティングと最適化、Javaのインタビューの質問、個人の成長と自己管理、および他のトピックの数にこのフォーカス、第一線の開発者は、読者のために働くと成長の経験、あなたはここで何かを得ることを期待することができます提供。 Jwadu