双亲委派机制

目录

0. 说在前面

 1. 工作流程

 工作原理：

 3. 工作特点：

4. 破坏双亲委派机制：

---

0. 说在前面

我们在IDE中编写的Java源代码被编译成.Class字节码文件，然后通过类加载器将这些Class文件加载到JVM中去执行。那么我们是如何选择类加载器呢？一个.class文件又是怎么被加载到JVM中呢？

三种类加载器：

• Bootstrap classLoader:主要负责加载核心的类库(java.lang.*等)，构造ExtClassLoader和APPClassLoader。

• ExtClassLoader：主要负责加载jre/lib/ext目录下的一些扩展的jar。

• AppClassLoader：主要负责加载应用程序的主函数类

 1. 工作流程

Java虚拟机对class文件采用的是按需加载的方式，也就是说当需要使用该类时才会将它的class文件加载到内存生成class对象。而且加载某个类的class文件时，Java虚拟机采用的是双亲委派模式，即把请求交由父类处理，它是一种任务委派模式。

我们首先查看一下双亲委派机制的源码：

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);
            //c==null表示该类没有被加载
            if (c == null) {
                long t0 = System.nanoTime();
                try {
                	//如果有父类，则优先用父类进行加载。否则说明已经到了最顶层的bootstrapClassLoader，到此则开始加载
                    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;
        }
    }

这段代码就能很好的解释双亲委派机制，那么通过下面这张流程图更加直观的展示一下它的工作过程。

 工作原理：

如果一个类加载器收到了类加载请求，他自己并不会先着急加载，先检查是否加载过，如果加载过就不会重复加载。没有的话就将这个加载请求委托给自己的父类加载器去执行。

如果父类加载器还存在其父类加载器，则进一步向上委托，一次递归，直到达到顶层的启动类加载器。

如果父类加载器可以完成该类加载的任务，就成功返回。只有当父类无法完成加载时，子类才会尝试去加载。如果到最低层都无法加载，就会抛出ClassNotFoundException。

 

 3. 工作特点：

避免类的重复加载

保护程序的安全，防止核心API被随意篡改。

检查类是否加载的委托过程是单向的，这个方式虽然从结构上说比较清晰，使各个ClassLoader的职责非常明确，但是同时会带来一个问题，即顶层的ClassLoader无法访问底层的ClassLoader所加载的类。按照这种模式，应用类访问系统类自然是没有问题，但是系统类访问应用类就会出现问题。

4. 破坏双亲委派机制：

在Java中大多数类加载器都是遵循这个模型的，但是也存在例外的情况。直到Java模块化出现为之，双亲委派模型出现了三次较大规模的被破坏。

第一次破坏双亲委派机制——JDK1.2面世以前

由于双亲委派模型在JDK 1.2之后才被引入，但是类加载器的概念和抽象类java.lang.ClassLoader则在Java的第一个版本中就已经存在，面对已经存在的用户自定义类加载器的代码，Java设计者们引入双亲委派模型时不得不做出一些妥协。

为了兼容这些已有的代码，无法再以技术手段避免loadClass()这个方法被子类覆盖的可能性，只能在以后的java.lang.ClassLoader中添加一个新的protected方法findClass()，引导用户区重写这个方法，而不是在loadClass()（双亲委派的具体逻辑就实现在这里面）上编写代码。

按照loadClass()方法的逻辑，如果父类加载失败，会自动调用自己的findClass()方法来完成加载，这样既不影响用户按照自己的意愿去加载类，又可以保证新写出来的类加载器是符合双亲委派规则的。

第二次破坏双亲委派机制——线程上下文类加载器

这一次被破坏其实是由于模型本身的缺陷导致的，双亲委派型机制保证了越是基础的类由越上层的加载器加载，基础类之所以称为基础是因为他总是被用户代码继承和调用。那么如果有基础类型想要回调用户代码会怎么办？

Java团队只好引入一个不太优雅的设计：线程上下文类加载器。默认上下文加载器就是应用类加载器，这样以上下文加载器为中介，使得启动类加载器中的代码也可以访问应用类加载器中的类。

可参考阅读：连接

第三次破坏双亲委派机制——代码热替换和模块热部署

 IBM公司主导的JSR-291(即OSGiR4.2)实现模块化热部署的关键是它自定义的类加载器机制的实现，每一个程序模块(osGi中称为Bundle)都有一个自己的类加载器，当需要更换一个Bundle时，就把Bund1e连同类加载器一起换掉以实现代码的热替换。在oSGi环境下，类加载器不再双亲委派模型推荐的树状结构，而是进一步发展为更加复杂的网状结构。