JVM(二)：类加载器的双亲委派机制
上一篇文章讲述了JVM的加载过程，整个过程都是通过类加载器完成，Java里有如下几种类加载器
1.引导类加载器：负责加载支撑JVM运行的位于JRE的lib目录下的核心类库，比如rt.jar、charsets.jar等
2.扩展类加载器：负责加载支撑JVM运行的位于JRE的lib目录下的ext扩展目录中的JAR类包
3.应用程序类加载器：负责加载ClassPath路径下的类包，主要就是加载你自己写的那些类
4.自定义加载器：负责加载用户自定义路径下的类包
类加载器初始化过程
在上一篇文章中有一幅关于类加载过程的流程图，可以看到会创建JVM启动器实例sun.misc.Launcher。
在Launcher构造方法内部，其创建了两个类加载器，分别是sun.misc.Launcher.ExtClassLoader(扩展类加载器)和sun.misc.Launcher.AppClassLoader(应用类加载器)。
JVM默认使用Launcher的getClassLoader()方法返回的类加载器AppClassLoader的实例加载我们的应用程序。如下图：
我们通过打断点的形式进入loadClass()方法调试，会发现类加载器首先会去查找是否已经加载此类，如果没有加载过则判断父类加载器是否存在，如果存在则有父类加载器调用loadClass(name,resolve)方法加载反之使用bootstrap类加载器加载，如果父类加载器和bootstrap加载器都没找到此类，则使用当前的类加载器加载。如下图：
这个过程我们可以总结为以下流程图：
双亲委派机制说白了就是，先找父亲加载，父类找不到再有子类加载器自己处理
那么为什么要设计双亲委派机制
1.沙箱安全机制，假设我们有一个自定义类java.lang.String.class。因为类加载器会委托父类加载器优先加载，所以jdk中的string类会被优先加载，然后应用程序类加载器在加载我们的自定义String类时发现已经有一个同名的类就不会再去加载，这样便可以防止核心API库被随意篡改。如果强行打破双亲委派利用loadClass去加载则会报错，见下图：
2.避免类的重复加载：当父亲已经加载了该类时，就没有必要子ClassLoader再加载一次，保证被加载类的唯一性
如何写一个自定义加载器
通过上述的可以得出以下结论：
自定义类加载器只需要继承 java.lang.ClassLoader 类，该类有两个核心方法，一个是loadClass(String, boolean)，实现了双亲委派机制，还有一个方法是findClass，默认实现是空方法，所以我们自定义类加载器主要是重写findClass方法。增加对包路径的判断即可实现我们自己的自定义类走自定义加载器，其他的依然是双亲委派机制,见下图
最后一个问题：双亲委派机制是否可以打破？哪里需要打破双亲委派机制？
以Tomcat类加载为例，Tomcat 如果使用默认的双亲委派类加载机制行不行？
现实情况下，同一台服务器上可能会部署多个应用，而不同应用内相同的组件又是不同版本的，如果使用双亲委派那势必会有冲突。
因此要保证每个应用程序的类库都是独立的，保证相互隔离，这就打破了双亲委派机制。
tips：Tomcat热加载，每个jsp会实例化一个独立的类加载器，当被替换后会将老的类加载器卸载重新实例化一个新的类加载器