JVM（二）类装载器子系统

1.类的加载

虚拟机类装载器子系统：虚拟机把描述类的数据从class文件加载到内存，并对数据进行校验、转换解析和初始化，最终形成可以被虚拟机直接使用的Java类型。

类的加载指的是将类的.class文件中的二进制数据读到内存中，将其放在运行时数据区的方法区内，然后在堆区创建一个java.lang.Class对象。类加载的最终产品是位于堆区中的Class对象，Class对象封装了类在方法区内的数据结构，并且向Java程序员提供了访问方法区内的数据结构的接口。

类加载结构

类加载并不需要等到某个类被"首次主动使用"时再加载它，JVM规范允许类加载器在预料某个类将要被使用时就预先加载它，如果在预先加载的过程中遇到了.class文件缺失或存在错误，类加载器必须在程序首次主动使用该类时才报告错误。如果类没被使用。那么类加载器就不会报告错误。

加载.class文件的方式

1.从本地系统中直接加载

2.通过网络下载的.class文件

3.从zip，jar等归档文件中加载.class文件

4.从专有数据库中提取.class文件

5.将Java源文件动态编译为.class文件

2.类的生命周期

类从被加载到虚拟机内存中开始，到卸载出内存为止，它的整个生命周期包括：加载、连接（验证、准备、解析）、初始化、使用、卸载

类生命周期

什么时候触发类加载？

1.使用new关键字实例化对象

2.读取或设置一个类的静态变量的时候

3.调用类的静态方法的时候

4.对类进行反射调用的时候

5.初始化子类时，父类会先被初始化

6.对类使用动态代理的时候需要先被初始化

3.类加载过程

类的加载、验证、准备、初始化这四个阶段发生的顺序是确定的。而解析阶段则不一定。它在某些情况下可以在初始化阶段之后开始，这是为了支持Java语言的运行时绑定（也称为动态绑定或晚期绑定）。另外注意这里的几个阶段是按顺序开始，而不是按顺序进行或完成。因为这些阶段通常都是互相交叉地混合进行的，通常在一个阶段执行的过程中调用或激活另一个阶段。

Java中的绑定是指把一个方法的调用与方法所在的类（方法主体）关联起来，对Java来说分为静态绑定和动态绑定。

静态绑定：即前期绑定，在程序执行前方法已经被绑定，此时由编译器或其他连接程序实现。针对Java，简单的可以理解为程序编译期的绑定。java中的方法只有final,static,private和构造方法是前期绑定的。

动态绑定：即晚期绑定，也叫运行时绑定的。在运行时根据具体对象的类型进行绑定，在java只能够几乎所有的方法都是后期绑定的。

4.加载

类加载工作

4.1加载过程

加载时类加载过程的第一个阶段，虚拟机完成以下三件事情：

1.通过类全限定名来获取.class文件的二进制字节流，是可控性最强的阶段（class文件、Jar包、网络中的Applet、JSP）

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

3.在Java堆中生成一个代表这个类的java.lang.Class对象，作为对方法区中这些数据的访问入口。

4.2类加载机制

全盘负责：当一个类加载器负责加载某个Class时，该Class所依赖的和引用的其他Class也将由该类加载器负责载入，除非显式使用另外一个类加载器来载入。
父类委托：先让父加载器视图加载类，只有在父加载器无法加载该类时才会尝试从自己的类路径中加载该类。
缓存机制：将会保证所有加载过的Class都会被缓存，只有缓存区不存，系统才会读取该类对应的二进制数据，并将其转换成Class对象。这就是为什么修改了Class后，必须重启JVM，修改才会生效。

4.3类加载器

对于任意一个类，都需要由它的类加载器和这个类本身一同确定在JVM中的唯一性。也就是说，及时两个类来源于同一个Class文件，只要家在他们的类加载器不同，那么这两个类就必定不相等。这里的"相等" Class对象的equals(),isAssignableFrom(),isInstance()等方法的返回结果，也包括了使用instanceof关键字对对象所属关系的判定结果。

站在虚拟机角度，只存在两种不同的类加载器：

1.启动类加载器：C++实现（HotSpot中，也有其他虚拟机是用Java语言实现的），是虚拟机自身的一部分。
2.其他的类加载器：这些类加载器都有Java语言实现，独立于虚拟机之外，并且全部继承自抽象类java.lang.ClassLoader,这些类加载器需要由启动类加载器加载到内存中之后才能去加载其他的类。

站在Java开发人员角度，类加载器可以大致分为三类：

