JVM类加载子系统第二篇：双亲委派（总体的第四篇）

同学郑学习

已于 2022-02-06 12:27:56 修改

阅读量339

点赞数

分类专栏： # java虚拟机内容文章标签： java 开发语言后端 java虚拟机深入理解JVM

于 2022-01-21 10:30:43 首次发布

本文链接：https://blog.csdn.net/weixin_46635575/article/details/122578677

版权

16 篇文章 0 订阅

订阅专栏

在这里插入图片描述

在java的世界里面，我们类加载是这样的，比如首先会去找到你有main方法的类（是你应用程序的入口方法），根据这个里面去加载其他的类，假设你在main方法里面有一个实例化你定义的XX类，用的时候去加载，不用的话是不会去加载的。

在这里插入图片描述

原理是这样，接下来自己编写类来分析（我们自定义一个java.lang.String的一个类）

问题：我们发现它并没有去加载我们的自定义的一个String类，而是去加载了系统系统的核心类，为什么呢？

问题：我们发现它并没有去加载我们的自定义的一个String类，而是去加载了系统系统的核心类，为什么呢？

分析问题前，先把这张图记住

从上一篇笔记中就写到：
- 最顶端的BootStrap就是进行java，javax，sun等开头的核心类库进行加载
- Extension 则是对我们的jre下的lib下的ext类进行加载
- 系统类加载器我们自定义类的加载器
原因就是：首先我们的类我们自定义的类JVMTest首先交于上一层的加载器加载，如果上一层的上面还有加载器，就又往上面递交上去，到最后的BootStrap加载器加载。
- 到了最顶端后，如果能是java，javax，sun路径开头的就加载，显然我们JVMTest里面的String类会被加载，也就它加载了，下面的就不会再加载了，到这里结束了。这也是区分包的原因了
- 但是如果不是因java，javax，sun开头的，那他处理不了，交给下层处理，如果是在jre/lib/etx下面的类，那么扩展类加载器就加载，如果它也加载不了，那么进行向下递交。
同样的道理，另外一种表现形式你能分析吗？