Mar 19, 2021, 5:58:25 PM

后端

类加载机制深度剖析

1.类加载过程

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

类加载到使用整个过程有如下几步：

加载$\Rightarrow$验证$\Rightarrow$准备$\Rightarrow$解析$\Rightarrow$初始化$\Rightarrow$使用$\Rightarrow$卸载

这里对每一个步骤进行说明

加载：在硬盘上查找并通过IO读入字节码文件，使用到类的时候才会加载，例如调用类的main()方法，新建对象等。
验证：校验字节码文件的正确性。字节码文件的头几位会判断Java版本，当java8生成的字节码用java6启动的时候可能会导致报错。
准备：将类的静态变量分配内存，赋予默认值
解析：将符号引用替换为直接引用，该阶段会把一些静态方法（符号引用，比如main()方法替换为指向数据所存内存的指针或句柄等(直接引用)），这就是所谓的静态链接过程（类加载期间完成），动态链接是程序运行期间完成的，将符号引用替换为直接引用
初始化：对类的静态变量赋予指定值，执行静态代码块

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

上面类的加载过程主要是通过类加载器来实现的，在类加载的第一阶段“加载”过程中，需要通过一个类的全限定名来获取定义此类的二进制字节流，完成这个动作的代码块就是类加载器。这一动作是放在Java虚拟机外部去实现的，以便让应用程序自己决定如何获取所需的类。

所以你可以从ZIP包中读取，从网络中获取，运行时计算生成（动态代理），从其他文件生成（.jsp本质是class）

Java里有如下几种类加载器

启动类加载器：负责将 Java_Home/lib下面的类库加载到内存中（比如rt.jar）。由于引导类加载器涉及到虚拟机本地实现细节，开发者无法直接获取到启动类加载器的引用，所以不允许直接通过引用进行操作。
扩展类加载器：是由 Sun 的 ExtClassLoader（sun.misc.Launcher$ExtClassLoader）实现的。它负责将Java_Home /lib/ext或者由系统变量 java.ext.dir指定位置中的类库加载到内存中。开发者可以直接使用标准扩展类加载器。
应用程序类加载器：负责加载classpath路径下的类包。主要就是加载你自己写的类
自定义加载器：负责加载用户自定义路径下的类包

启动类加载器属于虚拟机的一部分，它是用C++写的，看不到源码，所以如果试图通过

System.out.println(String.class.getClassLoader());

打印的是null值

2.1 自定义一个类加载示例

自定义类加载器只需要继承java.lang.ClasslLoader类，该类有两个核心方法，一个是loadClass(String,boolean)，实现了双亲委派机制，大体逻辑是

首先，检查一下指定名称的类是否已经加载过，如果加载过，就不需要再加载，直接返回
如果此类没有加载过，那么判断是否有父类加载器。如果有父类加载器，便通过父类加载器加载（即调用parent.loadClass(name,false);）,或者是调用bootstrap类加载器来加载
如果父加载器及bootstrap类加载器都没有找到指定类，那么调用当前类加载器的findClass方法来完成加载。

还有一个方法是findClass，默认实现是抛出异常，所以我们自定义类加载器主要是重写findClass方法

自定义类加载器示例：

自定义类加载器只需要继承 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 Exception {
            name = name.replaceAll("\\.", "/");
            FileInputStream fis = new FileInputStream(classPath + "/" + name
                    + ".class");
            int len = fis.available();
            byte[] data = new byte[len];
            fis.read(data);
            fis.close();
            return data;
        }

        protected Class<?> findClass(String name) throws ClassNotFoundException {
            try {
                byte[] data = loadByte(name);
                //defineClass将一个字节数组转为Class对象，这个字节数组是class文件读取后最终的字节数组。
                return defineClass(name, data, 0, data.length);
            } catch (Exception e) {
                e.printStackTrace();
                throw new ClassNotFoundException();
            }
        }

    }

    public static void main(String args[]) throws Exception {
        //初始化自定义类加载器，会先初始化父类ClassLoader，其中会把自定义类加载器的父加载器设置为应用程序类加载器AppClassLoader
        MyClassLoader classLoader = new MyClassLoader("D:/test");
        //D盘创建 test/com/tuling/jvm 几级目录，将User类的复制类User1.class丢入该目录
        Class clazz = classLoader.loadClass("com.tuling.jvm.User1");
        Object obj = clazz.newInstance();
        Method method = clazz.getDeclaredMethod("sout", null);
        method.invoke(obj, null);
        System.out.println(clazz.getClassLoader().getClass().getName());
    }
}

运行结果：
=======自己的加载器加载类调用方法=======
com.tuling.jvm.MyClassLoaderTest$MyClassLoader

2.2 双亲委派机制