1.启动类加载器（Bootstrap ClassLoader）：负责将%JAVA_HOME%/lib路径下的核心类库或-Xboot/classpath参数指定的路径下的jar包加载到内存中，并且能被虚拟机识别的类库（如rt.jar 所有java.*开头的类均被Bootstrap ClassLoader加载）。启动类加载器是无法被Java程序直接引用的。启动类加载器主要加载的是JVM自身需要的类。
2.扩展类加载器（Extension ClassLoader）：该加载器由sun.misc.Launcher $ExtClassLoader实现，他负责加载JDK\jre\lib\ext目录中，或者有java。ext.dirs系统变量指定的路径中的所有类库（如javax.*开头的类），开发者可以直接使用扩展类加载器。 3.应用程序类加载器（Application ClassLoader）：该类加载器有sun.misc.Launcher$ AppClassLoader来实现。他负责加载用户类路径（ClassLoader）所指定的类，一般情况下这个就是程序中默认的类加载器。
4.自定义类加载器（Custom ClassLoader）：如果编写了自己的ClassLoader，便可以做到以下几点：
- 1.在执行费置信代码之前，自动验证数字签名。
- 2.动态地创建符合用户特定需要的定制化构建类。
- 3.从特定的场所去的java class ，例如数据库中和网络中。

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

4.4双亲委派模型

双亲委派模型的意义：

带有优先级的层次关系，通过这种层级关系可以避免类重复加载。
保证Object类在程序中各种类加载器中都是同一个类。
保证java程序安全稳定运行,假设通过网络传递一个名为java.lang.Integer的类，未通过双亲委派就加载了这个类，这样核心API就会被篡改。

双亲委派模型

工作流程
双亲委派模型的工作流程是：如果一个类加载器收到了类加载的请求，他首先不会自己去尝试加载这个类，而是把请求委托给父加载器。依次向上，因此所有类加载请求最终都应该被传递到顶层的启动类加载器中，只有当父加载器在它搜索范围中没有找到所需要的类时，子加载器才会尝试自己去加载该类。如果均加载失败，就会抛出ClassNotFoundException异常。

5.验证

验证的目的是为了确保Class文件中字节流包含的信息符合当前虚拟机的要求，而且不会危害虚拟机自身安全。
不同虚拟机对类验证的实现可能有所不同，但大致都会完成以下四个阶段的验证。

文件格式的验证:验证字节流是否符合Class文件格式的规范，并且能被当前版本虚拟机处理。经过验证后，字节流才会进入内存方法区中存储，后面的三个验证都是基于方法区的存储结构进行的。
2.元数据验证:对类的元数据信息进行语义校验，保证不存在不符合Java语法规范的元数据信息。
3.字节码验证:该阶段验证的主要工作是数据流和控制流分析。对类的方法体进行校验分析。防止方法在运行时做出危害虚拟机的行为。
4.符号引用验证:最后一个阶段的验证，发生在虚拟机将符号引用转化为直接引用的时候（解析阶段中发生该转化）主要是对类自身以外的信息进行匹配性校验。

6.准备

准备阶段是正式为类变量分配内存并设置类变量初始值阶段，这些内存都将在方法区中分配。

1.这时候进行内存分配的仅包括类变量（static）分配在方法区中，而不包含实例变量，实例变量会在对象实例化时随着对象一块分配在JAVA堆中。

2.这时候所设置的初始值通常情况下是数据类型默认的零值（如0,0L,null,false等），而不是在Java代码中被显示地赋予的值（初始化阶段才会执行）

3.如果类字段的属性存在常量（ConstantValue），即同时被static final修饰，那么在准备阶段变量value就会被初始化为常量所指定的值。

下表列出了Java中所有基本数据类型以及reference类型的默认零值

默认零值

需要注意以下几点：

对基本数据类型来说，类变量和全局变量，如果不显式地对其赋值而直接使用，则系统会为其赋予默认的零值。而对于局部变量来说，在使用前必须显式地赋值，否则编译不通过。
对于同时被static和final修饰的常量，必须在声明的时候就为其显式的赋值，否则编译不通过。
对于只被final修饰的常量则既可以在声明时显式地为其赋值，也可以在类初始化时显式地为其赋值。总之，在使用前必须为其显式地赋值，系统不会为其赋予默认零值。
对于引用数据类型reference来说，如数组引用对象引用等，如果没有对其进行显式地赋值，系统会为其赋予零值即null。如果在数组初始化时没有对数组中各元素赋值，那么元素将根据对应的数据类型而被赋予默认的零值。

7.解析

解析动作主要针对接口、字段、类方法、接口方法四类符号引用进行，分别对应常量池中的CONSTANT_Class_info,CONSTANT_Fieldref_info,CONSTANT_Methodref_info,CONSTANT_InterfaceMethodref_info四种常量类型。

1.类或接口的解析：判断所要转化成的直接引用是对数组类型，还是普通的对象引用，从而进行不同解析

