导读：

类加载器是怎么被创建出来的？
什么是双亲委派机制？为什么要有这种机制？
Class实例和类加载器究竟是在Java Heap中，还是在方法区中？

类加载器： 可以实现通过一个类的全限定名称来获取描述此类的二进制字节流。实现这个动作的代码模块成为”类加载器“。

通过自定义类加载器可以实现各种有趣而强大的功能更：OSGi，热部署，代码加密等。

1、类加载器的加载流程

如上图为类加载器的加载流程。

这里简单描述下：

1.1、启动类加载器

**启动类加载器：**系统启动的时候，首先会通过由C++实现的启动类加载器，加载<JAVA_HOME>/lib目录下面的jar包，或者被-Xbootclasspath参数指定的路径并且被虚拟机识别的文件名的jar包。把相关Class加载到方法区中。

这一步会加载关键的一个类：sun.misc.Launcher。这个类包含了两个静态内部类：

ExtClassLoader：扩展类加载器内部类，下面会讲；
AppClassLoader：应用程序类加载器内部类，下面会讲

可以反编译rt.jar文件查看详细代码：

在加载到Launcher类完成后，会对该类进行初始化，初始化的过程中，会创建 ExtClassLoader 和 AppClassLoader，源码如下：

public Launcher() {
    ExtClassLoader extClassLoader;
    try {
      extClassLoader = ExtClassLoader.getExtClassLoader();
    } catch (IOException iOException) {
      throw new InternalError("Could not create extension class loader", iOException);
    }
    try {
      this.loader = AppClassLoader.getAppClassLoader(extClassLoader);
    } catch (IOException iOException) {
      throw new InternalError("Could not create application class loader", iOException);
    }
    Thread.currentThread().setContextClassLoader(this.loader);
    ...

由于启动类加载器是由C++实现的，所以在Java代码里面是访问不到启动类加载器的，如果尝试通过String.class.getClassLoader()获取启动类的引用，会返回null；

问题：

启动类加载器，扩展类加载器和应用类加载器都是又谁加载的？

启动类加载器是JVM的内部实现，在JVM申请好内存之后，由JVM创建这个启动类加载器

扩展类加载器和应用程序类加载器是由启动类加载器加载进来的；

说说以下代码输出什么：
 public static void main(String[] args) {
     System.out.println("加载当前类的加载器:" + TestClassLoader.class.getClassLoader());
        System.out.println("加载应用程序类加载器的加载器"
                         + TestClassLoader.class.getClassLoader().getClass().getClassLoader());
        System.out.println("String类的启动类加载器" + String.class.getClassLoader());
   }

1.2、扩展类加载器

如上图，扩展类加载器负责加载<JAVA_HOME>/lib/ext目录下或者被java.ext.dirs系统变量指定的路径中的类。

1.3、应用程序类加载器

引用程序类加载器加载用户类路径下制定的类库，如果应用程序没有自定义过自己的类加载器，此类加载器就是默认的类加载器。

引用程序类加载器也叫系统类加载器，可以通过getSystemClassLoader方法得到应用程序类加载器。

注意，如上图通过以上三个类加载器加载类到方法区之后，方法区中分别对应有各自的类信息存储区。不同类加载器加载的同一个类文件不相等。

2、类加载器的双亲委派机制

2.1、双亲委派机制原理

双亲委派模型在JDK1.2之后被引入，并广泛使用，这不是一个强制性的约束模型，二货思Java设计者推荐给开发者的一种类加载器实现方式。我们也可以覆盖对应的方式，实现自己的加载模型。

类加载器的双亲委派机制如下：

也就是说：

一个类加载器收到了类加载请求，不会自己立刻尝试加载类，而是把请求委托给父加载器去完成，每一层都是如此，所有的家在请求最终都传递到最顶层的类加载器进行处理；
如果父加载器不存在了，那么尝试判断有没有被启动类加载器加载；
如果的确没有被夹在，则再自己尝试加载。

问题：

为什么要有这么复杂的双亲委派机制？

如果没有这种机制，我们就可以篡改启动类加载器中需要的类了，如，修自己编写一个java.lang.Object用自己的类加载器进行加载，系统中就会存在多个Object类，这样Java类型体系最基本的行为也就无法保证了。

2.2、双亲委派机制处理流程

JDK中默认的双亲委派处理流程是怎么的呢？接下来我们看看代码，以下是java.lang.ClassLoader.loadClass()方法的实现：

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;
        }
    }

转成流程图，即是：

如山图所以，总是先回尝试让父类加载器先加载，其次判断启动类加载器是否已经加载了，最后才尝试从当前类加载器加载。转换为更清晰的模型如下：

双亲委派模型具有以下特点：

可见性原则：
- 应用类加载器是可以读取到由扩展类加载器和启动类加载器加载进来的Class的；
- 扩展类加载器是可以读取到由启动类加载器加载进来的Class的；
唯一性：
- 类是唯一的，没有重复的类；

2.3、类加载器和Class实例的题外话

