JVM 类加载机制 双亲委派机制

---

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

• 一种是启动类加载器(Bootstrap ClassLoader)，

这个类加载器使用C++语言实现，是虚拟机自身一部分；

• 一种是所有其他的类加载器，

使用Java语言实现，独立于虚拟机，继承于java.lang.ClassLoader

从Java开发人员的角度来看，类加载器可进一步划分，一般情况下提供3种系统的类加载器

• 启动类加载器(Bootstrap ClassLoader)

这个类加载器负责将存放在\lib目录下的，或被-Xbootclasspath参数所制定的路径种的，并且是被虚拟机识别的类库加载到虚拟机内存中启动类加载器无法被Java程序直接引用，用户在编写自定义类加载器时，如果需要加载请求委派到引导类加载器，可直接使用null代替即可。

• 扩展类加载器(Extension ClassLoader)

该加载器由sun.misc.Lanucher$ExtClassLoader实现，负责加载\lib\ext目录中，或者被java.ext.dirs系统变量指定路径中的类库，开发者可以直接使用扩展类加载器

• 应用程序类加载器（Application ClassLoader）

该类是ClassLoader中getSystemClassLoader()方法返回值，所以一般称为系统类加载器。负责加载用户类路径(ClassPath)上所指定的类库，开发者可以直接使用这个类加载器，如果应用程序没有自定义类加载器，一般情况下是默认的类加载器

---

类加载器

类加载器：“通过一个类的全限定名来获取描述此类的二进制字节流”这个动作放到java虚拟机外部去实现，以便让应用程序自己决定如何去获取所需要的类。实现这个动作的代码模块成为“类加载器”。
通俗的讲，虚拟机是根据类的全限定名来加载类的，那么有个问题，如果同时存在两个或多个全限定名完全一致的情况下。该如何选择加载哪个类。这就是双亲委派机制要做的工作。

在这里强加个知识点：

比较两个类是否“相等”，只有在这两个类是由同一个类加载器加载的前提下才有真正的意义，否则，即使这两个类来源于同一个class文件，被同一个虚拟机加载，只要加载他们的类加载器不同，那这两个类就必定不相等。

---

回到双亲委派的问题上，接下来了解下类加载器的种类：

1. 启动类加载器：负责加载%JAVA_HOME%\bin目录下的所有jar包，或者是-Xbootclasspath参数指定的路径；
2. 扩展类加载器：负责加载%JAVA_HOME%\bin\ext目录下的所有jar包，或者是java.ext.dirs参数指定的路径；
3. 应用程序类加载器：负责加载用户类路径上所指定的类库，如果应用程序中没有自定义加载器，那么次加载器就为默认加载器。
   加载器之间的层次关系：
   

---

双亲委派机制得工作过程：

1. 类加载器收到类加载的请求
2. 把这个请求委托给父加载器去完成，一直向上委托，直到启动类加载器
3. 启动器加载器检查能不能加载（使用findClass()方法），能就加载（结束）；否则，抛出异常，通知子加载器进行加载
4. 重复步骤三

以上就是双亲委派机制的原理

---

接下来举个例子：

大家所熟知的Object类，直接告诉大家，Object默认情况下是启动类加载器进行加载的。假设我也自定义一个Object，并且制定加载器为自定义加载器。现在你会发现自定义的Object可以正常编译，但是永远无法被加载运行。
这是因为申请自定义Object加载时，总是启动类加载器，而不是自定义加载器，也不会是其他的加载器。

---

人和事物都有缺陷，双亲委派机制也不例外，有三次得到破坏：

1. jdk1.2之间，用户直接去调用loadClass()方法；不能保证双亲委派机制的基本规则。后改成findClass()方法
2. 双亲委派机制的自我缺陷，使用了线程上下文类加载器。这种行为打破了双亲委派机制模型的层次关系来逆向使用类加载器，实际上违背了双亲委派机制的一般性原则
3. 用户对程序动态性的追求而导致的。例如鼠标，键盘灯热部署。