双亲委派模型及如何打破
今天我们来讲JVM类加载机制详解最重要的一环：双亲委派模型：
基本概念
定义
双亲委派模型要求除了顶层的启动类加载器外，其余的类加载器都应当有自己的父类加载器。
双亲委派模型的工作过程是：
如果一个类加载器收到了类加载的请求，它首先不会自己去尝试加载这个类，而是把这个请求委派给父类加载器去完成。
每一个层次的类加载器都是如此。因此，所有的加载请求最终都应该传送到顶层的启动类加载器中。
只有当父加载器反馈自己无法完成这个加载请求时（搜索范围中没有找到所需的类），子加载器才会尝试自己去加载。
很多人对“双亲”一词很困惑。“双亲”只是“parents”的直译，实际上并不表示汉语中的父母双亲，而是一代一代很多parent，即parents。
作用
对于任意一个类，都需要由加载它的类加载器和这个类本身一同确立其在虚拟机中的唯一性，每一个类加载器，都拥有一个独立的类名称空间。因此，使用双亲委派模型来组织类加载器之间的关系，有一个显而易见的好处：类随着它的类加载器一起具备了一种带有优先级的层次关系。
例如类java.lang.Object，它由启动类加载器加载。双亲委派模型保证任何类加载器收到的对java.lang.Object的加载请求，最终都是委派给处于模型最顶端的启动类加载器进行加载，因此Object类在程序的各种类加载器环境中都是同一个类。
相反，如果没有使用双亲委派模型，由各个类加载器自行去加载的话，如果用户自己编写了一个称为java.lang.Object的类，并用自定义的类加载器加载，那系统中将会出现多个不同的Object类，Java类型体系中最基础的行为也就无法保证，应用程序也将会变得一片混乱。
结构
系统提供的类加载器
在双亲委派模型的定义中提到了“启动类加载器”。包括启动类加载器，绝大部分Java程序都会使用到以下3种系统提供的类加载器：
开发者可以直接使用扩展类加载器。
负责将存放在＜JAVA_HOME＞/lib目录中的，或者被-Xbootclasspath参数所指定的路径中的，并且是虚拟机按照文件名识别的（如rt.jar，名字不符合的类库即使放在lib目录中也不会被加载）类库加载到虚拟机内存中。
启动类加载器无法被Java程序直接引用，用户在编写自定义类加载器时，如果需要把加载请求委派给引导类加载器，那直接使用null代替即可。
JDK中的常用类大都由启动类加载器加载，如java.lang.String、java.util.List等。需要特别说明的是，启动类Main class也由启动类加载器加载。
扩展类加载器（Extension ClassLoader）
由sun.misc.Launcher$ExtClassLoader实现。
负责加载＜JAVA_HOME＞/lib/ext目录中的，或者被java.ext.dirs系统变量所指定的路径中的所有类库。
应用程序类加载器（Application ClassLoader）
由sun.misc.Launcher$AppClassLoader实现。由于这个类加载器是ClassLoader.getSystemClassLoader()方法的返回值，所以一般也称它为系统类加载器。
它负责加载用户类路径ClassPath上所指定的类库，开发者可以直接使用这个类加载器。如果应用程序中没有自定义过自己的类加载器，一般情况下这个就是程序中默认的类加载器。
启动类Main class、其他如工程中编写的类、maven引用的类，都会被放置在类路径下。Main class由启动类加载器加载，其他类由应用程序类加载器加载。
双亲委派模式：
双亲委派模式要求除了顶层的启动类加载器外，其余的类加载器都应当有自己的父类加载器，请注意双亲委派模式中的父子关系并非通常所说的类继承关系，而是采用组合关系来复用父类加载器的相关代码，类加载器间的关系如下：
双亲委派模式是在Java 1.2后引入的，其工作原理的是，如果一个类加载器收到了类加载请求，它并不会自己先去加载，而是把这个请求委托给父类的加载器去执行，如果父类加载器还存在其父类加载器，则进一步向上委托，依次递归，请求最终将到达顶层的启动类加载器，如果父类加载器可以完成类加载任务，就成功返回，倘若父类加载器无法完成此加载任务，子加载器才会尝试自己去加载，这就是双亲委派模式
双亲委派模式优势
采用双亲委派模式的是好处是Java类随着它的类加载器一起具备了一种带有优先级的层次关系，通过这种层级关可以避免类的重复加载，当父亲已经加载了该类时，就没有必要子ClassLoader再加载一次。
其次是考虑到安全因素，java核心api中定义类型不会被随意替换，假设通过网络传递一个名为java.lang.Integer的类，通过双亲委托模式传递到启动类加载器，而启动类加载器在核心Java API发现这个名字的类，发现该类已被加载，并不会重新加载网络传递的过来的java.lang.Integer，而直接返回已加载过的Integer.class，这样便可以防止核心API库被随意篡改。
可能你会想，如果我们在classpath路径下自定义一个名为java.lang.SingleInterge类(该类是胡编的)呢？该类并不存在java.lang中，经过双亲委托模式，传递到启动类加载器中，由于父类加载器路径下并没有该类，所以不会加载，将反向委托给子类加载器加载，最终会通过系统类加载器加载该类。但是这样做是不允许，因为java.lang是核心API包，需要访问权限，强制加载将会报出如下异常
实现原理：
实现双亲委派的代码都集中在ClassLoader#loadClass()方法之中。简写如下：
public abstract class ClassLoader {
...
public Class<?> loadClass(String name) throws ClassNotFoundException {
return loadClass(name, false);
}
protected Class<?> loadClass(String name, boolean resolve)
throws ClassNotFoundException {
synchronized (getClassLoadingLock(name)) {
Class<?> c = findLoadedClass(name);
if (c == null) {
...
try {
if (parent != null) {
c = parent.loadClass(name, false);
} else {
c = findBootstrapClassOrNull(name);
}
} catch (ClassNotFoundException e) {
}
if (c == null) {
...
c = findClass(name);
// do some stats
...
}
}
if (resolve) {
resolveClass(c);
}
return c;
}
}
protected Class<?> findClass(String name) throws ClassNotFoundException {
throw new ClassNotFoundException(name);
}
...
}首先，检查目标类是否已在当前类加载器的命名空间中加载（即，使用二元组
<类加载器实例，全限定名>区分不同类）。如果没有找到，则尝试将请求委托给父类加载器（如果指定父类加载器为null，则将启动类 加载器作为父类加载器；如果没有指定父类加载器，则将应用程序类加载器作为父类加载器），最终所有类都会委托到启动类加载器。
如果父类加载器加载失败，则自己加载。
默认resolve取false，不需要解析，直接返回。
自定义类加载器的正确姿势
系统提供的3种类加载器分别负责各路径下的Java类的加载。如果用户希望自定义一个类加载器（如从网络中读取class字节流，以加载新的类），该如何做呢？
错误姿势
先来看几个类加载的错误姿势。
再次提醒，以下这些错误姿势一定不影响编译，因为加载行为发生在运行期。
不定义类加载器
现在用户自定义了一个sun.applet.Main类，但不定义类加载器：
package sun.applet;
/**
* Created by chevytech
*/
public class Main {
public Main() {
System.out.println("constructed");
}
public static void main(String[] args) {
System.out.println("recognized as sun.applet.Main in jdk," +
" and there isn't any main method");
}
}为保持与后续实验的连贯性，这里没有选择常用的java.lang包下的类。原因见后。
将该类作为Main class启动，会输出什么呢？或许你以为会输出12-13行声明的字符串，现实却总会啪啪啪抚摸我们的脸庞：
用法: appletviewer <options> url
其中, <options> 包括:
-debug 在 Java 调试器中启动小应用程序查看器
-encoding <encoding> 指定 HTML 文件使用的字符编码
-J<runtime flag> 将参数传递到 java 解释器
-J 选项是非标准选项, 如有更改, 恕不另行通知。不管这些东西从哪来的，总之不是我们定义的。
实际被选中的Main class是jdk中的sun.applet.Main类。如果没有定义类加载器，则会使用默认的类加载器（应用程序类加载器）和默认的类加载行为（ClassLoader#loadClass()）。由双亲委派模型可知，最终将由启动类加载器加载＜JAVA_HOME＞/lib/rt.jar中的sun.applet.Main，并执行其main方法。
定义类加载器，但不委派
如何不委派呢？覆写ClassLoader#loadClass()：
当然，还要覆写ClassLoader#findClass()以支持自定义的类加载方式。
public class UnDelegationClassLoader extends ClassLoader {
private String classpath;
public UnDelegationClassLoader(String classpath) {
super(null);
this.classpath = classpath;
}
@Override
public Class<?> loadClass(String name) throws ClassNotFoundException {
Class<?> clz = findLoadedClass(name);
if (clz != null) {
return clz;
}
// jdk 目前对"java."开头的包增加了权限保护，这些包我们仍然交给 jdk 加载
if (name.startsWith("java.")) {
return ClassLoader.getSystemClassLoader().loadClass(name);
}
return findClass(name);
}
@Override
protected Class<?> findClass(String name) throws ClassNotFoundException {
InputStream is = null;
try {
String classFilePath = this.classpath + name.replace(".", "/") + ".class";
is = new FileInputStream(classFilePath);
byte[] buf = new byte[is.available()];
is.read(buf);
return defineClass(name, buf, 0, buf.length);
} catch (IOException e) {
throw new ClassNotFoundException(name);
} finally {
if (is != null) {
try {
is.close();
} catch (IOException e) {
throw new IOError(e);
}
}
}
}
public static void main(String[] args)
throws ClassNotFoundException, IllegalAccessException, InstantiationException,
MalformedURLException {
sun.applet.Main main1 = new sun.applet.Main();
UnDelegationClassLoader cl = new UnDelegationClassLoader("java-study/target/classes/");
String name = "sun.applet.Main";
Class<?> clz = cl.loadClass(name);
Object main2 = clz.newInstance();
System.out.println("main1 class: " + main1.getClass());
System.out.println("main2 class: " + main2.getClass());
System.out.println("main1 classloader: " + main1.getClass().getClassLoader());
System.out.println("main2 classloader: " + main2.getClass().getClassLoader());
}
}注意16-19行。由于jdk对"java."开头的包增加了权限保护，用户无法使用示例中的ClassLoader#defineClass()方法；而所有类都是java.lang.Object类的子类，sout输出时也要使用java.lang.System类等，所以我们又必须加载java.lang包下的类。因此，我们仍然将这些包委托给jdk加载。
同时，这也解释了，为什么不能将常用的java.lang包下的类作为同名类测试对象。
示例先加载jdk中的sun.applet.Main类，实例化main1，再使用不进行委派的自定义类加载器加载自定义的sun.applet.Main类，实例化main2。如果实例main2创建成功，则输出“constructed”。之后，输出main1、main2的类名和类加载器。
测试输出结果：
constructed
main1 class: class sun.applet.Main
main2 class: class sun.applet.Main
main1 classloader: null
main2 classloader: com.msh.demo.classloading.loading.UnDelegationClassLoader@1d44bcfa首先，1行说明实例main2创建成功了。2-3行表示main1、main2的全限定名确实相同。4-5行表示二者的类加载器不同，main1的类使用启动类加载器，main2的类使用自定义的类加载器。
正确姿势
一个符合规范的类加载器，应当仅覆写ClassLoader#findClass()，以支持自定义的类加载方式。不建议覆写ClassLoader#loadClass()（以使用默认的类加载逻辑，即双亲委派模型）；如果需要覆写，则不应该破坏双亲委派模型：
public class DelegationClassLoader extends ClassLoader {
private String classpath;
public DelegationClassLoader(String classpath, ClassLoader parent) {
super(parent);
this.classpath = classpath;
}
@Override
protected Class<?> findClass(String name) throws ClassNotFoundException {
InputStream is = null;
try {
String classFilePath = this.classpath + name.replace(".", "/") + ".class";
is = new FileInputStream(classFilePath);
byte[] buf = new byte[is.available()];
is.read(buf);
return defineClass(name, buf, 0, buf.length);
} catch (IOException e) {
throw new ClassNotFoundException(name);
} finally {
if (is != null) {
try {
is.close();
} catch (IOException e) {
throw new IOError(e);
}
}
}
}
public static void main(String[] args)
throws ClassNotFoundException, IllegalAccessException, InstantiationException,
MalformedURLException {
sun.applet.Main main1 = new sun.applet.Main();
DelegationClassLoader cl = new DelegationClassLoader("java-study/target/classes/",
getSystemClassLoader());
String name = "sun.applet.Main";
Class<?> clz = cl.loadClass(name);
Object main2 = clz.newInstance();
System.out.println("main1 class: " + main1.getClass());
System.out.println("main2 class: " + main2.getClass());
System.out.println("main1 classloader: " + main1.getClass().getClassLoader());
System.out.println("main2 classloader: " + main2.getClass().getClassLoader());
ClassLoader itrCl = cl;
while (itrCl != null) {
System.out.println(itrCl);
itrCl = itrCl.getParent();
}
}
}因为在自定义类加载器上正确使用了双亲委派模型，上述代码运行后，不会出现相同全限定名的类被不同类加载器加载的问题，也就不会引起混乱了.
测试输出数据：
main1 class: class sun.applet.Main
main2 class: class sun.applet.Main
main1 classloader: null
main2 classloader: null
com.msh.demo.classloading.loading.DelegationClassLoader@1d44bcfa
sun.misc.Launcher$AppClassLoader@18b4aac2
sun.misc.Launcher$ExtClassLoader@266474c2在双亲委派模型下，运行时中只存在启动类加载器加载的sun.applet.Main类。
5-6行输出了类加载器在双亲委派模型中的位置：最下层是自定义类加载器，然后逐层向上是应用程序类加载器、扩展类加载器，最上层是启动类加载器（在扩展类加载器中记为null）。可与前面的结构图对照。
不过，实际情况中，覆写ClassLoader#loadClass()是非常常见的。JNDI、OSGi等为了实现各自的需求，也在一定程度上破坏了双亲委派模型。
双亲委派模型的作用以及如何打破双亲委派模型以及双亲委派模型破坏史？
双亲委派模型的作用
作用：保证JDK核心类的优先加载；
如何打破双亲委派模型？
自定义类加载器，重写loadClass方法；
使用线程上下文类加载器；
双亲委派模型破坏史
1.第一次破坏
由于双亲委派模型是在JDK1.2之后才被引入的，而类加载器和抽象类java.lang.ClassLoader则在JDK1.0时代就已经存在，面对已经存在的用户自定义类加载器的实现代码，Java设计者引入双亲委派模型时不得不做出一些妥协。在此之前，用户去继承java.lang.ClassLoader的唯一目的就是为了重写loadClass()方法，因为虚拟机在进行类加载的时候会调用加载器的私有方法loadClassInternal()，而这个方法唯一逻辑就是去调用自己的loadClass()。
2.第二次破坏
双亲委派模型的第二次“被破坏”是由这个模型自身的缺陷所导致的，双亲委派很好地解决了各个类加载器的基础类的同一问题（越基础的类由越上层的加载器进行加载），基础类之所以称为“基础”，是因为它们总是作为被用户代码调用的API，但世事往往没有绝对的完美。
如果基础类又要调用回用户的代码，那该么办？
一个典型的例子就是JNDI服务，JNDI现在已经是Java的标准服务，
它的代码由启动类加载器去加载（在JDK1.3时放进去的rt.jar），但JNDI的目的就是对资源进行集中管理和查找，它需要调用由独立厂商实现并部署在应用程序的ClassPath下的JNDI接口提供者的代码，但启动类加载器不可能“认识”这些代码。
为了解决这个问题，Java设计团队只好引入了一个不太优雅的设计：线程上下文类加载器(Thread Context ClassLoader)。这个类加载器可以通过java.lang.Thread类的setContextClassLoader()方法进行设置，如果创建线程时还未设置，他将会从父线程中继承一个，如果在应用程序的全局范围内都没有设置过的话，那这个类加载器默认就是应用程序类加载器。
有了线程上下文加载器，JNDI服务就可以使用它去加载所需要的SPI代码，也就是父类加载器请求子类加载器去完成类加载的动作，这种行为实际上就是打通了双亲委派模型层次结构来逆向使用类加载器，实际上已经违背了双亲委派模型的一般性原则，但这也是无可奈何的事情。Java中所有涉及SPI的加载动作基本上都采用这种方式，例如JNDI、JDBC、JCE、JAXB和JBI等。
3.第三次破坏
双亲委派模型的第三次“被破坏”是由于用户对程序动态性的追求导致的，这里所说的“动态性”指的是当前一些非常“热门”的名词：代码热替换、模块热部署等，简答的说就是机器不用重启，只要部署上就能用。
OSGi实现模块化热部署的关键则是它自定义的类加载器机制的实现。每一个程序模块(Bundle)都有一个自己的类加载器，当需要更换一个Bundle时，就把Bundle连同类加载器一起换掉以实现代码的热替换。在OSGi幻境下，类加载器不再是双亲委派模型中的树状结构，而是进一步发展为更加复杂的网状结构，当受到类加载请求时，OSGi将按照下面的顺序进行类搜索：
1）将java.＊开头的类委派给父类加载器加载。
2）否则，将委派列表名单内的类委派给父类加载器加载。
3）否则，将Import列表中的类委派给Export这个类的Bundle的类加载器加载。
4）否则，查找当前Bundle的ClassPath，使用自己的类加载器加载。
5）否则，查找类是否在自己的Fragment Bundle中，如果在，则委派给Fragment Bundle的类加载器加载。
6）否则，查找Dynamic Import列表的Bundle，委派给对应Bundle的类加载器加载。
7）否则，类加载器失败。