双亲委派模型

亦凉 2022-07-12 13:26 224阅读 0赞

说道双亲委派模型，就要从类加载器说起。。。。。。。。。。。

[Java][]虚拟机类加载过程是把Class类文件加载到内存，并对Class文件中的数据进行校验、转换解析和初始化，最终形成可以被虚拟机直接使用的java类型的过程。

在加载阶段，java虚拟机需要完成以下3件事：

a.通过一个类的全限定名来获取定义此类的二进制字节流。

b.将定义类的二进制字节流所代表的静态存储结构转换为方法区的运行时[数据结构][Link 1]。

c.在java堆中生成一个代表该类的java.lang.Class对象，作为方法区数据的访问入口。

而类的加载过程是通过类加载器完成的。

在Java中，任意一个类都需要由加载它的类加载器和这个类本身一同确定其在java虚拟机中的唯一性，即比较两个类是否相等，只有在这两个类是由同一个类加载器加载的前提之下才有意义，否则，即使这两个类来源于同一个Class类文件，只要加载它的类加载器不相同，那么这两个类必定不相等(这里的相等包括代表类的Class对象的equals()方法、isAssignableFrom()方法、isInstance()方法和instanceof关键字的结果)。

看下面的例子：

**\[java\]**  [view plain][]   [copy][view plain]

1.  **package** com.test;    
2.      
3.  **public** **class** ClassLoaderTest \{    
4.      **public** **static** **void** main(String\[\] args)**throws** Exception\{    
5.          //匿名内部类实现自定义类加载器    
6.      ClassLoader myClassLoader = **new** ClassLoader()\{    
7.      **protected** Class<?> findClass(String name)**throws** ClassNotFoundException\{    
8.          //获取类文件名    
9.      String filename = name.substring(name.lastIndexOf(“.”) + 1) + “.**class**”;    
10.     InputStream in = getClass().getResourceAsStream(filename);    
11.     **if**(in == **null**)\{    
12.     **throw** RuntimeException(“Could not found **class** file:” + filename);    
13. \}    
14. **byte**\[\] b = **new** **byte**\[in.available()\];    
15. **return** defineClass(name, b, 0, b.length);    
16. \}**catch**(IOException e)\{    
17.     **throw** **new** ClassNotFoundException(name);    
18. \}    
19. \};    
20. Object obj = myClassLoader.loadClass(“com.test.ClassLoaderTest”).newInstance();    
21. System.out.println(obj.getClass());    
22. System.out.println(obj **instanceof** com.test. ClassLoaderTest);    
23. \}    
24. \}

输出结果如下：

com.test.ClassLoaderTest

false

之所以instanceof会返回false，是因为com.test.ClassLoaderTest类默认使用Application ClassLoader加载，而obj是通过自定义类加载器加载的，类加载不相同，因此不相等。

说到这里就轮到双亲委派模型出场了。

先看双亲委派模型的经典体系统：

![20160102154038185][]

做一个简单解释：

(1).BootStrap ClassLoader：启动类加载器，负责加载存放在%JAVA\_HOME%\\lib目录中的，或者通被-Xbootclasspath参数所指定的路径中的，并且被java虚拟机识别的(仅按照文件名识别，如rt.jar，名字不符合的类库，即使放在指定路径中也不会被加载)类库到虚拟机的内存中，启动类加载器无法被java程序直接引用。

(2).Extension ClassLoader：扩展类加载器，由sun.misc.Launcher$ExtClassLoader实现，负责加载%JAVA\_HOME%\\lib\\ext目录中的，或者被java.ext.dirs系统变量所指定的路径中的所有类库，开发者可以直接使用扩展类加载器。

(3).Application ClassLoader：应用程序类加载器，由sun.misc.Launcher$AppClassLoader实现，负责加载用户类路径classpath上所指定的类库，是类加载器ClassLoader中的getSystemClassLoader()方法的返回值，开发者可以直接使用应用程序类加载器，如果程序中没有自定义过类加载器，该加载器就是程序中默认的类加载器。

这里需要注意的是上述三个JDK提供的类加载器虽然是父子类加载器关系，但是没有使用继承，而是使用了组合关系。

从JDK1.2开始，java虚拟机规范推荐开发者使用双亲委派模式(ParentsDelegation Model)进行类加载，其加载过程如下：

(1).如果一个类加载器收到了类加载请求，它首先不会自己去尝试加载这个类，而是把类加载请求委派给父类加载器去完成。

(2).每一层的类加载器都把类加载请求委派给父类加载器，直到所有的类加载请求都应该传递给顶层的启动类加载器。

(3).如果顶层的启动类加载器无法完成加载请求，子类加载器尝试去加载，如果连最初发起类加载请求的类加载器也无法完成加载请求时，将会抛出ClassNotFoundException，而不再调用其子类加载器去进行类加载。

双亲委派 模式的类加载机制的优点是java类它的类加载器一起具备了一种带优先级的层次关系，越是基础的类，越是被上层的类加载器进行加载，保证了java程序的稳定运行。双亲委派模式的实现：

**\[java\]**  [view plain][]   [copy][view plain]

1.  <span style="color:\#333333;">**protected** **synchronized** Class<?> loadClass(String name, Boolean resolve) **throws** ClassNotFoundException\{    
2.      //首先检查请求的类是否已经被加载过    
3.      Class c = findLoadedClass(name);    
4.      **if**(c == **null**)\{    
5.      **try**\{    
6.          **if**(parent != **null**)\{ //委派父类加载器加载    
7.      c = parent.loadClass(name, **false**);    
8.  \}    
9.  **else**\{ //委派启动类加载器加载    
10.     c = findBootstrapClassOrNull(name);     
11. \}    
12. \}**catch**(ClassNotFoundException e)\{    
13.     //父类加载器无法完成类加载请求    
14. \}    
15. **if**(c == **null**)\{ //本身类加载器进行类加载    
16.     c = findClass(name);    
17. \}    
18. \}    
19. **if**(resolve)\{    
20.     resolveClass(c);    
21. \}    
22. **return** c;    
23. \}  </span>

通过双亲委派模型我们就能很好解决文章开始我们自定义的类加载器所出现的问题。

这里需要注意的是在JDK1.2之前，类加载尚未引入双亲委派模式，因此实现自定义类加载器时常常重写loadClass方法，提供双亲委派逻辑，从JDK1.2之后，双亲委派模式已经被引入到类加载体系中，自定义类加载器时不需要在自己写双亲委派的逻辑，因此不鼓励重写loadClass方法，而推荐重写findClass方法。

[JVM如何加载一个类的过程，双亲委派模型中有哪些方法][JVM]

[Java]: http://lib.csdn.net/base/javase
[Link 1]: http://lib.csdn.net/base/datastructure
[view plain]: http://blog.csdn.net/p10010/article/details/50448491#
[20160102154038185]: /images/20220710/634e4179d6db4f4a8f6c9447dd19fcbe.png
[JVM]: http://blog.csdn.net/wzf2589646/article/details/51113052