Java虚拟机类加载机制（三）——类加载器

类加载器：实现 “ 通过类的全限定名来获取描述此类的二进制字节流 ” 的模块

类加载器种类：

• 启动类加载器：负责加载支撑JVM运行的位于jre/lib目录下的核心类库（例如：String、Object类），在虚拟机启动时就会加载完，以支撑虚拟机的运行。对于hotspot，这个类加载器使用C++实现。
• 扩展类加载器：负责加载支撑JVM运行的位于jre/lib/ext中的JAR包。由Java语言实现，父类加载器为null。
• 应用程序类加载器：负责加载用户路径ClassPath下的类库。由Java语言实现，父类加载器为ExtClassLoader。

类加载器加载Class大致要经过如下8个步骤：

1. 检测此Class是否载入过，即在缓冲区中是否有此Class，如果有直接进入第8步，否则进入第2步。
2. 如果没有父类加载器，则要么Parent是根类加载器，要么本身就是根类加载器，则跳到第4步，如果父类加载器存在，则进入第3步。
3. 请求使用父类加载器去载入目标类，如果载入成功则跳至第8步，否则接着执行第5步。
4. 请求使用根类加载器去载入目标类，如果载入成功则跳至第8步，否则跳至第7步。
5. 当前类加载器尝试寻找Class文件，如果找到则执行第6步，如果找不到则执行第7步。
6. 从文件中载入Class，成功后跳至第8步。
7. 抛出ClassNotFountException异常。
8. 返回对应的java.lang.Class对象。

类加载机制：

• 全盘负责：所谓全盘负责，就是当一个类加载器负责加载某个Class时，该Class所依赖和引用其他Class也将由该类加载器负责载入，除非显示使用另外一个类加载器来载入。
• 双亲委派：所谓的双亲委派，则是先让父类加载器试图加载该Class，只有在父类加载器无法加载该类时才尝试从自己的类路径中加载该类。通俗的讲，就是某个特定的类加载器在接到加载类的请求时，首先将加载任务委托给父加载器，依次递归，如果父加载器可以完成类加载任务，就成功返回；只有父加载器无法完成此加载任务时，才自己去加载。
• 缓存机制。缓存机制将会保证所有加载过的Class都会被缓存，当程序中需要使用某个Class时，类加载器先从缓存区中搜寻该Class，只有当缓存区中不存在该Class对象时，系统才会读取该类对应的二进制数据，并将其转换成Class对象，存入缓冲区中。这就是为很么修改了Class后，必须重新启动JVM，程序所做的修改才会生效的原因。

双亲委派机制

双亲委派机制要求除了顶层的启动类加载器外，其余的类加载器都应当有自己的父类加载器，但这里的父子关系是组合关系

组合关系，是关联关系的一种，是比聚合关系强的关系。它要求普通的聚合关系中代表整体的对象负责代表部分对象的生命周期，组合关系是不能共享的。代表整体的对象需要负责保持部分对象和存活，在一些情况下将负责代表部分的对象湮灭掉。代表整体的对象可以将代表部分的对象传递给另一个对象，由后者负责此对象的生命周期。换言之，代表部分的对象在每一个时刻只能与一个对象发生组合关系，由后者排他地负责生命周期。部分和整体的生命周期一样。

对于我们写出来的.class文件，即对应应用程序加载器，它在加载时，首先会向上委托，委托给他的父亲，即扩展类加载器，扩展类加载器继续向上委托，给启动类加载器，而启动类加载器没有父类，则在启动类加载器查找是否有这个类，有则加载，无则打回；然后在扩展类加载器中找，有则加载，无则打回；最后在应用程序类加载器中加载。

双亲委派机制的优势：采用双亲委派模式的是好处是Java类随着它的类加载器一起具备了一种带有优先级的层次关系，通过这种层级关可以避免类的重复加载，当父亲已经加载了该类时，就没有必要子ClassLoader再加载一次。其次是考虑到安全因素，java核心api中定义类型不会被随意替换，假设通过网络传递一个名为java.lang.Integer的类，通过双亲委托模式传递到启动类加载器，而启动类加载器在核心Java API发现这个名字的类，发现该类已被加载，并不会重新加载网络传递的过来的java.lang.Integer，而直接返回已加载过的Integer.class，这样便可以防止核心API库被随意篡改。

我们以一个简单的代码为例：

我们自己定义一个String类，注意在java.lang包中也有一个系统自带的String类，而我们定义的这个类，包名也叫做java.lang，运行结果怎么样呢 ？

为啥会找不到main方法？
这里就要从双亲委托机制进行解释：我们定义的这个类在加载时首先是对应应用程序类加载器，它要向上委托，直到启动类加载器。
上面已经说过，启动类加载器加载的是位于jre/lib目录下的核心类库，其中就有String类，这个String类就在java.lang 中，所以我们自定义的这个String类在最上层的启动类加载器中被核心类库里的String类替换掉了！

参考文章：https://blog.csdn.net/m0_38075425/article/details/81627349