虚拟机类加载机制

1.概述

多个java文件经过编译打包生成可运行jar包，终由java命令运行某个主类的main函数启动程序，这里首先需要通过类加载器把主类加载到JVM。 主类在运行过程中如果使用到其它类，会逐步加载这些类。 注意，jar包里的类不是一次性全部加载的，是使用到时才加载。

定义：虚拟机把描述类的数据从Class文件加载到内存，并对数据进行校验、转换解析和初始化，最终形成可以被虚拟机直接使用的Java类型，这就是虚拟机的类加载机制。

2.类加载的过程

类加载到使用整个过程有如下几步： 加载 >> 验证 >> 准备 >> 解析 >> 初始化 >> 使用 >> 卸载

2.1加载

在加载阶段虚拟机需要完成以下三件事情(虚拟机规范)：

1. 通过一个类的全限定名来获取定义此类的二进制字节流
2. 将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构
3. 在内存中生成一个代表这个类的java.lang.Class对象，作为方法区这个类的各种数据的访问入口

虚拟机的这三点规范很抽象，因此虚拟机的实现和具体应用有很大的灵活度，例如第一步，没有指明要从哪里获取，怎么获取。比如：

• 常见的从zip包中获取，也有JAR、WAR等格式
• 从网络中获取，这种场景最典型的应用就是Applet
• 运行时计算生成，例如动态代理技术，反射生成二进制字节流
• 由其他文件生成，例如由JSP文件生成对应的class类

2.2 验证

校验字节码文件的正确性，确保class文件的字节流中包含的信息符合当前虚拟机的要求，并且不会危害虚拟机自身的安全。
大致会完成下面四个阶段的检验动作：

• 文件格式验证
• 元数据验证
• 字节码验证
• 符号引用验证

对于虚拟机的类加载机制来说，验证阶段是一个非常重要，但是不是一定必要的阶段。如果所运行的全部代码，都已经反复使用和验证过，那么在实施阶段可以考虑使用-Xverify:none参数来关闭大部分的类验证措施，以缩短虚拟机类加载的时间。

2.3准备

给类的静态变量赋予分配内存，并赋予默认值，这些变量所使用的内存都在方法区中进行分配。
这里所说的默认值是数据类型的默认值，而不是程序赋予的初始值。
例如:
public static int value = 123;
变量value在准备阶段过后的初始值是int的默认值0，而不是123，
把value赋值为123的动作将在初始化阶段,构造java对象的时候才会执行。
特殊情况
如果类字段的字段属性分配在常量池中，那么在准备阶段变量value就会被初始化为常量
例如:
public static final int value = 123;
在准备阶段虚拟机就会把value设置为常量123

2.4解析

将常量池内的符号引用替换为直接引用。
该阶段会把一些静态方法(符号引用，比如 main()方法)替换为指向数据所存内存的指针或句柄等(直接引用)，这是所谓的静态链 接过程(类加载期间完成)，动态链接是在程序运行期间完成的将符号引用替换为直接引用

2.5初始化

对类的静态变量初始化为指定的值，执行静态代码块。

3.类加载器和双亲委派机制

上面的类加载过程主要是通过类加载器来实现的，Java里有如下几种类加载器:

• 启动类加载器：负责加载支撑JVM运行的位于JRE的lib目录下的核心类库，比如 rt.jar、charsets.jar等
• 扩展类加载器：负责加载支撑JVM运行的位于JRE的lib目录下的ext扩展目录中 的JAR类包
• 应用程序类加载器：负责加载ClassPath路径下的类包，主要就是加载你自己写的那些类
• 自定义加载器：负责加载用户自定义路径下的类包

双亲委派机制
JVM类加载器是有亲子层级结构的，如上图
双亲委派模型的工作过程是：如果一个类加载器收到了类加载的请求，它首先不会自己去尝试加载这个类，而是把这个请求委派给父类加载器去完成，每一个层次的类加载器都是如此，因此所有的加载请求最终都应该从顶层的启动类加载器开始，只有当父类加载器反馈自己无法完成这个加载请求时，子加载器才会尝试自己去加载。

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

为什么要设计双亲委派机制：

• 沙箱安全机制：自定义的java.lang.String.class类不会被加载，这样便可以防止 核心API库被随意篡改
• 避免同一个类被不同的加载器加载，无法保证被加载类的唯一性，造成混乱

自定义一个类加载器示例：

自定义类加载器只需要继承 java.lang.ClassLoader 类，该类有两个核心方法，一个是 loadClass(String, boolean)，实现了双亲委派机制；还有一个方法是findClass，默认实现是抛出异常，所以我们自定义类加载器主要是重写 findClass方法。

public class MyClassLoaderTest {
    static class MyClassLoader extends ClassLoader{
        private String classPath;

        public MyClassLoader(String classPath) {
            this.classPath = classPath;
        }

