JVM之类加载过程

最新推荐文章于 2025-07-21 22:01:57 发布

原创最新推荐文章于 2025-07-21 22:01:57 发布 · 830 阅读

1 ·

CC 4.0 BY-SA版权

走进JVM 专栏收录该内容

5 篇文章

订阅专栏

1.第1处说明（new关键字与newInstance()方法区别）

2.第 2 处说明（使用类似的方式可获取其他声明如注解、方法等）

3.第 3 处说明（private 成员在类外依然可以修改）

四、类加载器结构

1.最高层Bootstrap

2.第二层Platform ClassLoader（JDK9）

3.第三层Application ClassLoader

一、引言

在冯·诺依曼定义的计算机模型中，任何程序都需要加载到内存才能与 CPU 进行交流。字节码 .class 文件同样需要加载到内存中，才可以实例化类。"兵马未动，粮草先行。" ClassLoader 正是准备粮草的先行军，它的使命就是提前加载 .class 类文件到内存中。在加载类时，使用的是 Parents Delegation Model ，译为双亲委派模型，这个译名有些不妥。如果意译的话，则译作 “溯源委派加载模型”更加贴切。

二、类加载过程

Java 的类加载器是一个运行时核心基础设施模块，如下图所示，主要是在启动之初进行类的 Load 、 Link 和 Init ，即加载、链接、初始化。

1.Load

第一步， Load 阶段读取类文件产生二进制流，并转化为特定的数据结构，初步校验 cafe babe 魔法数、常量池、文件长度、是否有父类等，然后创建对应类的 java.lang.Class 实例。

2.Link

第二步， Link 阶段包括验证、准备、解析三个步骤。验证是更详细的校验，比如 final 是否合规、类型是否正确、静态变量是否合理等；准备阶段是为静态变量分配内存，并设定默认值；解析类和方法确保类与类之间的相互引用正确性，完成内存结构布局。

3.Init

第三步， Init 阶段执行类构造器＜clinit> 方法，如果赋值运算是通过其他类的静态方法来完成的，那么会马上解析另外一个类，在虚拟机栈中执行完毕后通过返回值进行赋值。

三、案例

类加载是一个将 .class 字节码文件实例化成 Class 对象并进行相关初始化的过程。在这个过程中， JVM 会初始化继承树上还没有被初始化过的所有父类，并且会执行这个链路上所有未执行过的静态代码块、静态变量赋值语句等。某些类在使用时，也可以按需由类加载器进行加载。

全小写的 class 是关键字，用来定义类，而首字母大写的 Class ，它是所有 class 的类。这句话理解起来有难度，是因为类已经是现实世界中某种事物的抽象，为什么这个抽象还是另外个类 Class 的对象？示例代码如下：

public class ClassTest {
    // 数组类型有一个魔法属性：length 来获取数组长度
    private static int[] array = new int[3];
    private static int length = array.length;

    //任何小写 class 的定义的类,也有一个魔法属性：class,来获取此类的大写 Class 类对象
    private static Class<One> one = One.class;
    private static Class<Another> another = Another.class;

    public static void main(String[] args) throws Exception {
        // 通过 newInstance 方法创建 One 和 Another 的类对象 (第1处)
        One oneObject = one.newInstance();
        oneObject.call();

        Another anotherObject = another.newInstance();
        anotherObject.speak();

        // 通过 one 这个大写的 Class 对象,获取私有成员属性对象 Filed (第2处)
        Field privateFiledInOne = one.getDeclaredField("inner");

        // 设置私有对象的属性可以访问和修改 (第3处)
        privateFiledInOne.setAccessible(true);

        privateFiledInOne.set(oneObject, "world changed.");
        // 成功修改类的私有属性 inner 变量值为 world changed.
        System.out.println(oneObject.getInner());
    }
}

class One {
    private String inner = "time files.";

    public void call() {
        System.out.println("hello world.");
    }

    public String getInner() {
        return inner;
    }
}

class Another {
    public void speak() {
        System.out.println("easy coding.");
    }
}