2.字段解析：对字段进行解析时，会现在本类中查找是否包含有简单名称和字段描述符斗鱼目标相匹配的字段，如果有，则查找结束。如果没有，则会按照继承关系从上往下递归搜索该类所实现的各个接口和它们的父接口。还没有，则按照继承关系从上往下递归搜索其父类，直至查找结束。

字段解析流程

3.类方法解析：对类方法的解析与对字段解析的搜索步骤差不多，只是多了判断该方法所处的是类还是接口的步骤，而且对类方法匹配搜索，是先搜索父类，再搜索接口。

4.接口方法解析：与类方法解析步骤类似，只是接口不会有父类，因此只递归向上搜索父接口就行了。

8.初始化

初始化是类加载过程的最后一步，到了此阶段，才真正开始执行类中定义的Java程序代码。在准备阶段，类变量（static）已经被赋过一次系统要求的初始值，而在初始化阶段，则是根据程序员通过程序指定的主观计划去初始化类变量和其他资源，或者可以从另一个角度来表达：初始化阶段是执行类构造器<clinit>()方法的过程。

8.1clinit()方法的执行规则

1.<clinit>()方法是由编译器自动收集类中的所有类变量的赋值动作和静态语句块中的语句合并产生的，编译器收集的顺序是由语句在源文件中出现的顺序所决定的，静态语句块中只能访问到定义在静态语句块之前的变量，定义在它之后的变量，在前面的静态语句中可以赋值，但是不能访问。

2.<clinit>()方法与实例构造器<init>()（类的构造函数）方法不同，它不需要显式地调用父类构造器，虚拟机惠保证在子类的<clinit>()方法执行之前，父类的<clinit>()方法已经执行完毕。因此，在虚拟机中第一个被执行的<clinit>()方法肯定是java.lang.Object

3.<clinit>()方法对于类或接口来说并不是必须的，如果一个类中没有静态语句块，也没有对类变量的赋值操作，那么编译器不为这个类生成<clinit>()方法。

4.接口中不能使用静态语句块（JDK1.8之后有静态方法），但仍然有类变量（final static）初始化的赋值操作，因此接口也会生成<clinit>()方法。

5.虚拟机会保证一个类的<clinit>()方法在多线程环境中被正确的加锁和同步，如果多个线程同时去初始化一个类，那么只会由一个线程去执行这个类的<clinit>()方法，其他线程都需要阻塞等待，直到活动线程执行完<clinit>()方法。

8.2类进行初始化情况

8.2.1主动引用
虚拟机规范严格规定了有且只有四种情况必须立即对类进行初始化：

1.遇到new、getstatic、putstatic\invokestatic这四条字节码指令时，如果类还没有进过初始化，则需要先出发其初始化。生成这四条指令最常见的Java代码场景是：
1)使用new关键字实例化对象
2)读取或设置一个类的静态字段(static)时（static final除外，已在编译期把结果放入常量池的静态字段除外），以及调用一个类的静态方法时。

2.使用Java.lang.refect包的方法对类进行反射调用时，如果类还没有进行初始化，则需要先初始化。

3.当初始化一个类时，如果发现其父类没有进行初始化，则需要先触发其父类的初始化。

4.当虚拟机启动时，用户需要指定一个要执行的主类，虚拟机会先执行该主类的初始化。

虚拟机规定只有这四种情况才会触发类的初始化，称为对一个类进行主动引用，除此之外所有引用类的方式都不会触发其初始化，称为被动引用。

8.2.2被动引用
下面据一些例子来说明被动引用

1.通过子类引用父类中的静态字段，这时对子类的引用为被动引用，因此不会初始化子类，只会初始化父类。对于静态字段，只有直接定义这个字段的类才会被初始化。

2.常量在编译阶段会存入调用它的类的常量池中，本质上没有直接引用到定义该常量的类，因此不会触发定义常量的类的初始化。

3.通过数组定义来引用类，不会触发类的初始化。

8.2.3类的实例化顺序

1.勒种的static代码在类加载时就执行，且只执行这一次。（先静态）

2.如果类A继承了类B 在类A实例化时要先加载实例化类B（先父后子）

3.类实例化要先实例化成员变量（非静态），在执行构造函数（先成员后构造）

9.结束

在如下几种情况JVM将结束生命周期

1.执行了System.exit(0)方法

2.程序正常执行结束

3.程序再执行过程中遇到了异常或错误而异常终止

4.由于操作系统出现错误而导致JVM虚拟机进程终止

10.程序中的类加载

类加载有三种方式：

1.启动应用时，由JVM初始化加载

2.通过Class.forName()方法动态加载

3.通过ClassLoader.loadClass()方法动态加载

 public static void main(String args[]) {
    ClassLoader loader = HelloWorld.class.getClassLoader();
    System.out.println(loader);
    //使用ClassLoader.loadClass来加载类，不会执行初始化块。
    loader.loadClass("Test2");
    


}