Java类加载的双亲委派机制

雨点打透心脏的1/2处 2023-01-16 06:49 199阅读 0赞

# 一、类加载器 #

在JVM有 两种类型的类加载器，一种是由c++编写，一种是由java编写的，其中启动类加载器（Bootstrap  Class Loader）是由c++编写，其余的都是有java编写，由java编写的类加载器都继承自类java.lang.ClassLoader,为什么小编要这么区分呢，这是因为c++编写的，开发者无法直接获取到， 所以不允许直接通过引用进行操作。下面我们分别介绍几个类加载器：

1、**启动类(Bootstrap)加载器**：是由本地代码实现的类加载器，他负责将<Java\_Runtime\_Home>/lib下面的类库加载到内存中，例如rt.jar。由于引导类加载器涉及到虚拟机本地实现细节，开发者无法直接获取到启动类加载器的引用，所以不允许直接通过引用进行操作。其实，JVM将c++处理类加载的一套逻辑定义为启动类加载器，它是没有实体的。

2、**标准扩展(Extension)类加载**：是由Sun的ExtClassLoader（sun.misc.Launcher$ExtClassLoader）实现的。 它负责将<Java\_Runtime\_Home>/lib/ext或者由系统变量java.ext.dir指定位置中的类库加载到内存中。开发者可以直接使用标准扩展类加载器。

3、**系统（System） 类加载器**：是由Sun的AppClassLoader（sun.misc.Launcher$AppClassLoader）实现的。它负责系统类路径(CLASSPATH)中指定地方类库加载到内存中。 开发者可以直接使用系统类加载器。

各种类加载器存在逻辑上的父子关系，但是并不是真正的父子关系，因为他们之间没有从属关系。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTMwNDU0Mzc_size_16_color_FFFFFF_t_70][]

除了上面列举的 三种类加载器，还有一种比较特殊的类加载—— 线程上下文加载器

# 二、双亲委派机制描述 #

如果一个类加载器接收到加载某个类的请求，首先将加载任务委托给父类加载器，一次递归，如果父类加载器可以完成加载任务，就成功返回；只有再父类无法完成此加载任务时，才自己去加载。下面我们用一张图类描述整个过程：

![0fae56a252bf78c26184bd57af0bf379.png][]

# 三、为什么需要双亲委派机制——防止内存中出现多份同样的字节码？ #

在回到这个问题之前我们需要知道 类加载加载的类在jvm中如何存储？

![74e69ee19ed4a339adc07cbe62085e0f.png][]

从上面的图中我们可以看出，不同的类加载加载类在都在不同的区域，也就说如果我们同一个类使用不同的 类加载器加载，那么在jvm 中就会存在多份同样的字节码， 这种做法无疑是一种非常严重的资源浪费。这个时候如果我们使用 双亲委派机制，在加载某个的类的时候，就会递归向上查找，也就是首选使用Bootstra类加载器尝试加载，如果找不到再向下。这样能保证同一个类使用同一个类加载器加载。

# 四、打破双亲委派 #

因为在某些情况下父类加载器需要委托子类加载器去加载class文件。受到加载范围的限制，父类加载器无法加载到需要的文件，以Driver接口为例，由于Driver接口定义在jdk当中的，而其实现由各个数据库的服务商来提供，比如mysql的就写了`MySQL Connector`，那么问题就来了，DriverManager（也由jdk提供）要加载各个实现了Driver接口的实现类，然后进行管理，但是DriverManager由启动类加载器加载，只能记载JAVA\_HOME的lib下文件，而其实现是由服务商提供的，由系统类加载器加载，这个时候就需要启动类加载器来委托子类来加载Driver实现，从而破坏了双亲委派。

既然我们要打破双亲委派，哪肯定是因为这种机制存在一定的弊端，从上面的分析我们都知道这种机制只能向上委派，所以我们要打破这种机制无非两种思路， 向下委派或者不委派。

SPI机制是一种服务发现机制。它通过在ClassPath路径下的META-INF/services文件夹查找文件，自动加载文件里所定义的类。这一机制为很多框架扩展提供了可能，比如在Dubbo、JDBC中都使用到了SPI机制。这就是打破双亲委派的一种手段，直接通过约定的路径直接加载类。

同时我们还可以通过线程上下文加载器实现向下委派，可以通过线程上下文加载器直接制定类加载：

//获取
    Thread.currentThread().getContextClassLoader()
        
    // 设置
    Thread.currentThread().setContextClassLoader(new Classloader_4());

# 五、沙箱安全——**防止恶意代码污染java源代码** #

比如我定义了一个类名为String所在包为java.lang，因为这个类本来是属于jdk的，如果没有沙箱安全机制的话，这个类将会污染到我所有的String,但是由于沙箱安全机制，所以就委托顶层的bootstrap加载器查找这个类，如果没有的话就委托extsion,extsion没有就到aapclassloader，但是由于String就是jdk的源代码，所以在bootstrap那里就加载到了，先找到先使用，所以就使用bootstrap里面的String,后面的一概不能使用，这就保证了不被恶意代码污染。

![ff6094ee0d546ec05ee9342685658060.png][]

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTMwNDU0Mzc_size_16_color_FFFFFF_t_70]: /images/20221022/372ae08d1c5a40e5a1d1a66b671c3544.png
[0fae56a252bf78c26184bd57af0bf379.png]: /images/20221022/de22b102abc04de998bf98f7c7a5b6c4.png
[74e69ee19ed4a339adc07cbe62085e0f.png]: /images/20221022/e4245e1cea244ee2b722fae4b88c71c0.png
[ff6094ee0d546ec05ee9342685658060.png]: /images/20221022/3fc581917320443296e6af2102822b74.png