JVM-类加载机制

全干丶

已于 2022-05-25 20:57:07 修改

阅读量172

点赞数

文章标签： jvm

于 2022-05-25 20:41:02 首次发布

本文链接：https://blog.csdn.net/errrl/article/details/124973372

版权

JVM 的类加载机制

一、加载Class（类）

1. 加载路径

本地系统中直接加载 rt.jar
通过网络下载class 文件
从zip，jar等归档文件中加载class 文件（rt.jar、src.zip）
从专有数据库中提取class 文件
将java 源文件动态编译为class 文件

2. 类加载器加载

将class 文件字节码内容加载到内存中，并将这些静态数据转换成方法区的运行时数据结构，然后在堆中生成一个代表这个类的java.lang.Class对象，作为方法区中类数据的访问入口。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-n3ExkyEV-1653482260793)(imgclip_1.png "imgclip_1.png")]

JVM 规范定义了那些类加载器：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-3jaRL7lK-1653482260796)(imgclip_2.png "imgclip_2.png")]

启动类加载器：BootstrapClassLoader，负责加载存放在 JDK\jre\lib(JDK代表JDK的安装目录，下同)下，或被 -Xbootclasspath参数指定的路径中的，并且能被虚拟机识别的类库（如rt.jar，所有的java.开头的类均被 BootstrapClassLoader加载）。启动类加载器是无法被Java程序直接引用的。也就是说JDK 中的类也是启动类加载器加载的。
扩展类加载器：ExtensionClassLoader，该加载器由 sun.misc.Launcher$ExtClassLoader实现，它负责加载 JDK\jre\lib\ext目录中，或者由 java.ext.dirs系统变量指定的路径中的所有类库（如javax.开头的类），开发者可以直接使用扩展类加载器。
应用程序类加载器： ApplicationClassLoader，该类加载器由 sun.misc.Launcher$AppClassLoader来实现，它负责加载用户类路径（ClassPath）所指定的类，开发者可以直接使用该类加载器，如果应用程序中没有自定义过自己的类加载器，一般情况下这个就是程序中默认的类加载器。此加载器还有一个名称 “SystemClassLoader”。

获取类加载器：

public class Demo {
    public static void main(String[] args) throws ClassNotFoundException {
        ClassLoader systemClassLoader = ClassLoader.getSystemClassLoader();
        System.out.println(systemClassLoader);  // sun.misc.Launcher$AppClassLoader@18b4aac2
        ClassLoader parent = systemClassLoader.getParent();
        System.out.println(parent); // sun.misc.Launcher$ExtClassLoader@1b6d3586
        ClassLoader parent1 = parent.getParent();
        System.out.println(parent1);  // null 无法被访问 引导类加载器
        System.out.println("自定义类的加载器：" + Demo.class.getClassLoader());  // 自定义类的加载器：sun.misc.Launcher$AppClassLoader@18b4aac2
        Class<?> aClass = Class.forName("java.lang.Object");
        System.out.println("JDK 的加载器：" + aClass.getClassLoader());  // JDK 的加载器：null  引导类加载器无法被访问
        String property = System.getProperty("java.class.path");
        System.out.println(property);
        /*
        C:\Program Files\Java\jdk1.8.0_261\jre\lib\charsets.jar;
        C:\Program Files\Java\jdk1.8.0_261\jre\lib\deploy.jar;
        C:\Program Files\Java\jdk1.8.0_261\jre\lib\ext\access-bridge-64.jar;
        C:\Program Files\Java\jdk1.8.0_261\jre\lib\ext\cldrdata.jar;
        C:\Program Files\Java\jdk1.8.0_261\jre\lib\ext\dnsns.jar;
        C:\Program Files\Java\jdk1.8.0_261\jre\lib\ext\jaccess.jar;
        C:\Program Files\Java\jdk1.8.0_261\jre\lib\ext\jfxrt.jar;
        C:\Program Files\Java\jdk1.8.0_261\jre\lib\ext\localedata.jar;
        C:\Program Files\Java\jdk1.8.0_261\jre\lib\ext\nashorn.jar;
        C:\Program Files\Java\jdk1.8.0_261\jre\lib\ext\sunec.jar;
        C:\Program Files\Java\jdk1.8.0_261\jre\lib\ext\sunjce_provider.jar;
        C:\Program Files\Java\jdk1.8.0_261\jre\lib\ext\sunmscapi.jar;
        C:\Program Files\Java\jdk1.8.0_261\jre\lib\ext\sunpkcs11.jar;
        C:\Program Files\Java\jdk1.8.0_261\jre\lib\ext\zipfs.jar;
        C:\Program Files\Java\jdk1.8.0_261\jre\lib\javaws.jar;
        C:\Program Files\Java\jdk1.8.0_261\jre\lib\jce.jar;
        C:\Program Files\Java\jdk1.8.0_261\jre\lib\jfr.jar;
        C:\Program Files\Java\jdk1.8.0_261\jre\lib\jfxswt.jar;
        C:\Program Files\Java\jdk1.8.0_261\jre\lib\jsse.jar;
        C:\Program Files\Java\jdk1.8.0_261\jre\lib\management-agent.jar;
        C:\Program Files\Java\jdk1.8.0_261\jre\lib\plugin.jar;
        C:\Program Files\Java\jdk1.8.0_261\jre\lib\resources.jar;
        C:\Program Files\Java\jdk1.8.0_261\jre\lib\rt.jar;
        C:\Users\Jming_er\Desktop\javaStudy\out\production\javaStudy;
        F:\intellij\IntelliJ IDEA 2018.1.7\lib\idea_rt.jar
         */
    }
}

