JVM----双亲委派模型
加载类的开放性
我们在了解双亲委派模型之前，不得不先了解一下什么是类加载器。虚拟机设计团队之初是希望类加载过程“通过一个类的全限定名来获取描述该类的二进制字节流”这个动作能放到虚拟机外部实现，以便于让程序自己决定如何获取该类，实现这个动作的代码的工具成为类加载器。
可能很多人觉得类加载器，顾名思义，就是个加载类的嘛，有啥大不了的，但是类加载这个过程是很严格的，对于任意一个类，我们都需要由加载他的类加载器和类的本身来决定该类在虚拟机之中的唯一性。什么意思呢？？就是说我们的虚拟机要比较两个类是否相等，那前提条件是就是这两个类必须是在同一个类加载器加载的，如果两个类都不是由同一个加载器加载的，那么这俩类就一定不相等，所以就没有比较的意义！
public class ClassLoaderTest {
public static void main(String[] args) throws Exception {
ClassLoader myLoader = new ClassLoader() {
@Override
public Class<?> loadClass(String name) throws ClassNotFoundException {
try {
String fileName = name.substring(name.lastIndexOf(".") + 1) + ".class";
InputStream is = getClass().getResourceAsStream(fileName);
if (is == null) {
return super.loadClass(name);
}
byte[] b = new byte[is.available()];
is.read(b);
return defineClass(name, b, 0, b.length);
} catch (IOException e) {
throw new ClassNotFoundException(name);
}
}
};
Object obj = myLoader.loadClass("org.fenixsoft.classloading.ClassLoaderTest").newInstance();
System.out.println(obj.getClass());
System.out.println(obj instanceof org.fenixsoft.classloading.ClassLoaderTest);
}
}
就比如上面这段代码，代码运行结果很令人失望，虽然打印出的类路径是相同的，但是比较后的结果却是false，这是为啥啊？好气啊，明明类路径一样，但是结果却不同？
这是因为，我们自己实现了属于我们自己的类加载器，我们选择了我们自己的加载路径去加载该类，而另一个同类路径名的类却是由另一个加载器（应用程序类加载器）加载的，只要不是同一个类加载器加载的类，一定不是同一个类！！
双亲委派模型
从java虚拟机角度来讲，只存在两种不同的类加载器：
（1）一种是启动类加载器，由C++语言实现的，属于虚拟机的一部分；
（2）一种是所有的其他类加载器，这些都是由Java实现的，独立于虚拟机外部，继承自java.lang.ClassLoader；
但是从开发人员角度来讲，应该分的再细一些，绝大部分程序都使用到了以下三种系统提供的类加载器：
（1）启动类加载器，该加载器是C++实现的，它负责加载存放于<JAVA_HOME>\lib目录下的类，它是仅仅按照文件的名字来识别的，名字不符合的类就算放到该目录下，也是毫无卵用的.....
（2）扩展类加载器，它是负责加载<JAVA_HOME>\lib\Ext目录下的；
（3）应用程序类加载器，这个类也被称为系统类加载器，它是负责用户类路径classpath上指定的类库，开发者可以直接使用这个加载器；
应用程序都是由这三种加载器相互配合进行加载的，有必要的话，还可以实现属于自己的类加载器，这几种加载器关系如图：
这种层次结构我们就称之为双亲委派模型，可以很直观的看出除了顶层的启动类加载器外，其他的都有属于自己的父类加载器。但是我们在这里不要混淆一个概念，就是继承（Inheritance），这个结构图并不是继承关系而是通过组合的方式来实现向上委托的.......
双亲委派的工作流程就是：如果一个类加载器收到了类加载的请求，它是不会自己立马亲自动手去加载的（比较懒，哈哈！），而是把该请求委托给父类，每一层都是如此，到了顶层后，这时就无法再向上传递了，所有的请求都集中到了启动类加载器，当父类反馈自己无法满足这个请求时，这时就会再把请求一层层向下传递。
这样的好处是啥？？相信大家看这种层次结构应该很清晰，但是这有什么意义吗？比如java.lang.Object，他是存在rt.jar里的，不论哪种加载器，是系统自带的也好还是我们自己实现的也好，都会把请求一层层的往上委托，直到启动类加载器，而启动类加载器一看，自己是有这个类的，所以加载，因此Object在程序的各个类加载器的加载下永远都是同一个类。反之，没有双亲委派模型，任由各个类加载器自己去加载的话，比如我们开发者自己写了Object类，包名也是java.lang，那么系统中就会出现各种各样的Object，每一个层级的类加载器都加载了自己具有个性的Object，那么作为程序中这么基础这么重要的Object，他的唯一性得不到保证，应用程序就会杂乱不堪。
双亲委派模型的作用想必到这里很多人应该清楚了，觉得：“哇！这个模型还真的是很强大呢...”。他的实现也是非常简单的：
protected synchronized Class<?> loadClass(String name,boolean resolve)throws ClassNotFoundException{
//check the class has been loaded or not
Class c = findLoadedClass(name);
if(c == null){
try{
if(parent != null){
c = parent.loadClass(name,false);
}else{
c = findBootstrapClassOrNull(name);
}
}catch(ClassNotFoundException e){
//if throws the exception ,the father can not complete the load
}
if(c == null){
c = findClass(name);
}
}
if(resolve){
resolveClass(c);
}
return c;
}
从图中的代码，我们大致可以看出这个委托机制是如何实现的，当一个加载器收到请求后，首先会判断一下当前这个类是否已经被加载过，如果没有被加载的话，开始委托父类加载器了（就是这么懒，哈哈），如果没有父类的话，就默认使用启动类加载器。如果抛异常了，就代表当前类加载器的父类无法加载，满足不了请求，那么此时只能自己亲自出马了！！所以什么事还是自己来做的靠谱啊哈哈。
总结
当然，这种模型一直都不是强制性的，而是推荐我们这么做的，往年就出现过打破该机制的事件，典型的例子就是JNDI服务，他的代码是交给启动类加载器去实现的，但是当JNDI要对资源进行集中化管理时，他需要调用其他公司实现并部署在应用程序的classpath下的JNDI接口，因为这些代码是需要我们开发者自己来实现的，这时启动类加载器是无法识别这些类的，于是乎出现了一种线程上下文加载器，JNDI服务可以调用该加载器去加载所需要的代码，就是通过父类加载器去请求子类加载器来实现的，这已经很明显的违背了双亲委派模型。
