ClassLoader分类和双亲委派模式

Dear 丶 2022-12-29 09:06 154阅读 0赞

**目录**

ClassLoader分类

核心类

双亲委派模式

加载示例

--------------------

加载类的过程需要从系统外部根据类名获取其二进制数据流，途径可以是外部文件，数据库或者从网络上download，接着把它们交给JVM，让虚拟机将这些数据转化成Class实例，这一过程通过ClassLoader类加载器来完成，ClassLoader只作用在类加载过程，获取二进制流交给JVM之后，接下来的连接和初始化等操作就不再参与了，对于ClassLoader，它是一个类，里面提供了一些方法来完成加载流程，例如

public Class<?> loadClass(String name) throws ClassNotFoundException方法，通过传入类名，获取该类的一个实例，如果无法找到这个类就会抛出ClassNotFoundException异常。还有

protected final Class<?> findLoadedClass(String name)方法根据类名查找返回已经被加载的类。除了一些方法外，还有一个重要的属性是parent字段，它用来表示当前ClassLoader的双亲，没错，ClassLoader不止一个，它们分了几个级。

## ClassLoader分类 ##

ClassLoader分类有四种，自顶向下依次为启动类加载器BootStrap ClassLoader、扩展类加载器Extension ClassLoader、应用类加载器App ClassLoader和自定义类加载器，一般情况下JVM会用到前三个，自定义类加载器由我们决定是否使用来扩展虚拟机获取Class二进制流数据的方式。

![20201221121413282.PNG][]

可以看到，从底层开始，自定义类加载器的双亲是应用类加载器，应用类加载器的双亲是扩展类加载器，下同。当ClassLoader尝试加载一个类时，会从启动类加载器到扩展类加载器开始往下加载，而当JVM试图判断一个类是否存在时，便反过来从自定义类加载器开始往上查找。这四个类加载器中除了启动类外，另外三个在JVM中都可以找到与其对应的实例，只有启动类加载器没有，这个我们可以打印输出看一下：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2p1c3RpbnplbmdUTQ_size_16_color_FFFFFF_t_70][]

我们直接获取当前类ClassLoaderTree的ClassLoader，然后输出它的所有双亲类加载器，从输出结果可以看到，当前类由应用类加载器AppClassLoader加载，双亲加载器是ExtClassLoader扩展类加载器，如果小伙伴们用的是jdk 9及之后的版本，则会改为平台类加载器PlatformClassLoader。

### 核心类 ###

扩展类加载器的双亲启动类加载器BootStrap ClassLoader并没有被输出，证明在JVM中没有与之对应的对象，原因是启动类加载器作为最顶层的ClassLoader，是JVM里的核心组件，由C实现，所以没有与其对应的Java对象，负责加载系统的核心类，例如String类，String类是Java的核心类，由启动类加载器加载，从上面的例子可以看到，如果我们获取String类的ClassLoader并输出，得到的结果是null，并不是说String类没有使用ClassLoader，而是表示该类由BootStrap ClassLoader加载。

## 双亲委派模式 ##

JVM将ClassLoader分散成几个不同层次的加载器，挺符合模块化设计的，加载系统核心类时由启动类加载器负责，应用类加载器加载用户定义的类，自定义类加载器加载特殊类，一般也是用户类。在这些类加载器一同工作时，会默认开启双亲委派模式，该模式下，如果某一个类加载器收到请求，需要加载一个类，那么首先会去请求自己的双亲ClassLoader，而不是自己加载，如果双亲类加载器找不到这个类时，子类加载器才会自己去加载。为社么要这样做呢，为什么不一开始就直接自己去加载这个请求中的类呢，其实是安全问题，拿Java核心类String类来举例，假设别人自己也定义了一个String类，里面的方法做的和Java中的String类一样，只是里面逻辑过程做了些修改，然后通过自定义类加载器，就是上面说的ClassLoader中有，加载到系统中，那么我们就有可能用到一个”假”的String类。如果使用双亲委派模式的话，就可以避免这种情况的发生，还记得前面说的，String是Java的核心类，通过最顶层启动类加载器加载，当其完成对String类的加载，后面的自定义类加载器就没办法加载一个看似相同的String类了。

### 加载示例 ###

来看一个例子，假设我们定义了两个类，它们的名字都是相同的，一个类是启动型，另一个类是应用型，一开始把应用型的MyLoader类和我们的主类LoadClass放在一起，也就是同一个ClassPath下，把启动型的MyLoader放在自己的路径下，我的是F:/MyLoader文件夹里：

public class LoadClass {
    
    	public static void main(String[] args) {
    		MyLoader loader = new MyLoader();
    		loader.PrintSth();
    	}
    
    }
    public class MyLoader {
    	public void PrintSth() {
    		System.out.println("启动类版本.");
    	}
    }
    
    public class MyLoader {
    	public void PrintSth() {
    		System.out.println("应用类版本.");
    	}
    }

此时运行程序，得到的输出结果显然会是“应用类版本”：

![20201221121522469.PNG][]

因为LoadClass类会默认在自己的ClassPath下面加载需要用到的类，因为应用型的MyLoader类和主类在同一路径下，所以就会查找到。如果我们修改JVM参数-Xbootclasspath/a:F:/MyLoader来运行程序，把class的搜索路径改为我们自己的路径，这样我们F盘MyLoader文件夹下的启动型类就会被启动类加载器查找到：

![2020122112153162.PNG][]

因为我们修改了class的搜索路径，所以在和主类同一ClassPath下的应用型类没有被加载，证明了JVM在加载某个类时，是从最顶层的启动类加载器开始查找。

[20201221121413282.PNG]: /images/20221120/e154edc9db23412e9c020c704c430d72.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2p1c3RpbnplbmdUTQ_size_16_color_FFFFFF_t_70]: /images/20221120/dbe01c33cae749c581671cda34c1607e.png
[20201221121522469.PNG]: /images/20221120/6e5f6d6be80f4de3a48c056d5b7f7d1e.png
[2020122112153162.PNG]: /images/20221120/6ed4fed6c6e643d7a0b99575e8d1c714.png