注意：SystemClassLoader 另外一个名字 AppClassLoader

拓展：自定义类加载器：https://www.cnblogs.com/szlbm/p/5504631.html

3. JVM 的类加载机制

全盘负责：当一个类加载器负责加载某个Class时，该Class所依赖的和引用的其他Class也将由该类加载器负责载入，除非显示使用另外一个类加载器来载入。
缓存机制：缓存机制将会保证所有加载过的Class都会被缓存，当程序中需要使用某个Class时，类加载器先从缓存区寻找该Class，只有缓存区不存在，系统才会读取该类对应的二进制数据，并将其转换成Class对象，存入缓存区。这就是为什么修改了Class后，必须重启JVM，程序的修改才会生效。
双亲委派：先让父类加载器试图加载该类，只有在父类加载器无法加载该类时才尝试从自己的类路径中加载该类。

拓展：双亲委派机制即把请求交由父类处理，它是一种任务委派模式

工作流程是：如果一个类加载器收到了类加载的请求，它首先不会自己去尝试加载这个类，而是把请求委托给父加载器去完成，依次向上，因此，所有的类加载请求最终都应该被传递到顶层的启动类加载器中，只有当父加载器在它的搜索范围中没有找到所需的类时，即无法完成该加载，子加载器才会尝试自己去加载该类。例如：

当 AppClassLoader加载一个class时，它首先不会自己去尝试加载这个类，而是把类加载请求委派给父类加载器ExtClassLoader 去完成。
当 ExtClassLoader加载一个class时，它首先也不会自己去尝试加载这个类，而是把类加载请求委派给BootStrapClassLoader 去完成。
如果 BootStrapClassLoader加载失败（例如在 $JAVA_HOME/jre/lib里未查找到该class），会使用 ExtClassLoader 来尝试加载；
ExtClassLoader也加载失败，则会使用 AppClassLoader来加载，如果 AppClassLoader也加载失败，则会报出异常 ClassNotFoundException。

流程顺序见上图。

源码：使用ClassLoader 对象中的loadClass方法加载类

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) {  // c==null表示没有加载，如果有父类的加载器则让父类加载器加载递归调用loadClass()尝试加载。直到找到BootStrapClassLoader，bootStrapClassloader比较特殊无法通过get获取返回null，就调用findBootstrapClassOrNull尝试加载。
                        c = parent.loadClass(name, false);
                    } else {
                        c = findBootstrapClassOrNull(name);
                    }
                } catch (ClassNotFoundException e) {
                }

                if (c == null) {  // 如果上面的递归还是加载不了，就使用自定义的ClassLoader 加载。
                    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 类看看加载的是JDK 的内置类String 还是自定义的java.lang.String 类：

package java.lang;

public class String {
    static{
        System.out.println("使用一个静态代码块验证是否能被加载");
    }
}

public class Demo {
    public static void main(String[] args) throws ClassNotFoundException {
        Class<?> cl = Class.forName("java.lang.String");
    }
}

输出结果：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-DSYh34vx-1653482260802)(imgclip_3.png "imgclip_3.png")]

