(一) 类加载过程详解 (类加载机制 第一篇)

当我们用java命令运行某个类的main函数启动程序时,首先需要通过类加载器把主类加载到 JVM。

package com.shendu;

public class JvmTest01 {
    public static final int initData = 666; 

    public int compute() { 
        int a = 1;
        int b = 2;
        int c = (a + b) * 10;
        return c;
    }

    public static void main(String[] args) {
        new JvmTest01().compute();
    }
}

如上面的代码:当我们用java命令运行某个类的main函数启动程序时,首先需要通过类加载器把主类加载到 JVM。

通过Java命令执行代码的大体流程如下:

(一) 类加载过程详解 (类加载机制 第一篇)_第1张图片

以上就是整个从jvm到java中main程序的执行全部过程,main是所有程序的入口。

整个类加载如图所示

(一) 类加载过程详解 (类加载机制 第一篇)_第2张图片

加载

加载,是指Java虚拟机查找字节流(查找.class文件),并且根据字节流创建java.lang.Class对象的过程。这个过程,将类的.class文件中的二进制数据读入内存,放在运行时区域的方法区内。然后在堆中创建java.lang.Class对象,用来封装类在方法区的数据结构。

类加载阶段:

(1)Java虚拟机将.class文件读入内存,并为之创建一个Class对象。

(2)任何类被使用时系统都会为其创建一个且仅有一个Class对象。

(3)这个Class对象描述了这个类创建出来的对象的所有信息,比如有哪些构造方法,都有哪些成员方法,都有哪些成员变量等。

验证
验证阶段作用是保证Class文件的字节流包含的信息符合JVM规范,不会给JVM造成危害。如果验证失败,就会抛出一个java.lang.VerifyError异常或其子类异常。验证过程分为四个阶段:

文件格式验证:验证字节流文件是否符合Class文件格式的规范,并且能被当前虚拟机正确的处理。

元数据验证:是对字节码描述的信息进行语义分析,以保证其描述的信息符合Java语言的规范要求

字节码验证:主要是进行数据流和控制流的分析,保证被校验类的方法在运行时不会危害虚拟机。

符号引用验证:符号引用验证发生在虚拟机将符号引用转化为直接引用的时候,这个转化动作将在解析阶段中发生。

准备
准备阶段为变量分配内存并设置类变量的初始化。在这个阶段分配的仅为类的变量(static修饰的变量),而不包括类的实例变量。对已非final的变量,JVM会将其设置成“零值”,而不是其赋值语句的值:pirvate static int size = 12;。那么在这个阶段,size的值为0,而不是12。但final修饰的类变量将会赋值成真实的值。

解析
解析过程是将常量池内的符号引用替换成直接引用。主要包括四种类型引用的解析。类或接口的解析、字段解析、方法解析、接口方法解析。

初始化

初始化,则是为标记为常量值的字段赋值的过程。换句话说,只对static修饰的变量或语句块进行初始化。

如果初始化一个类的时候,其父类尚未初始化,则优先初始化其父类。

如果同时包含多个静态变量和静态代码块,则按照自上而下的顺序依次执行。


类加载器和双亲委派机制

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

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

双亲委派机制

一个类只有被第一次主动使用时,才会被java虚拟机加载
主动使用的情况(6种)
1、创建类的实例
2、访问类的静态变量
3、调用类的静态方法
4、反射加载
5、初始化一个类的子类
6、java虚拟机启动时被标记为启动类的类

定义了几个类加载器。

  • AppClassLoader 系统类加载器 负责的目录如下:

    • %JAVA_HOME%/jre/lib
    • -Xbootclasspath 参数指定的目录
    • 系统属性sun.boot.class.path
  • ExtClassLoader 扩展类加载器 负责的目录如下:

    • %JAVA_HOME%/jre/lib/ext
    • 系统属性java.ext.dirs指定的类库
  • Bootstrap classLoader 启动类加载器 负责的目录如下:

    • 环境变量 classpath
    • -cp
    • 系统属性java.class.path

各个加载器的加载路径的验证

AppClassLoader 加载路径地址

        String appProperty = System.getProperty("java.class.path");
        for (String s : appProperty.split(";")) {
            System.out.println(s);
        }

打印为:

