Java基础_虚拟机3：（JVM类加载机制）

浅水壁虎

已于 2024-05-07 15:19:08 修改

阅读量185

点赞数 1

分类专栏： Java基础文章标签： java scala

于 2019-05-31 18:29:59 首次发布

本文链接：https://blog.csdn.net/huyiju/article/details/90702980

版权

Java基础专栏收录该内容

20 篇文章 0 订阅

订阅专栏

1：类文件概述

2：类加载过程

2.1：对象的创建

2.2：类加载过程（结合2.1的对象创建）

1：类文件概述

在 Java 中，JVM 可以理解的代码就叫做字节码（即扩展名为 .class 的文件），它不面向任何特定的处理器，只面向虚拟机。Java 语言通过字节码的方式，在一定程度上解决了传统解释型语言执行效率低的问题，同时又保留了解释型语言可移植的特点。所以 Java 程序运行时比较高效，而且，由于字节码并不针对一种特定的机器，因此，Java 程序无须重新编译便可在多种不同操作系统的计算机上运行。

Clojure（Lisp 语言的一种方言）、Groovy、Scala 等语言都是运行在 Java 虚拟机之上。下图展示了不同的语言被不同的编译器编异常.class文件最终运行在 Java 虚拟机之上。.class文件的二进制格式可以使用 WinHex 查看。

可以说.class文件是不同的语言在 Java 虚拟机之间的重要桥梁，同时也是支持 Java 跨平台很重要的一个原因。

2：类加载过程

2.1：对象的创建

对象创建的步骤，在我们用new关键字的时候，对象的创建步骤如下：

User user=new User();

1：类型检查（首先检查在常量池中是否能找到这个类的信息，是否已经被加载、解析和初始化过）

2：为对象分配内存，内存是固定的，因为你对象的各种类型字段都是起源于基本数据类型。对象所需要的内存在类加载之后便可以完全确定，采用如下两种方法划分新的内存空间。

指针碰撞（内存是连续的通过指针摆动划分新的所需内存）

空闲列表（内存不是连续的，有碎片化，虚拟机维护一个列表，这种请况从空闲列表中找到可用的内存）

3：对象初始化为零

4：执行对象的init方法，最终创建对象

2.2：类加载过程（结合2.1的对象创建）

Class 文件需要加载到虚拟机中之后才能运行和使用，那么虚拟机是如何加载这些 Class 文件呢？

系统加载 Class 类型的文件主要三步:加载->连接->初始化。连接过程又可分为三步:验证->准备->解析。

类加载过程

针对这个过过程我们对象的创建来描述：

创建自定义对象：

User u=new User();

第一步：加载阶段，加载User类的class文件（通过包名+类名的形式加载）

第二步：验证阶段，我们知道class文件是虚拟机能够识别的二进制文件，需要严格验证这个class文件中的文件格式、元数据、字节码副符号引用等信息，保证不会产生莫名错误。这一步很重要。

第三步：准备阶段，为对象的类变量初始化零值，不包含实例变量。

public static int a=10; 这个阶段初始化零值。

3：类加载器总结

JVM 中内置了三个重要的 ClassLoader，除了 BootstrapClassLoader 其他类加载器均由 Java 实现且全部继承自java.lang.ClassLoader：

BootstrapClassLoader(启动类加载器) ：最顶层的加载类，由C++实现，负责加载 %JAVA_HOME%/lib目录下的jar包和类或者或被 -Xbootclasspath参数指定的路径中的所有类。
ExtensionClassLoader(扩展类加载器) ：主要负责加载目录 %JRE_HOME%/lib/ext 目录下的jar包和类，或被 java.ext.dirs 系统变量所指定的路径下的jar包。
AppClassLoader(应用程序类加载器) :面向我们用户的加载器，负责加载当前应用classpath下的所有jar包和类。

3.1：双亲委派模型

双亲委派模型介绍：

java 平台使用委派模型来加载类。基本思想就是，除了启动类加载器，每一个加载类器都有一个父类加载器，加载类的时候逐级上加载，如果分类加载器无法加载，则自己加载。