说明：没有输出静态代码块中的内容，也就是说加载的是JDK 的内置类String。为什么呢？原因就是自定义的String 类本应该由appClassLoader 加载。但是那时它不会自己先加载，而是把这个请求委托给上级加载器加载。也就是扩展类加载器，到了扩展类加载器发现String类不归自己管，再委托给父类加载器（引导类加载器），这时发现是java.lang包，这事就归引导类加载器管，所以加载的是 JDK 自带的 String 类。

实验二：在自定义的java.lang.String 类中添加main 方法：

package java.lang;

public class String {
    static{
        System.out.println("使用一个静态代码块验证是否能被加载");
    }
    public static void main(String[] args){
        System.out.println("String")	
    }
}

输出结果：错误：在类java.lang.String 中找不到main 方法。原因就是双亲委派机制此处加载的是JDK 中的内置类String ，但是在引导类加载器的核心类库API 中String 类是没有main 方法的。

实验三：在java.lang 包下自定义类：

package java.lang;

public class MyString {
    public static void main(String[] args){
        System.out.println("MyString")	
    }
}

输出结果：会出现安全错误，原因就是出于保护机制，java.lang 包下不允许自定义类。

综上所述：双亲委派机制的优势在于避免重复加载类，保护程序安全防止核心库API 被篡改。

4. 类的加载

类的加载有三种方式：

命令行启动应用时候由JVM初始化加载
通过Class.forName()方法动态加载
通过ClassLoader.loadClass()方法动态加载

public class Demo {
    public static void main(String[] args) throws ClassNotFoundException {
        ClassLoader classLoader = Demo.class.getClassLoader();
        Class<?> test = classLoader.loadClass("src.com.study.Test");  // 不执行静态代码块
        Class<?> test2 = Class.forName("src.com.study.Test");  // 执行静态代码块
        Class<?> test3 = Class.forName("src.com.study.Test", false, classLoader);  // 第二个参数决定执不执行静态代码块
        System.out.println(test);
        System.out.println(test2);
        Test.method();  // 执行静态代码块
    }
}

class Test {
    static {
        System.out.println("静态代码块");
    }

    public static void method() {
        System.out.println("调用了一个方法");
    }
}

区别：

Class.forName()：将类的.class文件加载到jvm中之外，还会对类进行解释，执行类中的static块；
ClassLoader.loadClass()：只干一件事情，就是将.class文件加载到jvm中，不会执行static中的内容，只有在newInstance才会去执行static块。
Class.forName(name,initialize,loader)带参函数也可控制是否加载static块。并且只有调用了newInstance()方法采用调用构造函数，创建类的对象。

二、类的生命周期

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-8T4kcyIa-1653482260806)(imgclip.png "imgclip.png")]

加载

查找并加载类的二进制数据加载时类加载过程的第一个阶段，在加载阶段，虚拟机需要完成以下三件事情：

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

相对于类加载的其他阶段而言，加载阶段（准确地说，是加载阶段获取类的二进制字节流的动作）是可控性最强的阶段，因为开发人员既可以使用系统提供的类加载器来完成加载，也可以自定义自己的类加载器（ClassLoader）来完成加载。

加载阶段完成后，虚拟机外部的二进制字节流就按照虚拟机所需的格式存储在方法区之中，而且在Java堆中也创建一个 java.lang.Class类的对象，这样便可以通过该对象访问方法区中的这些数据。

连接

**验证：**确保被加载的类的正确性

文件格式验证：验证字节流是否符合Class文件格式的规范
元数据的验证：对字节码描述的信息进行语义分析（注意：对比javac编译阶段的语义分析），以保证其描述的信息符合Java语言规范的要求；例如：这个类是否有父类，除了 java.lang.Object之外。
字节码的验证：通过数据流和控制流分析，确定程序语义是合法的、符合逻辑的。
符号引用的验证：确保解析动作能正确执行。