C:\Program Files\Java\jdk1.8.0_281\jre\lib\charsets.jar
C:\Program Files\Java\jdk1.8.0_281\jre\lib\deploy.jar
C:\Program Files\Java\jdk1.8.0_281\jre\lib\ext\access-bridge-64.jar
C:\Program Files\Java\jdk1.8.0_281\jre\lib\ext\cldrdata.jar
C:\Program Files\Java\jdk1.8.0_281\jre\lib\ext\dnsns.jar
C:\Program Files\Java\jdk1.8.0_281\jre\lib\ext\jaccess.jar
C:\Program Files\Java\jdk1.8.0_281\jre\lib\ext\jfxrt.jar
C:\Program Files\Java\jdk1.8.0_281\jre\lib\ext\localedata.jar
C:\Program Files\Java\jdk1.8.0_281\jre\lib\ext\nashorn.jar
C:\Program Files\Java\jdk1.8.0_281\jre\lib\ext\sunec.jar
C:\Program Files\Java\jdk1.8.0_281\jre\lib\ext\sunjce_provider.jar
C:\Program Files\Java\jdk1.8.0_281\jre\lib\ext\sunmscapi.jar
C:\Program Files\Java\jdk1.8.0_281\jre\lib\ext\sunpkcs11.jar
C:\Program Files\Java\jdk1.8.0_281\jre\lib\ext\zipfs.jar
C:\Program Files\Java\jdk1.8.0_281\jre\lib\javaws.jar
C:\Program Files\Java\jdk1.8.0_281\jre\lib\jce.jar
C:\Program Files\Java\jdk1.8.0_281\jre\lib\jfr.jar
C:\Program Files\Java\jdk1.8.0_281\jre\lib\jfxswt.jar
C:\Program Files\Java\jdk1.8.0_281\jre\lib\jsse.jar
C:\Program Files\Java\jdk1.8.0_281\jre\lib\management-agent.jar
C:\Program Files\Java\jdk1.8.0_281\jre\lib\plugin.jar
C:\Program Files\Java\jdk1.8.0_281\jre\lib\resources.jar
C:\Program Files\Java\jdk1.8.0_281\jre\lib\rt.jar
D:\tcl_ouyang\demo_coding\jvmclassload\target\classes
D:\tcl_ouyang\dev_soft\IntelliJ IDEA 2019.1.4\lib\idea_rt.jar

虽然打印了这么多的路径,但是其他的jar已经被它的父加载器给加载过了,根据双亲委托机制,其实AppClassLoader只是加载项目中的classpath路径下的类。

ExtClassLoader 加载路径

String extDirs = System.getProperty("java.ext.dirs");
for (String path : extDirs.split(";")) {
System.out.println(path);
}

打印

C:\Program Files\Java\jdk1.8.0_281\jre\lib\ext
C:\Windows\Sun\Java\lib\ext

Bootstrap classLoader加载路径

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

打印

file:/C:/Program%20Files/Java/jdk1.8.0_281/jre/lib/resources.jar
file:/C:/Program%20Files/Java/jdk1.8.0_281/jre/lib/rt.jar
file:/C:/Program%20Files/Java/jdk1.8.0_281/jre/lib/sunrsasign.jar
file:/C:/Program%20Files/Java/jdk1.8.0_281/jre/lib/jsse.jar
file:/C:/Program%20Files/Java/jdk1.8.0_281/jre/lib/jce.jar
file:/C:/Program%20Files/Java/jdk1.8.0_281/jre/lib/charsets.jar
file:/C:/Program%20Files/Java/jdk1.8.0_281/jre/lib/jfr.jar
file:/C:/Program%20Files/Java/jdk1.8.0_281/jre/classes

我们在来验证下,各个加载器之间的关系

        System.out.println(JvmTest02.class.getClassLoader());
        System.out.println(JvmTest02.class.getClassLoader().getParent());
        System.out.println(JvmTest02.class.getClassLoader().getParent().getParent());

打印:

sun.misc.Launcher$AppClassLoader@18b4aac2
sun.misc.Launcher$ExtClassLoader@1b6d3586
null

我们可以得出一个结论:AppClassLoader的父加载器是ExtClassLoader,然后我们的引导类加载器是不对外开放的,因为它是C++编写的,它不是一个类


JVM类加载器是有亲子层级结构的,如下图

(一) 类加载过程详解 (类加载机制 第一篇)_第3张图片

这里类加载其实就有一个双亲委派机制,加载某个类时会先委托父加载器寻找目标类,找不到再 委托上层父加载器加载,如果所有父加载器在自己的加载类路径下都找不到目标类,则在自己的 类加载路径中查找并载入目标类。 比如我们的Math类,最先会找应用程序类加载器加载,应用程序类加载器会先委托扩展类加载 器加载,扩展类加载器再委托引导类加载器,顶层引导类加载器在自己的类加载路径里找了半天 没找到Math类,则向下退回加载Math类的请求,扩展类加载器收到回复就自己加载,在自己的 类加载路径里找了半天也没找到Math类,又向下退回Math类的加载请求给应用程序类加载器, 应用程序类加载器于是在自己的类加载路径里找Math类,结果找到了就自己加载了。。 双亲委派机制说简单点就是,先找父亲加载,不行再由儿子自己加载

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

  • 沙箱安全机制:自己写的java.lang.String.class类不会被加载,这样便可以防止核心 API库被随意篡改 避免类的重复加载:

  • 当父亲已经加载了该类时,就没有必要子ClassLoader再加载一 次,保证被加载类的唯一性

你可能感兴趣的:(java随笔,java,开发语言,后端)