每一个类都有一个对应它的类加载器。系统中的 ClassLoder 在协同工作的时候会默认使用 双亲委派模型 。即在类加载的时候，系统会首先判断当前类是否被加载过。已经被加载的类会直接返回，否则才会尝试加载。加载的时候，首先会把该请求委派该父类加载器的 loadClass() 处理，因此所有的请求最终都应该传送到顶层的启动类加载器 BootstrapClassLoader 中。当父类加载器无法处理时，才由自己来处理。当父类加载器为null时，会使用启动类加载器 BootstrapClassLoader 作为父类加载器。

ClassLoader

每个类加载都有一个父类加载器，我们通过下面的程序来验证。

public class ClassLoaderDemo {
    public static void main(String[] args) {
     		System.out.println("当前加载器1(引用程序类加载器)："+ClassLoaderDemo1.class.getClassLoader());
		System.out.println("当前加载器2(扩展类加载器)："+ClassLoaderDemo1.class.getClassLoader().getParent());
		System.out.println("当前加载器3(启动类加载器)："+ClassLoaderDemo1.class.getClassLoader().getParent().getParent());

    }
}

Output

当前加载器1(引用程序类加载器)：sun.misc.Launcher$AppClassLoader@2a139a55
当前加载器2(扩展类加载器)：sun.misc.Launcher$ExtClassLoader@7852e922
当前加载器3(启动类加载器)：null

AppClassLoader的父类加载器为（扩展加载器）ExtClassLoader ExtClassLoader的父类加载器为null，null并不代表ExtClassLoader没有父类加载器，而是 Bootstrap ClassLoader 。

其实这个双亲翻译的容易让别人误解，我们一般理解的双亲都是父母，这里的双亲更多地表达的是“父母这一辈”的人而已，并不是说真的有一个 Mather ClassLoader 和一个 Father ClassLoader 。另外，类加载器之间的“父子”关系也不是通过继承来体现的，是由“优先级”来决定。官方API文档对这部分的描述如下:

The Java platform uses a delegation model for loading classes. The basic idea is that every class loader has a "parent" class loader. When loading a class, a class loader first "delegates" the search for the class to its parent class loader before attempting to find the class itself.

双亲委派模型实现源码分析：

双亲委派模型的实现代码非常简单，逻辑非常清晰，都集中在 java.lang.ClassLoader 的 loadClass() 中，相关代码如下所示。

private final ClassLoader parent; 
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 {//父加载器为空，使用启动类加载器 BootstrapClassLoader 加载
                        c = findBootstrapClassOrNull(name);
                    }
                } catch (ClassNotFoundException e) {
                   //抛出异常说明父类加载器无法完成加载请求
                }

                if (c == null) {
                    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;
        }
    }

3.2：双亲委派模型的好处

1：双亲委派模型保证了Java程序的稳定运行，可以避免类的重复加载（JVM 区分不同类的方式不仅仅根据类名，相同的类文件被不同的类加载器加载产生的是两个不同的类），

2：也保证了 Java 的核心 API 不被篡改（比如网络传递一个名为java.lang.Integer的类，这个时候就会层层加载，到启动类类加载器，而启动类加载器在核心Java API发现这个名字的类，发现该类已被加载，并不会重新加载网络传递的过来的java.lang.Integer，而直接返回已加载过的Integer.class，这样便可以防止核心API库被随意篡改）。如果不用没有使用双亲委派模型，而是每个类加载器加载自己的话就会出现一些问题，比如我们编写一个称为 java.lang.Object 类的话，那么程序运行的时候，系统就会出现多个不同的 Object 类。

3.3：自定义类加载器

为了避免双亲委托机制，我们可以自己定义一个类加载器，然后重载 loadClass() 即可。

3.4：为什么需要自定义类加载器？

我们需要的类不一定存放在已经设置好的classPath下(有系统类加载器AppClassLoader加载的路径)，对于自定义路径中的class类文件的加载，我们需要自己的ClassLoader，不在classPath下的类，需要用自定义加载类。
有时我们不一定是从类文件中读取类，可能是从网络的输入流中读取类，这就需要做一些加密和解密操作，这就需要自己实现加载类的逻辑，当然其他的特殊处理也同样适用。（网络流中的类）
可以定义类的实现机制，实现类的热部署,如OSGi中的bundle模块就是通过实现自己的ClassLoader实现的。

除了 BootstrapClassLoader 其他类加载器均由 Java 实现且全部继承自java.lang.ClassLoader。如果我们要自定义自己的类加载器，很明显需要继承 ClassLoader。