01-​JVM学习记录-类加载器

 一、类加载器子系统

1. 作用-运输工具（快递员）

• 负责从文件系统或者网络中加载Class文件（DNA元数据模板），Class文件开头有特定标识，魔术，咖啡杯壁（class文件存于本地硬盘，JVM根据class实例化）DNA元数据模板

• Classloader只负责class文件的加载，至于是否可运行，则由执行引擎决定

• 加载的类信息存放于称为方法区的内存空间，除了类信息，方法区还会存放运行时常量池信息，还可能包括字符串字面量和数字常量（常量池运行时加载到内存中，即运行时常量池）

2. 类的加载过程

加载——链接（验证、准备、解析）——初始化

解析阶段不一定，在某些情况下可以在初始化阶段之后再开始，为了支持Java语言的运行时绑定特性（也称为动态绑定或晚期绑定）。

2.1 加载

加载是类加载过程的一个阶段，注意区分

        1. 通过一个类的全限定名获取定义此类的二进制字节流

加载class文件的方法：

• 本地系统直接加载

• 网络获取，Web Applet

• zip压缩包获取，jar，war

• 运行时计算生成，动态代理

• 有其他文件生成，jsp

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

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

        2. 将这个字节流所代表的的静态存储结果转化为方法区的运行时数据结构

        3. 在内存中生成一个代表这个类的java.lang.Class对象，作为方法区这个类的各种数据访问入口

2.2 链接

2.2.1 验证：确保Class文件的字节流中包含信息符合当前虚拟机要求，保证被加载类的正确性，不会危害虚拟机自身安全

四种验证：

• 文件格式验证

        CA FE BA BE(魔数，Java虚拟机识别)

        主次版本号

        常量池的常量中是否有不被支持的常量类型

        指向常量的各种索引值中是否有指向不存在的常量或不符合类型的常量

• 元数据验证

        对字节码描述的信息进行语义分析，保证描述符合Java规范

        类是否有父类，除了Object之外，所有的类都应该有父类

        类的父类是否继承了不允许被继承的类（被final修饰的类）

        如果这个类不是 抽象类，是否实现了其父类或接口中要求实现的所有方法。

        类的字段，方法是否与父类的产生矛盾。例如方法参数都一样，返回值不同

• 字节码验证

        通过数据流分析和控制流分析，确定程序语义是合法的，符合逻辑的。

        对类的方法体，进行校验分析，保证在运行时不会做出危害虚拟机的行为

        保证任意时刻操作数栈的数据类型与指令代码序列都能配合工作，不会出现类似于在操作数栈放了一个int类型的数据，使用时却按照long类型加载到本地变量表中的情况。

        保障任何跳转指令都不会跳转到方法体之外的字节码指令上。

• 符号引用验证

通过字符串描述的全限定名是否能找到对应的类

符号引用中的类、字段、方法的可访问性是否可被当前类访问

2.2.2 准备：为类变量分配内存，并且设置该类变量的初始值，即零值

不包含用final修饰的static（常量），在编译的时候就会分配了，准备阶段会显示初始化

不会为实例变量分配初始化（还没创建对象），类变量会分配在方法区中，实例变量会随着对象一起分配到Java堆中

2.2.3 解析

• 解析操作往往会伴随着JVM在执行完初始化之后再执行

• 将常量池内的符号引用转换为直接引用的过程。符号引用就是一组符号来描述引用的目标。符号引用的字面量形式明确定义在Java虚拟机规范的Class文件格式中。直接引用就是直接指向目标的指针，相对偏移量或一个间接定位到目标的句柄

• 解析动作主要针对类，或接口，字段，类方法，接口方法，方法类型等。对应常量池中的CONSTANT_Class_info、CONSTANT_Fieldref_info、CONSTANT_Methodref_info

符号引用是用符号（如类名，方法名，字段名等）来描述所引用的对象，而直接引用是用具体的内存地址或指针来指向所引用的对象。符号引用在编译阶段就存在，但是需要在运行时通过类加载器解析成直接引用。直接引用在运行时才存在，它可以直接定位到内存中的目标。直接引用的效率要比符号引用高。 

2.3 初始化

        初始化阶段是执行类构造器方法<clinit>()的过程，此方法不需要定义，是javac编译器自动收集类中的所有类变量的赋值动作和静态代码块中的语句合并而来。如果没有类变量和静态代码块，也不会有clinit。构造器方法中指令按照语句在源文中出现的顺序执行。

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

• 非法的前向引用：可以在static中对number先赋值，再声明，但不能先调用。

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

• 虚拟机必须保证一个类的<clinit>()方法在多线程下被同步加锁，只被执行一次