1.第1处说明（new关键字与newInstance()方法区别）

Class 类下的newInstance()在JDK9中已经置为过时，使用getDelaredConstructor().newlnstance()的方式。这里着重说明一下 new 与newInstance 的区别。

new 关键字是强类型校验，可以调用任何构造方法，在使用 new 操作的时候，这个类可以没有被加载过。

而 Class 类下的 newInstance() 方法是弱类型，只能调用无参数构造方法，如果没有默认构造方法，就抛出InstantiationException 异常，如果此构造方法没有权限访问，则抛出IllegalAccessException 异常。Java 通过类加载器把类的实现与类的定义进行解耦，所以是实现面向接口编程、依赖倒置的必然选择。

Java中工厂模式经常使用 newInstance() 方法来创建对象，因此从为什么要使用工厂模式上可以找到具体答案：

（1）初始级别，其中 ExampleInterface 是 Example 的接口

    class c = Class.forName("Example");
    factory = (ExampleInterface)c.newInstance();

（2）进阶级别，将需要创建对象的类名定义成字符串，作为参数放入forName() 方法中

    String className = "Example";
    class c = Class.forName(className);
    factory = (ExampleInterface)c.newInstance();

（3）变身级别，已经不存在 Example 的类名称，无论 Example 类怎么变化，上述代码不变，甚至可以更换 Example 的兄弟类 Example2、Example3、Example4……，只要他们实现 ExampleInterface 接口就可以

    //从xml 配置文件中获得字符串    
    String className = readfromXMlConfig();
    class c = Class.forName(className);
    factory = (ExampleInterface)c.newInstance();

从JVM的角度看，我们使用关键字new创建一个类的时候，这个类可以没有被加载。但是使用newInstance()方法的时候，就必须保证：1、这个类已经加载；2、这个类已经连接了。而完成上面两个步骤的正是Class的静态方法forName()所完成的，这个静态方法调用了启动类加载器，即加载java API的那个加载器。

现在可以看出，newInstance()实际上是把new这个方式分解为两步，即首先调用Class加载方法加载某个类，然后实例化。这样分步的好处是显而易见的。我们可以在调用class的静态加载方法forName时获得更好的灵活性，提供给了一种降耦的手段。

2.第 2 处说明（使用类似的方式可获取其他声明如注解、方法等）

3.第 3 处说明（private 成员在类外依然可以修改）

