虚拟机之双亲委托模型

类加载器

虚拟机设计团队把类加载阶段中的“通过一个全限定性名获取二进制字节流”这个动作的实现放到 java 虚拟机外部去实现，以便让程序自己决定如何去获取所需要的类. 这个动作的代码模块称为“类加载器”。

任何一个类，都是由加载它的类加载器和这个类本身一同确立其在 java 虚拟机中的唯一性，每一个类加载器，都拥有一个独立的类名称空间.
换句话说，比较两个类是否相等，只有在这两个类在同一个类加载器加载的前提下才有意义.否则就是同一个类，但是用不同的类加载器加载，那么必然也是不相等的.

这里说的相等，包括代表类的 Class 对象的 equals() 方法、isAssignableFrom() 方法、isInstance() 方法的返回结果，也包括 instanceof 关键字做对象所属关系判定等情况.

双亲委派模型

从 java 虚拟机的角度上将，只存在两种加载器，一种是启动类加载器，这个类加载器由c++实现，还有就是其他的类加载器，这些类加载器由java语言实现，独立于虚拟机外部，并全部继承自抽象类 java.lang.ClassLoader.

启动类加载器：负责 java_hone/lib 目录中的，或者被 -Xbootclasspath 参数指定的路径
扩展类加载器：负责 java_home/lib/ext 目录中的，或者被 java.ext.dirs 系统变量所指定的(sun.misc.Launcher$ExtClassLoader实现).
应用程序类加载器：这个类加载器是 ClassLoader 中的 getSystemClassLoader() 方法的返回值，所以又称系统类加载器.(sun.misc.Launcher$App-ClassLoader)

双亲委托机制(使用组合关系来复用父加载器的代码)

双亲委派模型的工作过程：如果一个类加载器收到了一个类的加载请求，它首先不会自己去尝试加载这个类，而是把请求委托给父类加载器去完成，每个层次的加载器都是如此，因此所有的加载请求最终都会到启动类加载器那. 只有当父类加载器反馈自己无法完成这个加载请求时，子类加载器才会尝试自己去加载.

这样做的好处是保证核心类在虚拟机中只会出现一次，保证了虚拟机的安全.

双亲委托模型的实现：

protected Class<?> loadClass(String name, boolean resolve)
        throws ClassNotFoundException
    {
        synchronized (getClassLoadingLock(name)) {
            // First, check if the class has already been loaded
            Class<?> c = findLoadedClass(name);
            if (c == null) {
                long t0 = System.nanoTime();
                try {
                    if (parent != null) {
                        c = parent.loadClass(name, false);
                    } else {
                        c = findBootstrapClassOrNull(name);
                    }
                } catch (ClassNotFoundException e) {
                    // ClassNotFoundException thrown if class not found
                    // from the non-null parent class loader
                }

                if (c == null) {
                    // If still not found, then invoke findClass in order
                    // to find the class.
                    long t1 = System.nanoTime();
                    c = findClass(name);

                    // this is the defining class loader; record the stats
                    sun.misc.PerfCounter.getParentDelegationTime().addTime(t1 - t0);
                    sun.misc.PerfCounter.getFindClassTime().addElapsedTimeFrom(t1);
                    sun.misc.PerfCounter.getFindClasses().increment();
                }
            }
            if (resolve) {
                resolveClass(c);
            }
            return c;
        }
    }

我们可以看到，在 loadClass 中实现了双亲委托的核心代码，然后调用 findClass 方法. 所以，如果我们只是改变查找类的话，可以直接重写 findClass 方法.

破坏双亲委托模型

双亲委托模型并不是一个强制性约束模型，而是 java 设计者推荐的一种.

双亲委托模型第一次被破坏: JDK1.2发布之前，由于双亲委托模型是在 JDK1.2之后才被引入的，而 ClassLoader 在 JDK1.0 时已经存在，所以 java 设计者不得不做出一些妥协，添加了 protected 方法 findClass().

双亲委托模型第二次被破坏：是由模型自身缺陷导致的，比如说基础类要回调用户代码，该怎么办了？比如典型的例子JNDI服务，它的代码由启动类加载器加载，但是它要加载厂商放在 classpath 的实现，该怎么办了？为了解决这个问题，java 设计团队引入了一个不太优雅的设计：线程上下文类加载器(Thread Context ClassLoader). 这个类加载器可以通过 Thread 类的 setContextClassLoader() 方法进行设置，如果线程创建时还没有设置，它将从父线程中继承一个，如果在引用程序的全局都没有设置过，那这个类加载器默认就是应用程序类加载器.

第三次被破坏：由于用户对程序动态性的追求所导致.每个程序模块(OSGI 中称 Bundle)都有一个自己的类加载器，当需要更换一个 Bundle 时，就把 Bundle 连同类加载器一起换掉以实现代码的热替换.

可以参考：https://www.zhihu.com/question/49667892

在 OSGI 环境下，类加载器不再是双亲委托模型中的树状结构，而是更加复杂的网状结构，当收到类加载请求时，OSGI 将按照下面的顺序进行类搜索：

1.将以 java.* 开头的类委派给父类加载器加载
2.否则，将委派列表名单内的类委派给父类加载器加载
3.否则，将 Import 列表中的类委派给 Export 这个类的 Bundle 的类加载器加载
4.否则，查找当前 Bundle 的 ClassPath，使用自己的类加载器加载
5.否则，查找类是否在自己的 Fragment Bundle 中，如果在，则委派给 Fragment Bundle 的类加载器加载
6.否则，查找 Dynamic Import 列表的 Bundle，委派给对应的 Bundle 的类加载器加载
7.否则，查找失败