深入理解java之类加载器

一、类与类加载器

类加载器：实现加载阶段的第一步，通过一个类的全限定名来将这个类的二进制字节流加载进jvm。

类与类加载器：任意一个类唯一性都是由它本身和加载它的类加载器确定，两个类是否相等在它们是由同一个类加载器加载的前提下。

jvm虚拟机中包括两种类加载器：一种是启动类加载器（Bootstrap ClassLoader），它是使用C++实现；另一种是其他所有用java实现的类加载器。

从java程序角度：

1）启动类加载器：负责加载<JAVA_HOME>lib目录下或者被-Xbootclasspath参数所指定的路径中的类，此外要求文件名被虚拟机识别，如果不被jvm识别也无法被加载。

2）扩展类加载器：负责加载<JAVA_HOME>libexit目录下或者被java.exit.dirs系统变量所指定的路径中的所有类库。

3）应用程序类加载器（系统类加载器）：它是Classloader中的getSystemClassloader()方法的返回值。负责加载用户类路径上所指定的类库，如果应用程序中没有自定义类加载器，这个就为程序中默认的类加载器。

免费在线视频教学：java视频教程

二、双亲委派模型

除了顶层的启动类加载器，其余所有类加载器都有自己的父类加载器。父子关系不以继承实现，而是以组合关系来复用父类加载器。

工作过程： 类加载器接到类加载请求–>将请求委派给父类加载器（直到最顶层启动类加载器）–>父类尝试加载，加载失败反馈给子类加载器–>子类加载器尝试加载

双亲委派模型的好处：保证java底层API的稳定，避免加载和基本类重名（Object）的自定义类导致出现多个不同的重名的类（Object），从而造成java基础行为的混乱。

双亲委派模型源码：

方法加同步锁保证线程安全，首先检查该类是否被加载过，如果没有加载则调用父类加载器的loadClass()方法，若父类加载器为空说明是启动类加载器，则调用启动类加载器。

如果父类加载失败会抛出ClassNotFoundException，在调用自己的findClass()方法进行加载。

protected Class<?> loadClass(String name, boolean resolve)
    throws ClassNotFoundException
{
    //同步锁
    synchronized (getClassLoadingLock(name)) {
        // 首先检车这个类是不是已被加载
        Class<?> c = findLoadedClass(name);
        if (c == null) {
            long t0 = System.nanoTime();
            try {
                if (parent != null) {
                    //如果父类不为空则调用父类加载器的loadClass方法
                    c = parent.loadClass(name, false);
                } else {
                    //没有父类则默认调用启动类加载器加载
                    c = findBootstrapClassOrNull(name);
                }
            } catch (ClassNotFoundException e) {
                //如果父类加载器找不到这个类则抛出ClassNotFoundException
            }


            if (c == null) {
                // 父类加载器失败时调用自身的findClass方法加载
                long t1 = System.nanoTime();
                c = findClass(name);


                //记录
                sun.misc.PerfCounter.getParentDelegationTime().addTime(t1 - t0);
                sun.misc.PerfCounter.getFindClassTime().addElapsedTimeFrom(t1);
                sun.misc.PerfCounter.getFindClasses().increment();
            }
        }
        if (resolve) {
            resolveClass(c);
        }
        return c;
    }
}

三、破坏双亲委派模型

1.第一次破坏

双亲委派模型出现在JDK1.2之后，而类加载器和抽象类java.lang.ClassLoader已经存在。

因此为了向前兼容，JDK1.2之后在ClassLoader中添加了一个新的protected方法findClass。用户把自己的类加载逻辑写在findClass方法中，而不是重写loadClass方法，从而保证自定义的类加载符合双亲委派模型。

2.第二次破坏

模型自身有缺陷。双亲委派可以确保各个类加载器的基础类的统一，这是在用户代码调用基础类的情况下，如果出现基础类回调用户代码那就不适用了。比如涉及到SPI的场景去加载所需要的SPI代码。

SPI机制的介绍参考其他文章。

为了解决这个问题，引入了线程上下文加载器（Thread Context ClassLoader），这个类加载器就可以通过java.lang.Thread类中的setContextClassLoader()方法进行设置，如果创建线程时未设置将会从父线程中继承一个，如果全局都没有则默认就是应用程序类加载器，利用这个加载器可以完成父类加载器请求子类加载器加载的动作。

3.第三次破坏

由于对程序动态性追求导致，如热部署，热替换等。

比如模块化标准OSGi R4.2中将双亲委派的树形结构变成了更复杂的网状结构。

java文章教程推荐：java入门教程