类加载与类文件结构

类加载机制

为什么需要类加载

• 首先我们计算机的主要组成是输入设备，输出设备，计算核心（运算器-控制器）CPU，内存，其中我们的核心CPU只能和内存交互，不能直接和其他设备（包括硬盘）交互的
• 我们开发工作将需求产品变成一组源代码*.java，然后通过编译器将源代码变成一组类文件*.class文件，通常我们将其类文件保存到硬盘上，而且我们一些JDK提供的类文件也是存储在硬盘中
• 这时候我们就需要解决一个问题：我们CPU只和内存打交道，我们的数据（类文件）放在硬盘上，我们就需要将我们的类文件从硬盘加载到内容中，而负责这项工作的就是JVM的类加载的子模块

• 类加载器子系统负责从文件系统或者网络中加载Class文件，class文件在文件开头有特定的文件标识。

• ClassLoader只负责class文件的加载，至于它是否可以运行，则由Execution Engine决定。

• 加载的类信息存放于一块称为方法区的内存空间。除了类的信息外，方法区中还会存放运行时常量池信息，可能还包括字符串字面量和数字常量（这部分常量信息是Class文件中常量池部分的内存映射）

类加载的时机

• 我们的JVM采用的方案就是第二种，当一个类被用到的时候并且这个类并没有被加载，就会将这个类加载到内存中，那我们需要注意的点就是什么时候类被用到

类的主动使用和被动使用
主动使用——会触发类的初始化

1. 创建类的实例（包括反射，new等）
2. 访问某个类或接口的静态变量，或者对该静态变量赋值 （被final修饰，已经在编译器把结果放入常量池的静态字段除外）
3. 调用一个类的静态方法
4. 反射（比如：Class.forName（“com.atguigu.Test”））
5. 初始化一个类的子类 ，需要先初始化这个子类的父类
6. Java虚拟机启动时被标明为启动类的类，也就是包含main方法的那个类
7. JDK 7 开始提供的动态语言支持：
   java.lang.invoke.MethodHandle实例的解析结果
   REF_getStatic、REF_putStatic、REF_invokeStatic句柄对应的类没有初始化，则初始化
8. 当一个接口中定义了JDK8新加入的默认方法（被deafult修饰的接口方法），如果有这个接口的实现类发生了初始化，那么接口在之前也需要初始化

除了以上七种情况，其他使用Java类的方式都被看作是对类的被动使用，都不会导致类的初始化。

被动使用的例子

通过子类调用父类的静态字段

public class SuperClass {
    static {
        System.out.println("SuperClass 被初始化了");
    }
    public static int value=123;
}
public class SubClass extends SuperClass {
    static {
        System.out.println("SubClass 被初始化了");
    }

}
public class Main {
    public static void main(String[] args) {
        System.out.println(cn.itcast.jvm.t3.book.SubClass.value);
    }
}
//输出结果
SuperClass 被初始化了
123

Process finished with exit code 0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

• 对于我们的静态字段，只有直接定义这个字段的类才会被初始化，因此通过子类去调用父类中定义的静态字段，只会触发父类的初始化而不会触发子类的初始化，但是会加载子类

package cn.itcast.jvm.t3.book;
public class SuperClass {
    static {
        System.out.println("SuperClass 被初始化了");
    }
    public static int value=123;
}
public class NotInitialization {
    public static void main(String[] args) {
        SuperClass []sca=new SuperClass[10];
    }
}
//输出结果

Process finished with exit code 0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