private 成员在类外是否可以修改？通过 setAccessible( true）操作，即可使用大写 Class 类的 set 方法修改其值。如果没有这一步，则抛出如下异常

Exception in thread "main" java.lang.IllegalAccessException: Class example.ClassTest can not access a member of class example.One with modifiers "private"

通过以上示例，对于 Class 这个"类中之王"，不会有恐惧心理了吧？那么回到类加载中，类加载器是如何定位到具体的类文件并读取的呢？

四、类加载器结构

类加载器类似于原始部落结构，存在权力等级制度。

1.最高层Bootstrap

最高的一层是家族中威望最高的 Bootstrap ，它是在 JVM 启动时创建的，通常由与操作系统相关的本地代码实现，是最根基的类加载器，负责装载最核心的 Java 类，比如 Object、System 、String 等；它是通过 C/C++ 实现的，并不存在于 JVM 体系内。

2.第二层Platform ClassLoader（JDK9）

第二层是在 JDK9 版本中，称为 Platform ClassLoader ，即平台类加载器，用以加载一些扩展的系统类，比如 XML，加密、压缩相关的功能类等，而 JDK9 之前的加载器是Extension ClassLoader。第二层平台类加载器是通过Java 语言实现。

3.第三层Application ClassLoader

第三层是 Application ClassLoader 的应用类加载器，主要是加载用户定义的 CLASSPATH 路径下的类。第三层应用类加载器是通过Java 语言实现。

第二、三层类加载器为 Java 语言实现，用户也可以自定义类加载器。查看本地类加载器的方式如下（编译环境JDK7）：

    ClassLoader classLoader = ClassTest.class.getClassLoader();
    // 当前正在使用的类加载器    
    System.out.println(classLoader);
    ClassLoader parent = classLoader.getParent();
    // 当前正在使用的类加载器的父加载器
    System.out.println(parent);
    ClassLoader grandparent = parent.getParent();
    // 当前正在使用的类加载器的祖父加载器
    System.out.println(grandparent);

打印结果如下：

sun.misc.Launcher$AppClassLoader@146ccf3e
sun.misc.Launcher$ExtClassLoader@7399f9eb
null

因为在JDK7环境中，所以第二层打印结果为ExtClassLoader。AppClassLoader 的 Parent 为 Bootstrap，它是通过 C/C++实现的，并不存在于 JVM 体系内，所以输出为 null，类加载器具有等级制度，但是并非继承关系，以组合的方式来复用父加载器的功能，这也符合组合优先原则，详细的双亲委派模型见下文。

五、类加载过程（双亲委派模型）

低层次的当前类加载器，不能覆盖更高层次类加载器已经加载的类。如果低层次的类加载器想加载一个未知类，要非常礼貌地向上逐级询问："请问，这个类已经加载了吗？" 被询问的高层次类加载器会自问两个问题，第一，我是否已加载过此类？第二，如果没有，是否可以加载此类？只有当所有高层次类加载器在两个问题上的答案均为"否"时，才可以让当前类加载器加载这个未知类。

如上图所示，左侧绿色箭头向上逐级询问是否已加载此类，直至 Bootstrap ClassLoader ，然后向下逐级尝试是否能够加载此类，如果都加载不了，则通知发起加载请求的当前类加载器，准予加载。在右侧的三个小标签里，列举了此层类加载器主要加载的代表性类库 ，事实上不止于此。通过如下代码可以查看 Bootstrap 所有已经加载的类库：

    URL[] urLs = Launcher.getBootstrapClassPath().getURLs();
    for (URL urL : urLs) {
        System.out.println(urL.toExternalForm());
    }

执行结果如下：

file:/C:/Software/JDK1.7/jre/lib/resources.jar
file:/C:/Software/JDK1.7/jre/lib/rt.jar
file:/C:/Software/JDK1.7/jre/lib/sunrsasign.jar
file:/C:/Software/JDK1.7/jre/lib/jsse.jar
file:/C:/Software/JDK1.7/jre/lib/jce.jar
file:/C:/Software/JDK1.7/jre/lib/charsets.jar
file:/C:/Software/JDK1.7/jre/lib/jfr.jar
file:/C:/Software/JDK1.7/jre/classes

Bootstrap 加载的路径可以追加，不建议修改或删除原有加载路径 。在 JVM 中增加如下启动参数，则能通过Class.forName 正常读取到指定类，说明此参数可以增加 Bootstrap 的类加载路径：

-Xbootclasspath/a:/Users/mark/Java/src

如果想在启动时观察加载了哪个 jar 包中的哪个类，可以增加 -XX：＋TraceClassLoading参数，此参数在解决类冲突时非常实用，毕竟不同的 JVM 环境对于加载类的顺序并非是一致的。有时想观察特定类的加载上下文，由于加载的类数量众多，调试时很难捕捉到指定类的加载过程，这时可以使用条件断点功能。比如，想查看 HashMap 的加载过程，在 loadClass 处打个断点，并且在 condition 框内输入var1.equals("java.util.HashMap")条件。

六、自定义类加载器

在明白了类加载器的实现机制后，知道双亲委派模型并非强制模型（我们可以对其中加载路径进行修改删除，而非一定要加载某些包），用户可以自定义类加载器，在什么情况下需要自定义类加载器呢？

1.需要自定义类加载器情形

（1）隔离加载类

在某些框架内进行中间件与应用的模块隔离，把类加载到不同的环境。比如，阿里内某容器框架通过自定义类加载器确保应用中依赖的 jar 包不会影响到中间件运行时使用的 jar 包。

（2）修改类加载方式

类的加载模型并非强制，除 Bootstrap 外，其他的加载并非定要引入，或者根据实际情况在某个时间点进行按需进行动态加载

（3）扩展加载源

比如从数据库、网络，甚至是电视机机顶盒进行加载。

（4）防止源码泄露

Java 代码容易被编译和篡改，可以进行编译加密。那么类加载器也需要自定义，还原加密的字节码。

2.实现自定义类加载器的步骤

实现自定义类加载器的步骤：继承 ClassLoader，重写 findClass() 方法，调用 defineClass() 方法。一个简单的类加载器实现的示例代码如下：

首先我们定义一个待加载的实体类Customer，我们把生成的Customer.class剪切到D盘目录下D:/Customer.class

public class Customer {
    private String name;
    private Integer age;

    public String getName() {
        return name;
    }

    public void setName(String name) {
        this.name = name;
    }

    public Integer getAge() {
        return age;
    }

    public void setAge(Integer age) {
        this.age = age;
    }

    @Override
    public String toString() {
        return "Customer{" +
                "name='" + name + '\'' +
                ", age=" + age +
                '}';
    }
}

接着我们定义一个自定义类加载器

public class CustomClassLoader extends ClassLoader {
    // 继承ClassLoader类
    @Override
    protected Class<?> findClass(String name) throws ClassNotFoundException {
        // 重写findClass方法
        try {
            byte[] result = getClassFromCustomPath(name);
            if (result == null) {
                throw new FileNotFoundException();
            } else {
                // 调用defineClass方法
                return defineClass(name, result, 0, result.length);
            }
        } catch (FileNotFoundException e) {
            e.printStackTrace();
        } catch (IOException e) {
            e.printStackTrace();
        }
        throw new ClassNotFoundException();
    }

    private byte[] getClassFromCustomPath(String name) throws IOException {
        // 从自定义路径中加载指定类
        // 这里要读入.class的字节，因此要使用字节流
        FileInputStream fis = new FileInputStream(new File("D:/Customer.class"));
        FileChannel fc = fis.getChannel();
        ByteArrayOutputStream baos = new ByteArrayOutputStream();
        WritableByteChannel wbc = Channels.newChannel(baos);
        ByteBuffer by = ByteBuffer.allocate(1024);

        while (true)
        {
            int i = fc.read(by);
            if (i == 0 || i == -1) {
                break;
            }
            by.flip();
            wbc.write(by);
            by.clear();
        }

        fis.close();

        return baos.toByteArray();
    }

}

测试类

public class TestMethod {
    public static void main(String[] args) {
        CustomClassLoader customClassLoader = new CustomClassLoader();
        try {
            Class<?> clazz = Class.forName("example.Customer", true, customClassLoader);
            Object obj = clazz.newInstance();
            System.out.println(obj.getClass().getClassLoader());
            System.out.println(obj.getClass().getClassLoader().getParent());
        } catch (Exception e) {
            e.printStackTrace();
        }
    }
}

测试结果

example.CustomClassLoader@4e543c44
sun.misc.Launcher$AppClassLoader@146ccf3e

注意点，很可能你打印出来的是

sun.misc.Launcher$AppClassLoader@146ccf3e
sun.misc.Launcher$ExtClassLoader@7399f9eb

那是因为你没有删除项目路径下编译生成的 Customer.class 文件，你的Eclipse或者IDEA自动编译Customer类（此时是用的AppClassLoader编译）后，生成了Customer.class 文件，当你准备用自定义类加载器的时候，根据双亲委任模型，会向上级请示是否已经加载过此类，显然，当询问到 AppClassLoader 加载器时得到的答案为：是。因此此时自定义类加载器变不会生效

由于中间件一般都有自己的依赖 jar 包，在同一个工程内引用多个框架时，往往被迫进行类的仲裁。按某种规则 jar 包的版本被统一指定，导致某些类存在包路径、类名相同的情况，就会引起类冲突，导致应用程序出现异常。主流的容器类框架都会
自定义类加载器，实现不同中间件之间的类隔离，有效避免了类冲突。