        private byte[] loadByte(String name) throws IOException {
            name = name.replaceAll("\\.", "/");
            FileInputStream fis = new FileInputStream(classPath + "/" + name + ".class");
            int length = fis.available();
            byte[] data = new byte[length];
            fis.read(data);
            fis.close();
            return data;
        }

        @Override
        protected Class<?> findClass(String name) throws ClassNotFoundException {
            try {
                byte[] data = loadByte(name);
                return defineClass(name, data, 0, data.length);
            } catch (IOException e) {
                e.printStackTrace();
                throw new  ClassNotFoundException();
            }
        }
    }

    public static void main(String[] args) throws Exception {
        MyClassLoader myClassLoader = new MyClassLoader("D:/test");
        Class clazz = myClassLoader.loadClass("com.example.DemoLog");
        Object object = clazz.newInstance();
        Method method = clazz.getDeclaredMethod("sout", null);
        method.invoke(object, null);
        System.out.println(clazz.getClassLoader().getClass().getName());
    }
}

4.破坏双亲委派模型

双亲委派模型并不是一个强制性的约束模型，而是Java设计者推荐给开发者的类加载器实现方式。开发者可以通过重写loadClass方法打破双亲委派模型。

4.1Tomcat设计

以Tomcat类加载为例，Tomcat 如果使用默认的双亲委派类加载机制行不行？ 我们思考一下：Tomcat是个web容器， 那么它要解决什么问题：

• 1. 一个web容器可能需要部署两个应用程序，不同的应用程序可能会依赖同一个第三方类 库的不同版本，不能要求同一个类库在同一个服务器只有一份，因此要保证每个应用程序的 类库都是独立的，保证相互隔离。
• 2. 部署在同一个web容器中相同的类库相同的版本可以共享。否则，如果服务器有10个应 用程序，那么要有10份相同的类库加载进虚拟机。
• 3. web容器也有自己依赖的类库，不能与应用程序的类库混淆。基于安全考虑，应该让容 器的类库和程序的类库隔离开来。
• 4. web容器要支持jsp的修改，我们知道，jsp 文件终也是要编译成class文件才能在虚拟 机中运行，但程序运行后修改jsp已经是司空见惯的事情， web容器需要支持 jsp 修改后不 用重启。

再看看我们的问题：Tomcat 如果使用默认的双亲委派类加载机制行不行？ 答案是不行的。为什么？

• 第一个问题，如果使用默认的类加载器机制，那么是无法加载两个相同类库的不同版本的， 默认的类加器是不管你是什么版本的，只在乎你的全限定类名，并且只有一份。
• 第二个问 题，默认的类加载器是能够实现的，因为他的职责就是保证唯一性。
• 第三个问题和第一个问题一样。
• 我们再看第四个问题，我们想我们要怎么实现jsp文件的热加载，jsp 文件其实也就是class 文件，那么如果修改了，但类名还是一样，类加载器会直接取方法区中已经存在的，修改后 的jsp是不会重新加载的。那么怎么办呢？我们可以直接卸载掉这jsp文件的类加载器，所以 你应该想到了，每个jsp文件对应一个唯一的类加载器，当一个jsp文件修改了，就直接卸载 这个jsp类加载器。重新创建类加载器，重新加载jsp文件。

4.2Tomcat自定义加载器解

tomcat的几个主要类加载器：

• commonLoader：Tomcat基本的类加载器，加载路径中的class可以被 Tomcat容器本身以及各个Webapp访问；
• catalinaLoader：Tomcat容器私有的类加载器，加载路径中的class对于 Webapp不可见；
• sharedLoader：各个Webapp共享的类加载器，加载路径中的class对于所有 Webapp可见，但是对于Tomcat容器不可见；
• WebappClassLoader：各个Webapp私有的类加载器，加载路径中的class只对 当前Webapp可见；

从图中的委派关系中可以看出： CommonClassLoader能加载的类都可以被CatalinaClassLoader和SharedClassLoader使 用，从而实现了公有类库的共用，而CatalinaClassLoader和SharedClassLoader自己能加 载的类则与对方相互隔离。 WebAppClassLoader可以使用SharedClassLoader加载到的类，但各个 WebAppClassLoader实例之间相互隔离。 而JasperLoader的加载范围仅仅是这个JSP文件所编译出来的那一个.Class文件，它出现的 目的就是为了被丢弃：当Web容器检测到JSP文件被修改时，会替换掉目前的 JasperLoader的实例，并通过再建立一个新的Jsp类加载器来实现JSP文件的热加载功能。

tomcat 这种类加载机制违背了java 推荐的双亲委派模型了吗？答案是：违背了。 我们前面说过，双亲委派机制要求除了顶层的启动类加载器之外，其余的类加载器都应当由 自己的父类加载器加载。 很显然，tomcat 不是这样实现，tomcat 为了实现隔离性，没有遵守这个约定，每个 webappClassLoader加载自己的目录下的class文件，不会传递给父类加载器，打破了双 亲委派机制。