• 我们发现并没有触发 cn.itcast.jvm.t3.book.SpuerClass的初始化，但是这段代码会触发另一个名为 [Lprg.cn.itcast.jvm.t3.book.SuperClass的初始化，对于用户来说，这并不是一个合法的数据类型，它是一个由虚拟机自动生成，直接继承与Object的子类，创建动作由字节码anewarray触发，这个类代表一个元素类型为 cn.itcast.jvm.t3.book.SpuerClass的一维数组，数组应有的属性和方法都在这个类中实现

package cn.itcast.jvm.t3.book;

public class ConstClass {
    static {
        System.out.println("ConstClass 被初始化");

    }
    public static  final String HELLO_WORLD="heloo world";
}
public class Main {
    public static void main(String[] args) {
        System.out.println(ConstClass.HELLO_WORLD);
    }
}
//输出结果
heloo world

Process finished with exit code 0

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

• 输出结果表示并没有进行ConstClass的初始化，是因为我们的编译阶段通过常量优化，直接将常量值“hello world”直接存储到了我们的Main这个类文件的常量池

关于接口的初始化

• 当一个类在初始化的时候，要求其父类全部已经初始化过，但是在一个接口在初始化的时候，并不要求其父接口都完成了初始化，只有真正使用父接口的时候，如引用接口中定义的常量才会被初始化

类加载详细过程

/**
 *示例代码
 */
public class HelloLoader {
    public static void main(String[] args) {
        System.out.println("Hello World!");
    }
}
1
2
3
4
5
6
7
8

加载

• 加载阶段是我们的整个类加载过程的一个阶段
• 通过一个类的全限定名来获取定义此类的二进制字节流
• 将这个字节流所代表的静态存储结构转换成方法区的运行时数据结构
• 在内存中生成一个代表这个雷达的java.lang.Class对象，作为方法区这个类的各种数据的访问接口

• 类文件的主要组成

  • _java_mirror 即 java 的类镜像，例如对 String 来说，就是 String.class，作用是把 klass 暴露给 java 使用

  • _super 即父类

  • _fields 即成员变量

  • _methods 即方法

  • _constants 即常量池

  • _class_loader 即类加载器

  • _vtable 虚方法表

  • _itable 接口方法表

• instanceKlass 这样的【元数据】是存储在方法区（1.8 后的元空间内），但 _java_mirror是存储在堆中

• 将类的字节码载入方法区中，内部采用 C++ 的 instanceKlass 描述 java 类，
  _java_mirror 即 java 的类镜像，例如对 String 来说，就是 String.class，作用是把 klass 暴露给 java 使用

关于全限定名

• 首先类的名称=包名+类名

• 我们的类文件在硬盘上，硬盘上的数据被抽象成文件了（一颗文件系统树），我们的类加载如何去找到类文件的

• 我们自己写的类和官方停供的类处理方式一样吗，肯定处理方式不可能，所以对于不同的类文件需要不同的类加载器去处理

• 我们的JVM就是通过类加载器+类的权威名称来唯一确定一个类

  • 在JVM中表示两个class对象是否为同一个类存在两个必要条件：

    • 类的完整类名必须一致，包括包名。

    • 加载这个类的ClassLoader（指ClassLoader实例对象）必须相同。

补充：加载class文件的方式

• 从本地系统中直接加载

• 通过网络获取，典型场景：Web Applet

• 从zip压缩包中读取，成为日后jar、war格式的基础

• 运行时计算生成，使用最多的是：动态代理技术

• 由其他文件生成，典型场景：JSP应用

• 从专有数据库中提取.class文件，比较少见

• 从加密文件中获取，典型的防Class文件被反编译的保护措施

换句话说，在JVM中，即使这两个类对象（class对象）来源同一个Class文件，被同一个虚拟机所加载，但只要加载它们的ClassLoader实例对象不同，那么这两个类对象也是不相等的。

关于数组的类的加载

• 对于数组类而言，情况是不同的，数组类本身不通过类加载器创建，它是由于Java虚拟机直接在内存中动态构造出来，但是数组类与加载器仍是有很密切的关系，因为数组类的元素类型最终还是需要我们的类加载器去加载
  • 如果我们的数组的组件类型( new Person[10]的Person就是组件类型)是引用类型，那就依靠我们的类加载器去加载，但是数组将被标识在加载该组件类型的类加载器的类名称空间上
  • 如果我们的数组的组件类型不是引用类型，比如int []数组，Java虚拟机将会把数组本身标记为启动类加载器关联
  • 数组类的可访问性与它的组件类型的可访问性是一致的，如果组件类型不是引用类型，那么默认是public

对类加载器的引用

JVM必须知道一个类型是由启动加载器加载的还是由用户类加载器加载的。如果一个类型是由用户类加载器加载的，那么JVM会将这个类加载器的一个引用作为类型信息的一部分保存在方法区中。当解析一个类型到另一个类型的引用的时候，JVM需要保证这两个类型的类加载器是相同的。

链接

验证

• 验证是链接阶段的第一步，这一阶段的目的是为确保Class文件的字节流中包含的信息是符合《Java虚拟机规范》的全部约束条件，保证这些信息被当作代码运行之后不会危害虚拟机自身的安全
• 加载阶段与链接阶段（比如一部分的字节码文件格式的验证动作）是交叉进行的，加载阶段尚未完成，可能链接阶段已经开始，但是这些夹杂在加载阶段之中的进行的动作，仍然是属于链接的一部分
• 主要分为文件格式验证，元数据验证，字节码验证，符号引用验证

• 格式检查：比如开头是否以魔数开头 主次版本号是否被当前Java虚拟机支持 指向常量池的各种索引值中是否有指向不存在的常量或者不符合类型的常量等等，只有通过这些检查，这段字节流才能进入方法区进行存储
• 语义检查：这个类是否有父类 这个类是否继承了不允许被继承的类（被final修饰的类 ） 这个类是不是抽象类，是否实现了父类或者接口的所有抽象方法 类中的字段，方法是否与父类产生矛盾等等 这个阶段的目的主要对元数据信息进行语义校验
• 字节码验证：这个阶段主要目的是通过分析数据流和控制流分析，确定程序语义是合法的，符合逻辑的，这个阶段也就是对类中的方法体进行校验分析，保证类的方法运行的时候不会危害虚拟机
• 符号引用验证：符号引用验证的主要目的是确保解析行为能正常执行

准备

• • 为类变量分配内存并且设置该类变量（static）的默认初始值，即零值。
    • 从概念上来说，这些变量所使用的内存都应当在方法区中进行分配，但是必须注意到方法区本身就是一个逻辑上的区域，在JDK1.7之前，HotSpot使用永久代实现，而在JDK1.7之后，类变量则会随着Class对象一起存放在Java堆中，这时候类变量在方法区就完全是一种堆逻辑概念的表述了

• • 这里不包含用final修饰的static的ConstantValue属性，因为final在编译的时候就会分配了，准备阶段会显式初始化；

    • 同时使用final 、static来修饰的变量（常量），并且这个变量的数据类型是基本类型或者String类型，就生成ConstantValue属性来进行初始化。

      没有final修饰或者并非基本类型及String类型，则选择在方法中进行初始化。

• • 这里不会为实例变量分配初始化，类变量会分配在"方法区"中，而实例变量是会随着对象一起分配到Java堆中。

解析

• • 将常量池内的符号引用转换为直接引用的过程。
    • 符号引用就相当于在常量池里面的临时标识（局部变量）
    • 直接引用就是我们的直接内存地址类似的
• • 事实上，解析操作往往会伴随着JVM在执行完初始化之后再执行。
• • 符号引用就是一组符号来描述所引用的目标。符号引用的字面量形式明确定义在《java虚拟机规范》的Class文件格式中。直接引用就是直接指向目标的指针、相对偏移量或一个间接定位到目标的句柄。
• • 解析动作主要针对类或接口、字段、类方法、接口方法、方法类型等。对应常量池中的CONSTANT_Class_info，CONSTANT_Fieldref_info、CONSTANT_Methodref_info等。

初始化

类的初始化阶段是类加载过程的最后一个步骤

• 在进行准备阶段时，变量已经赋过一次系统要求的初始零值，而在我们的初始化阶段，则会根据程序员通过程序编码制定的主观计划去初始化类变量和其他资源

• 另一种表达方式，就是我们初始化阶段就是执行类构造器,这个构造器并不是程序员在Java代码中直接编写的方法，它是JavaC编译器的自动生成物

  • 是javac编译器自动收集类中的所有类变量的赋值动作和静态代码块中的语句合并而来。但是对于定义在它之后的静态变量，在前面的静态语句块可以赋值，但是不能访问

  • 构造器方法中指令按语句在源文件中出现的顺序执行。

  • 方法对于类或者接口来说不是必须的，如果一个类中没有静态语句块，也没有堆变量的赋值操作，那么编译器也不会生成这个()方法

• ()不同于类的构造器。（关联：构造器是虚拟机视角下的()）

• 若该类具有父类，JVM会保证子类的()执行前，父类的()已经执行完毕。

• 虚拟机必须保证一个类的()方法在多线程下被同步加锁。

类的初始化发生的时机

发生的时机

• 概括得说，类初始化是【懒惰的】

• main 方法所在的类，总会被首先初始化

• 首次访问这个类的静态变量或静态方法时

• 子类初始化，如果父类还没初始化，会引发

• 子类访问父类的静态变量，只会触发父类的初始化

• Class.forName

• new 会导致初始化

不会导致类初始化的情况

• 访问类的 static final 静态常量（基本类型和字符串）不会触发初始化
• 类对象.class 不会触发初始化
• 创建该类的数组不会触发初始化
• 类加载器的 loadClass 方法
• Class.forName 的参数 2 为 false 时

类加载器

Java虚拟机设计团队在设计有意把类加载阶段中的“通过一个类的全限定名来获取描述该类的二进制字节流这个动作”放到Java虚拟机外部实现，以便让应用程序自己决定如何去获取所需的类----实现这个动作的代码被称为类加载器

类与类加载器

类加载器虽然只用于实现类的加载动作，但它在Java程序中起到的作用却远超于类加载的阶段，对于任意一个类，都必须由加载它的类加载器和这个类本身一起共同确立其在Java虚拟机中唯一性，每一个类加载器，都拥有一个独立的类名称空间

• 这里的相等包括了类的Class对象的equals方法，isInstance()等方法的返回值

类加载器的分类

这里的四者之间的关系是包含关系。不是上层下层，也不是子父类的继承关系。

JVM支持两种类型的类加载器 。分别为引导类加载器（Bootstrap ClassLoader）这种是由C++语言实现的，是虚拟机的一部分和自定义类加载器（User-DefinedClassLoader）。这种类加载器都由Java语言实现，独立于虚拟机外部，并且全部继承自抽象类java.lang.ClassLoader

从概念上来讲，自定义类加载器一般指的是程序中由开发人员自定义的一类类加载器，但是Java虚拟机规范却没有这么定义，而是将所有派生于抽象类ClassLoader的类加载器都划分为自定义类加载器。

但是站在我们Java开发程序员的角度来看，类加载器的划分应当划分的更细致一些，也是为了实现我们的双亲委派机制

Java虚拟机自带的类加载器

启动类加载器（引导类加载器，Bootstrap ClassLoader）

• 这个类加载使用C/C++语言实现的，嵌套在JVM内部。

• 它用来加载Java的核心库（JAVA_HOME/jre/lib/rt.jar、resources.jar或sun.boot.class.path路径下的内容），用于提供JVM自身需要的类

• 并不继承自ava.lang.ClassLoader，没有父加载器。

• 加载扩展类和应用程序类加载器，并指定为他们的父类加载器。

• 出于安全考虑，Bootstrap启动类加载器只加载包名为java、javax、sun等开头的类

package cn.itcast.jvm.t3.load;
public class F {
	static {
		System.out.println("bootstrap F init");
	}
}
1
2
3
4
5
6

package cn.itcast.jvm.t3.load;
public class Load5_1 {
	public static void main(String[] args) throws ClassNotFoundException {
		Class<?> aClass = Class.forName("cn.itcast.jvm.t3.load.F");
		System.out.println(aClass.getClassLoader());
	}
}
// 加的命令 E:\git\jvm\out\production\jvm>java -Xbootclasspath/a:.cn.itcast.jvm.t3.load.Load5
//输出
bootstrap F init
null
1
2
3
4
5
6
7
8
9
10
11

Xbootclasspath 表示设置 bootclasspath
其中 /a:. 表示将当前目录追加至 bootclasspath 之后
可以用这个办法替换核心类

• java -Xbootclasspath:
• java -Xbootclasspath/a:<追加路径>
• java -Xbootclasspath/p:<追加路径>

扩展类加载器（Extension ClassLoader）

• Java语言编写，由sun.misc.Launcher$ExtClassLoader实现。

• 派生于ClassLoader类

• 父类加载器为启动类加载器

• 从java.ext.dirs系统属性所指定的目录中加载类库，或从JDK的安装目录的jre/1ib/ext子目录（扩展目录）下加载类库。如果用户创建的JAR放在此目录下，也会自动由扩展类加载器加载。

应用程序类加载器（系统类加载器，AppClassLoader）

• java语言编写，由sun.misc.LaunchersAppClassLoader实现

• 派生于ClassLoader类

• 父类加载器为扩展类加载器

• 它负责加载环境变量classpath或系统属性java.class.path指定路径下的类库

• 该类加载是程序中默认的类加载器，一般来说，Java应用的类都是由它来完成加载

• 通过ClassLoader.getSystemclassLoader() 方法可以获取到该类加载器

public class ClassLoaderTest {
    public static void main(String[] args) {

        //获取系统类加载器
        ClassLoader systemClassLoader = ClassLoader.getSystemClassLoader();
        System.out.println(systemClassLoader);//sun.misc.Launcher$AppClassLoader@18b4aac2

        //获取其上层：扩展类加载器
        ClassLoader extClassLoader = systemClassLoader.getParent();
        System.out.println(extClassLoader);//sun.misc.Launcher$ExtClassLoader@1540e19d

        //获取其上层：获取不到引导类加载器
        ClassLoader bootstrapClassLoader = extClassLoader.getParent();
        System.out.println(bootstrapClassLoader);//null

        //对于用户自定义类来说：默认使用系统类加载器进行加载
        ClassLoader classLoader = ClassLoaderTest.class.getClassLoader();
        System.out.println(classLoader);//sun.misc.Launcher$AppClassLoader@18b4aac2

        //String类使用引导类加载器进行加载的。---> Java的核心类库都是使用引导类加载器进行加载的。
        ClassLoader classLoader1 = String.class.getClassLoader();
        System.out.println(classLoader1);//null


    }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

用户自定义类加载器

在Java的日常应用程序开发中，类的加载几乎是由上述3种类加载器相互配合执行的，在必要时，我们还可以自定义类加载器，来定制类的加载方式。 为什么要自定义类加载器？

• 隔离加载类

• 修改类加载的方式

• 扩展加载源

• 防止源码泄漏

用户自定义类加载器实现步骤：

1. 开发人员可以通过继承抽象类ava.lang.ClassLoader类的方式，实现自己的类加载器，以满足一些特殊的需求
2. 在JDK1.2之前，在自定义类加载器时，总会去继承ClassLoader类并重写loadClass() 方法，从而实现自定义的类加载类，但是在JDK1.2之后已不再建议用户去覆盖loadclass() 方法，而是建议把自定义的类加载逻辑写在findClass()方法中
3. 在编写自定义类加载器时，如果没有太过于复杂的需求，可以直接继承URLClassLoader类，这样就可以避免自己去编写findClass() 方法及其获取字节码流的方式，使自定义类加载器编写更加简洁。

• 继承 ClassLoader 父类
• 要遵从双亲委派机制，重写 findClass 方法
  注意不是重写 loadClass 方法，否则不会走双亲委派机制
• 读取类文件的字节码
• 调用父类的 defineClass 方法来加载类
• 使用者调用该类加载器的 loadClass 方法

ClassLoader的使用说明

ClassLoader类是一个抽象类，其后所有的类加载器都继承自ClassLoader（不包括启动类加载器）

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-hiLbapBE-1668965214029)(https://www.yuque.com/api/filetransfer/images?url=https%3A%2F%2Fgitee.com%2Fvectorx%2FImageCloud%2Fraw%2Fmaster%2Fimg%2F20210507212318.png&sign=130be0176a03cf690be978a05c1eef52958ffc5a09b5f7ab83fe7c13f582b0af)]

获得类加载器的途径

public class ClassLoaderTest2 {
    public static void main(String[] args) {
        try {
            //1.获取当前ClassLoade
            ClassLoader classLoader = Class.forName("java.lang.String").getClassLoader();
            System.out.println(classLoader);
            //2.获取当前线程上下文的ClassLoader 
            ClassLoader classLoader1 = Thread.currentThread().getContextClassLoader();
            System.out.println(classLoader1);

            //3.获取系统的ClassLoader 
            ClassLoader classLoader2 = ClassLoader.getSystemClassLoader().getParent();
            System.out.println(classLoader2);
            //方式四：获取调用者的ClassLoader 
            DriverManager.getCallerClassLoader()

        } catch (ClassNotFoundException e) {
            e.printStackTrace();
        }
    }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

双亲委派机制

Java虚拟机对class文件采用的是按需加载的方式，也就是说当需要使用该类时才会将它的class文件加载到内存生成class对象。而且加载某个类的class文件时，Java虚拟机采用的是双亲委派模式，即把请求交由父类处理，它是一种任务委派模式。

工作流程

• 1）如果一个类加载器收到了类加载请求，它并不会自己先去加载，而是把这个请求委托给父类的加载器去执行；

• 2）如果父类加载器还存在其父类加载器，则进一步向上委托，依次递归，请求最终将到达顶层的启动类加载器；

• 3）如果父类加载器可以完成类加载任务，就成功返回，倘若父类加载器无法完成此加载任务，子加载器才会尝试自己去加载，这就是双亲委派模式。

优势

• 避免类的重复加载

• 保护程序安全，防止核心API被随意篡改

• • 自定义类：java.lang.String
• • 自定义类：java.lang.ShkStart（报错：阻止创建 java.lang开头的类）

• /**
   * @author shkstart
   * @create 2020 上午 11:40
   */
  public class String {
      //
      static{
          System.out.println("我是自定义的String类的静态代码块");
      }
      //错误: 在类 java.lang.String 中找不到 main 方法
      public static void main(String[] args) {
          System.out.println("hello,String");
      }
  }
  //输出结果 因为我们用启动类加载器加载了我们的核心类库中的String类，导致不能加载我们自己写的String类
  错误: 在类 java.lang.String 中找不到 main 方法, 请将 main 方法定义为:
     public static void main(String[] args)
  否则 JavaFX 应用程序类必须扩展javafx.application.Application
  
  1
  2
  3
  4
  5
  6
  7
  8
  9
  10
  11
  12
  13
  14
  15
  16
  17
  18
  19

• public class ShkStart {
  
      public static void main(String[] args) {
          System.out.println("hello!");
      }
  }
  //输出结果 保护了我们的程序安全，防止修改核心API
  java.lang.SecurityException: Prohibited package name: java.lang
  1
  2
  3
  4
  5
  6
  7
  8

沙箱安全机制

自定义String类，但是在加载自定义String类的时候会率先使用引导类加载器加载，而引导类加载器在加载的过程中会先加载jdk自带的文件（rt.jar包中java\lang\String.class），报错信息说没有main方法，就是因为加载的是rt.jar包中的string类。这样可以保证对java核心源代码的保护，这就是沙箱安全机制。

类文件的结构

无关性基石

• 实现一次编译到处运行的基础是字节码，也是我们的class文件

• Java也想实现语言无关性，Java虚拟机不与任何Java语言在内的任何程序语言绑定，它只与Class 文件这种特定二进制文件所关联，比如Kotlin也能在Java虚拟机运行