原创 | jvm05、类加载器

偏执的太偏执、 2021-09-17 00:54 261阅读 0赞

上一次我们简单说了下java中的类加载，那个知识点我们要记住的就是类的加载过程以及那几个阶段主要是干啥的，不过在谈及类加载的时候一定有一个知识点那就是类加载器。

什么？你不知道类加载器？那你一定知道ClassLoader或者双亲委派机制吧！

我记得我最先知道双亲委派的时候好像是从面试题中看到的，当时就觉得，什么玩意，还双亲委派，有点高大上，不知道是什么，那个时候我更不知道双亲委派是关于类加载的，这些知识点在当时都是知识盲区。

不过随着学习，积累的知识点不断变多，也就知道了什么是双亲委派机制。

双亲委派简单点来说是类加载器之间的一种模式，或者可以说是规则，也就是他们会按照这个模式去加载类，起了个名字叫做双亲委派，要知道什么是双亲委派，还要知道什么是类加载器。

那什么是类加载器呢？一个类如果被使用的话是会被加载进内存的，但是他们是如何加载进内存的呢？这就需要一个媒介，这个媒介就是类加载器，其实从和这个类加载器的名字就显而易见就是用来加载类的。

简单知道了类加载器，接下来你还要知道，其实类加载器不止一个，有好几个，谈及类加载器，一定会有这么一个图

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NpbmF0XzMzOTIxMTA1_size_16_color_FFFFFF_t_70]

对，就是这个图，图上有三个重要的类加载器，可以这么说，类加载器也就是这几个了，当然我们还可以自定义类加载器，不过这个都是后话。

我在图上也标出来了，对于第一个启动类加载器，它是使用C加加实现的，而且是属于虚拟机自身的一部分，但是下面的两个就不同了，扩展类加载器和应用类加载器都是使用java语言实现的，而且是虚拟机之外，他们俩都是要靠启动类加载器来加载他们的，用C++实现的就是牛啊。

这里你还要知道的一个知识点就是关于子类和父类这个概念，这里可不是继承的关系，而是组合的关系，另外有这么一个例子，一起来看一下

public class ClassLoaderTest {
        public static void main(String[] args) {
            ClassLoader loader = Thread.currentThread().getContextClassLoader();
            System.out.println(loader);
            System.out.println(loader.getParent());
            System.out.println(loader.getParent().getParent());
        }
    }

这个例子的意思就是看看应用类加载器的父类是谁，再看看扩展类加载器以及启动类的父类，结果是这样的

![在这里插入图片描述][20181115211314122.jpg]

你会发现，应用类的父类是扩展类，但是扩展类的却是null，这是为啥呢？也很简单啊，因为启动类加载器是C加加实现的，扩展类是java嘛，压根就不是一个品种啊。

到这里，我们似乎熟悉了类加载器的一些知识，接下来我们继续。

你还要了解的就是这三个类加载器都是用来加载哪些类的，这个你网上一搜一大把，都是很直白的话，你看看，就是这些

启动类加载器：这个加载器可以说是顶层的，古老的，厉害的，它主要是用来加载放在JDK\\jre\\lib下或者被-Xbootclasspath参数指定的路径中的，并且能被虚拟机识别的类库（如rt.jar，所有的java.开头的类均被Bootstrap ClassLoader加载）。启动类加载器是无法被Java程序直接引用的。

然后我就去看看了这个目录下都是些什么玩意

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NpbmF0XzMzOTIxMTA1_size_16_color_FFFFFF_t_70 1]

哦，知道了就是用来加载这些类库的。再来看这个扩展类加载器

扩展类加载器：这个加载器是由sun.misc.Launcher$ExtClassLoader实现，它负责加载JDK\\jre\\lib\\ext目录中，或者由java.ext.dirs系统变量指定的路径中的所有类库（如javax.开头的类），开发者可以直接使用扩展类加载器。

嗯，说的也比较清晰，这个目录就不去看了

最后的这个应用类加载器可以说就是我们平常使用的默认加载器，该类加载器由sun.misc.Launcher$AppClassLoader来实现，它负责加载用户类路径（ClassPath）所指定的类，开发者可以直接使用该类加载器，如果应用程序中没有自定义过自己的类加载器，一般情况下这个就是程序中默认的类加载器。

到这里，我们也简单的了解了这三个类加载器，其实在实际的加载中是他们三个互相协作进行，这才有了接下来我们要说的双亲委派模式。

那么，这就来说说这个双亲委派吧！

什么是双亲委派机制呢？其实也蛮好理解的，这个类加载器是用来加载类的，而这三个类加载器都可以用来加载类啊，那么如果要加载一个类的话，谁先来加载呢，通常情况下是这样的，要加载的这个类首先到达这个类的默认类加载器，也就是应用类加载器，但是呢这个应用类加载器并不会去加载它，而是把这个类扔给他的父类也就是扩展类加载器，而这个扩展类加载器也会把这个类再次丢给启动类加载器来加载。

现在这个类到达了启动类加载器，没办法，上面没人了，只能自己加载了，如果启动类可以加载那就成功返回，实在加不了的话就把这个类原路返回。所以也有可能最后还是得这个应用类加载器来加载。

在这个过程中，我就感觉这个类像是个没人要的孤儿，而这个什么双亲委派不就是坑爹吗？

那么，这个双亲委派有啥用呢？为什么要这样搞？你还别说，用处蛮大，首先一点就是这样可以避免重复加载，也就是如果父类加载器已经加载过这个类的话，子类加载器就不需要再次加载了，另外还有非常重要的一点就是安全性，要知道，java的核心api类库都是被启动类加载器加载的，如果外部突然要加载一个，一个比如java.lang.xxx的话，这个会被传到启动类加载器，启动类加载器发现这个已经加载过啦，所以不管你，直接返回已经加载的，这样就有效的防止核心api被篡改。

多么好的双亲委派啊，坑爹就坑爹吧！

虚拟机对于类的加载就是采用这样的一种模式，就是我们经常听说的双亲委派啦，接下来，还有一个知识点那就是这些个类加载器其实我们还可以自定义，不过，感觉这一篇说的够多了，先就此打住！

来日方长，不着急！

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NpbmF0XzMzOTIxMTA1_size_16_color_FFFFFF_t_70]: /images/20210813/8873a794f2864e0ba8dd57f552c9dc45.png
[20181115211314122.jpg]: /images/20210813/81f2c5ca81be4ef3ae169ef36fd14fe2.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NpbmF0XzMzOTIxMTA1_size_16_color_FFFFFF_t_70 1]: /images/20210813/37003f6f4b994acd8c9f472b0848c014.png