有一个描述类加载器加载类过程的术语：双亲委派模型。然而这是一个很有误导性的术语，它应该叫做单亲委派模型（Parent-Delegation Model）。但是没有办法，大家都已经这样叫了。所谓双亲委派，这个亲就是指ClassLoader里的全局变量parent，也就是父加载器。

双亲委派的具体过程如下：

当一个类加载器接收到类加载任务时，先查缓存中有没有，如果没有，将任务委托给它的父类加载器去执行
父类加载器也做统一的过程，一层一层网上委托，直到最顶层的启动类加载器为止。
如果启动类加载器没有找到所需加载的类，便将此加载任务退回给下一级类加载器去执行，而下一级的类加载器也做同样的事情
如果最底层类加载器仍然没有找到所需要的class文件，则抛出异常

所以是一条线传上再传下，并没有什么“双亲”。整个过程的Java也没有什么神秘的：

public abstract class ClassLoader {
    // name: Class文件的绝对路径
    // resolve: 找到后是否立即解析（什么是解析？）
    protected Class<?> loadClass(String name, boolean resolve) throws ClassNotFoundException {
        synchronized (lock) {
            // 尝试从缓存获取，这也是为什么修改了Class后需重启JVM才能生效
            Class<?> target = findLoadedClass(name); // native方法
            if (target == null) {
                try {
                    if (parent != null) {
                        // 委托给父加载器， 只查找不解析
                        target = parent.loadClass(name, false);
                    } else {
                        // 父加载器为null，则委托给启动类加载器BootstrapClassloader
                        target = findBootstrapClassOrNull(name); // native方法
                    }
                } catch (ClassNotFoundException e) {...}
			
			
                if (target == null) {
                    // 父加载器没有找到，才调用自己的findClass()方法
                    target = findClass(name);
                }
            }
            if (resolve) {
                resolveClass(target); // native方法
            }
            return target;
        }
    }
  
    // findClass是模板方法，需要重写
    protected Class<?> findClass(String name) throws ClassNotFoundException {
        throw new ClassNotFoundException(name);
    }  
}

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

沙箱安全机制：自己写的java.lang.String.class类不会被加载，这样可以防止核心API库被篡改
避免类的重复加载：当父亲已经加载了该类时，就没有必要子ClassLoader再加载一次，保证被加载类的唯一性。

如果你打算自己写一个String类，然后在其中写main()方法，这是可以做到的，但是运行的时候会抛出异常：在类java.lang.String中找不到main()方法。

如果你说想打破双亲委派机制？

沙箱安全机制示例，尝试打破双亲委派机制，用自定义类加载器加载我们自己实现的

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

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

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

        }

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

        /**
         * 重写类加载方法，实现自己的加载逻辑，不委派给双亲加载
         * @param name
         * @param resolve
         * @return
         * @throws ClassNotFoundException
         */
        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) {
                    // 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.getFindClassTime().addElapsedTimeFrom(t1);
                    sun.misc.PerfCounter.getFindClasses().increment();
                }
                if (resolve) {
                    resolveClass(c);
                }
                return c;
            }
        }
    }

    public static void main(String args[]) throws Exception {
        MyClassLoader classLoader = new MyClassLoader("D:/test");
        //尝试用自己改写类加载机制去加载自己写的java.lang.String.class
        Class clazz = classLoader.loadClass("java.lang.String");
        Object obj = clazz.newInstance();
        Method method= clazz.getDeclaredMethod("sout", null);
        method.invoke(obj, null);
        System.out.println(clazz.getClassLoader().getClass().getName());
    }
}

运行结果：
java.lang.SecurityException: Prohibited package name: java.lang
	at java.lang.ClassLoader.preDefineClass(ClassLoader.java:659)
	at java.lang.ClassLoader.defineClass(ClassLoader.java:758)

2.4 打破双亲委派机制

以tomcat为例，在tomcat中就实现了打破双亲委派机制，为什么需要这样做？

首先，tomcat是一个web容器，需要解决的问题有：

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

如果使用双亲委派机制，那么意味着无法加载两个相同类库的不同版本，默认的类加载器不管你是什么版本，只在乎你的全限定名，并且只有一份。

如果要实现jsp文件的热加载，对某个jsp进行修改，但是类名还是一样，类加载器会直接取方法区中已经存在的，修改后的jsp是不会重新加载的。所以要实现，我们需要卸载这jsp文件的类加载器，然后重新创建类加载器，重新加载jsp文件。

2.5 tomcat自定义类加载器

tomcat中的几个主要类加载器

commonClassLoader：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的双亲委派机制，实现每个webappClassLoader加载自己的目录下的class文件，不会传递给父类加载器。

# JVM tomcat