启动类加载器，扩展类加载器，应用程序类加载器，他们分别管理者各自方法区里的一个区块。

根据上一篇文章我们知道，方法区里面主要存储的是类的运行时数据结构，这个类的在方法区中的各种数据结构信息通过类的Class实例进行访问。

如下图：

方法区里面存储着加载进来的类信息，方法区同时雇佣了两类工种帮忙干活：

**类加载器：**负责管理各个存储区的类信息，如加载和卸载类信息；
**Class实例：**负责对接外部需求，如果外部有人想查看里面的类信息，则需要通过Class实例来获取；

另外，方法区里面，启动类加载器类信息对扩展两类加载器类信息可见，而前面两者的类信息又对应用程序类加载器类信息可见。

3、其他非双亲委派模型的案例

3.1、JDK 1.0遗留问题

在JDK1.0已经存在了ClassLoader类，但是当时还没有双亲委派机制，用户为了自定义类加载器，需要重新loadClass()方法，而我们知道，在JDK1.2以后，loadClass里面就是双亲委派机制的实现代码，此时，要实现自定义类加载器，需要重新findClass()类即可。

如果重新了loadClass()方法，也就意味着不再遵循双亲委派模型了。

3.2、线程上下文类加载器

为什么需要这个东西呢，我们还是从一个案例来说起。

Tomcat中的类加载器

我们知道Tomcat目录结构中有以下目录：

/common/： 该目录下的类库可被Tomcat和所有的WebApp共同使用；
/server/： 该目录下的类库可被Tomcat使用，但对所有的WebApp不可见；
/shared/： 该目录下的类库可被所有的WebApp共同使用，但对Tomcat自己不可见；

另外Web应用程序还有自身的类库，放在/WebApp/WEB-INF目录中：这里面的类库仅仅可以被此Web应用程序使用，对Tomcat和其他Web应用程序都不可见。为了实现以上各个目录的类库可见性效果，Tomat提供了如下的自定义类加载器：

现在如下场景：

我们发现Tomcat下面有若干个webapp，每个webapp都用到了spring，于是我们把spring的jar包放到了shared目录中。

于是问题出现了：由于spring的jar包是由Shared类加载器加载的，假设我们要使用SpringContext的getBean方法，获取webapp中的Bean，如果是按照双亲委派模型，就会有问题了，因为webapp中的Java类是对SharedClassLoader不可见的：

Spring中的线程上下文类加载器

为了解决这个问题，Spring使用了线程上下文类加载器，即从ThreadLocal中获取到当前线程的上下文类加载器，来加载所有的类库和类。

关于Spring初始化源码相关解读，参考这篇文章：Spring IoC原理剖析。

Spring中的bean类加载器

ApplicationContext中有一个beanClassLoader字段，这个是bean的类加载器，在prepareBeanFactory()方法中做了初始化：

beanFactory.setBeanClassLoader(getClassLoader());

getClassLoader方法如下：

@Override
    @Nullable
    public ClassLoader getClassLoader() {
        return (this.classLoader != null ? this.classLoader : ClassUtils.getDefaultClassLoader());
    }

ClassUtils.getDefaultClassLoader()方法：

@Nullable
    public static ClassLoader getDefaultClassLoader() {
        ClassLoader cl = null;
        try {
            cl = Thread.currentThread().getContextClassLoader();
        }
        catch (Throwable ex) {
            // Cannot access thread context ClassLoader - falling back...
        }
        if (cl == null) {
            // No thread context class loader -> use class loader of this class.
            cl = ClassUtils.class.getClassLoader();
            if (cl == null) {
                // getClassLoader() returning null indicates the bootstrap ClassLoader
                try {
                    cl = ClassLoader.getSystemClassLoader();
                }
                catch (Throwable ex) {
                    // Cannot access system ClassLoader - oh well, maybe the caller can live with null...
                }
            }
        }
        return cl;
    }

可以发现，这里最终取了当前线程上下文中的ClassLoader。

加载Bean

我们来看看Spring加载Class的代码。这里我们直接找到实例化Singletons的方法跟进去找需要关注的代码：

我们发现在加载Bean Class的时候调用了这个方法：

AbstractBeanFactory：

ClassLoader beanClassLoader = getBeanClassLoader();

也就是用到了ApplicationContext中的beanClassLoader，线程上下文类加载器来加载Bean Class实例。

总结

Spring作为一个第三方类库，可能被任何的ClassLoader加载，所以最灵活的方式是直接使用上下文类加载器。

3.3、模块热部署

主要是类似OSGi这类的模块化热部署技术。在OSGi中不再是双亲委派模型中的树状结构，而是更复杂的网状结构。

References

Where are static methods and static variables stored in Java?

ClassLoader in Java

真正理解线程上下文类加载器（多案例分析）

《深入理解Java虚拟机-JVM高级特性与最佳实践》

Chapter 5. Loading, Linking, and Initializing

来源：掘金

一篇图文彻底弄懂类加载器与双亲委派机制

导读：