JVM 双亲委派模型

类加载器

从虚拟机角度看，只存在2种不同的类加载器：

• 一种是启动类加载器(Bootstrap ClassLoader)，这个类加载器使用C++语言实现，是虚拟机自身一部分；
• 一种是所有其他的类加载器，使用Java语言实现，独立于虚拟机，继承于java.lang.ClassLoader

从java开发角度来讲，有分为三种类型加载器

• 启动类加载器(Bootstrap ClassLoader) 这个类加载器负责将存放在<JAVA_HOME>\lib目录下的，或被-Xbootclasspath参数所制定的路径种的，并且是被虚拟机识别的类库加载到虚拟机内存中启动类加载器无法被Java程序直接引用，用户在编写自定义类加载器时，如果需要加载请求委派到引导类加载器，可直接使用null代替即可。
• 扩展类加载器(Extension ClassLoader) 该加载器由sun.misc.Lanucher$ExtClassLoader实现，负责加载<JAVA_HOME>\lib\ext目录中，或者被java.ext.dirs系统变量指定路径中的类库，开发者可以直接使用扩展类加载器
• 应用程序类加载器<Application ClassLoader> 该类是ClassLoader中getSystemClassLoader()方法返回值，所以一般称为系统类加载器。负责加载用户类路径(ClassPath)上所指定的类库，开发者可以直接使用这个类加载器，如果应用程序没有自定义类加载器，一般情况下是默认的类加载器

双亲委派模型图：

 

除引导类加载器外，所有其它类加载器都有其父类加载器

如果一个类加载器收到了类加载请求，它不会首先加载这个类，而是将请求委派给父类加载器去完成

所有的加载请求最终都委派给顶层的引导类加载器，只有当父类加载器无法完成加载请求（也就是搜索范围内无该类）

子加载器才会尝试自己去加载这个类

为什么采用双亲委派模型？

——使得Java类随着类加载器不同而具备带优先级的层次关系，如java.lang.Object（位于rt.jar内），无论那个类加载器要加载该类，最终都委派给顶层引导类加载器，因此Object类在程序的各种类加载环境中都是同一个类。

——如果没有双亲委派，用户自定义重名的类，将会使得系统带有多个同名的类，使得基础的Java类型体系混乱

双亲委派模型对于保证Java程序的稳定运行十分重要，它实现却很简单
————————————————
版权声明：本文为CSDN博主「一只老风铃」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/qq_33369979/article/details/87934364