• Java虚拟机规范严格规定了，有且只有六种情况，必须立即对类进行初始化，其他使用类的方式被看做是对类的被动使用，都不会导致类的初始化

1、遇到new,getstatic，putstatic或invokestatic这四条字节码指令时。

        使用new关键字实例化对象

        读取或设置一个类型的静态字段（final修饰已在编译期将结果放入常量池的静态字段除外）

        调用一个类型的静态方法的时候

2、对类型进行反射调用，如果类型没有经过初始化，则需要触发初始化

3、初始化类的时候，发现父类没有初始化，则先触发父类初始化

4、虚拟机启动时，用户需要指定一个要执行的主类（包含main方法的那个类），虚拟机会初始化这个主类

5、只用JDK7中新加入的动态语言支持，如果一个java.lang.invoke.MethodHandler实例最后的解析结果为REF_getStatic,REF_putStatic,REF_invokeStatic，REF_newInvokeSpecial四种类型的方法句柄，并且这个方法对应的类没有进行初始化，则先触发其初始化

6、当一个接口中定了JDK8新加入的默认方法时，如果这个接口的实现类发生了初始化，要先将接口进行初始化

3. 类加载器分类

        分为引导（启动）类加载器和自定义加载器（所有派生于抽象类ClassLoader的类加载器都划分为自定义加载器，扩展类加载器和系统类加载器属于自定义加载器）。

• 引导类加载器返回null，获取不到（因为是c/c++写的），系统的核心类库都是用引导类加载器。

• 自定义类加载器默认使用系统类加载器

3.1 引导类加载器

• C/C++语言实现，嵌套JVM内部，用来加载Java核心类库，rt.jar、resources.jar、sun.boot.class.path路径下的内容。

• 并不继承java.lang.ClassLoader，没有父加载器，是扩展类和应用程序类加载器的父加载器。

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

3.2 扩展类加载器

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

• 派生于ClassLoader类

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

• 从java.ext.dirs系统属性所指定的目录中加载类库，或从jre/lib/ext子目录下加载类库。如果用户创建的jar放在此目录下，自动由扩展类加载器加载。

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

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

• 派生于ClassLoader类

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

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

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

• 通过ClassLoader#getSystemClassLoader（）方法可以后去到类加载器

3.4 用户自定义类加载器

3.4.1 为什么要用自定义类加载器？

• 隔离加载类：例如使中间件的Jar包与应用程序Jar包不冲突

• 修改类加载的方式：启动类加载器必须使用，其他可以根据需要自定义加载

• 扩展加载源

• 防止源码泄露：对字节码进行加密，自定义类加载器实现解密

3.4.2 实现步骤

• 继承抽象类java.lang.ClassLoader类的方式，实现自己的类加载器

• jdk1.2之前，继承并重写loadClass方法；jdk1.2之后，建议把自定义的类加载逻辑写在findClass()方法中

  

  

• 如果没有太过复杂的需求，可以直接继承URLClassLoader类，可以避免自己编写findClass（）方法，及其获取字节码流的方式，使自定义类加载器编写更加简洁

3.5 ClassLoader

抽象类，除了启动类加载器，其他类加载器都继承于此。

findClass方法中调用defineClass方法，搭配使用。

获取ClassLoader的途径：

4. 双亲委派机制

1. 一种任务委派模式：

JVM对Class文件采用的是按需加载（需要使用该类时才将它的class文件加载到内存生成class对象），而且加载class文件时，Java虚拟机使用的是双亲委派模式，即把请求交由父类处理。

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

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

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

例：如果我自定义了一个包java.lang，写了一个String类，默认是系统类加载器，我在其他类的静态代码块使用String，加载时不会加载我写的String类，依然是引导类加载器，因为引导类加载器是系统类加载器的父加载器（扩展类加载器）的父加载器，且可以完成这个加载任务。

2. 优势

• 避免类的重复加载

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

3. 沙箱安全机制

• 保证对Java核心源代码的保护

 例：360沙箱，将一些东西（U盘、病毒）限制在沙箱区域里运行，不会影响电脑的其他程序。

5. 类的主动使用和被动使用

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

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

• 加载这个类的ClassLoader必须相同

即使两个类对象来源于同一个class文件，被同一个JVM加载，只要加载它们的ClassLoader实例对象不同，这两个类对象也不相等。

JVM必须知道一个类型是由启动类加载器加载的，还是由用户类加载器加载的。如果是用户类加载器加载的，JVM会将这个类加载器的一个引用作为类型信息的一部分，保存到方法区中。

参考：b站尚硅谷-宋少康