JVM类加载机制

给大家推荐个靠谱的公众号程序员探索之路，大家一起加油

JVM类加载机制

类加载的生命周期

JVM加载类到内存中从开始到卸载，整个生命周期包括：加载(Loading)，验证(Verification)，准备(Preparation),解析(Resolution)，初始化(Initiallization)，使用(Using)，卸载(Unloading)这7个阶段，其中验证，准备，解析3各部分称为连接(Linking)。图例：

其中，加载/验证/准备/初始化/卸载这5个阶段的顺序是确定的，类的加载过程必须按照这种顺序按部就班地开始，而解析阶段不一定：他在某些情况下可以初始化阶段之后再开始，这是为了支持java语言的运行时绑定（也称为动态绑定）。接下来讲解加载，验证，准备，解析，初始化五个步骤组成一个完整的类加载过程。

加载Loading

加载是类加载的第一个阶段。有两种时机触发类加载。通过设置-XX:+TraceClassLoading可以看到类加载信息

加载阶段做的事情

1. 获取class文件的二进制流
2. 将类信息，静态变量，字节码，常量这些class文件中的内容放入方法区中
3. 在内存中生成一个代表这个class文件的java.lang.class对象，作为方法区这个类的各种数据的访问入口，一般这个class是在堆里的，不过HotSpot虚拟机比较特殊，这个class对象时放在方法区

JVM规范对这三点的要求并不具体，因此JVM实现与具体应用的灵活度都是相当大的。例如获取class文件的二进制流要从哪里来就可以有很多方式：从zip/jar/war/ear包中；从网络中，典型应用就是Applet；运行时计算生成，典型应用就是动态代理技术；有其他文件生成，典型应用就是JSP，即由JSP生成对应的class文件；从数据库中读取；

 

JVM启动时加载，会加载JAVA_HOME/lib/下的rt.jar下的class文件，这个jar包里面的内容是程序运行时非常常用的,像java.lang.*,java.util.*,java.io.*等等,因此随着JVM一起加载。

设置上-XX:+TraceClassLoading参数，启动程序就可以看到

E:\Java\jdk1.8.0_144\bin\java -agentlib:jdwp=transport=dt_socket,address=127.0.0.1:52552,suspend=y,server=n -XX:+TraceClassLoading -javaagent:C:\Users\ecidi\.IntelliJIdea2017.2\system\groovyHotSwap\gragent.jar -Dfile.encoding=UTF-8 -classpath C:\Users\ecidi\AppData\Local\Temp\classpath107584.jar com.ecidi.dam.web.rest.fileupload.UploadOrFindImg

[Opened E:\Java\jdk1.8.0_144\jre\lib\rt.jar]

[Loaded java.lang.Object from E:\Java\jdk1.8.0_144\jre\lib\rt.jar]

[Loaded java.io.Serializable from E:\Java\jdk1.8.0_144\jre\lib\rt.jar]

[Loaded java.lang.Comparable from E:\Java\jdk1.8.0_144\jre\lib\rt.jar]

[Loaded java.lang.CharSequence from E:\Java\jdk1.8.0_144\jre\lib\rt.jar]

[Loaded java.lang.String from E:\Java\jdk1.8.0_144\jre\lib\rt.jar]

[Loaded java.lang.reflect.AnnotatedElement from E:\Java\jdk1.8.0_144\jre\lib\rt.jar]

[Loaded java.lang.reflect.GenericDeclaration from E:\Java\jdk1.8.0_144\jre\lib\rt.jar]

[Loaded java.lang.reflect.Type from E:\Java\jdk1.8.0_144\jre\lib\rt.jar]

[Loaded java.lang.Class from E:\Java\jdk1.8.0_144\jre\lib\rt.jar]

………………………………………………………………………………………..

当JVM在用到一个class文件的时候，会先去内存中查看这个class文件有没有被加载，如果没有就会按照类的全限定名来加载这个类。

加载和连接阶段的部分内容（如果一部分字节码文件格式验证动作）是交叉进行的，加载阶段尚未完成，连接阶段可能已经开始，但这些夹在加载阶段之中进行的动作，仍然属于连接阶段的内容，这两个阶段的开始时间仍然保持着固定的先后顺序。

验证

连接阶段的第一步，这一阶段的目的是确保class文件的字节流中包含的信息符合当前JVM的要求，并且不会危害JVM自身的安全。

JAVA是相对安全的语言（相对C/C++而言），但是在加载阶段class文件不一定要从JAVA源码编译而来，甚至可以用十六进制的编译器产生class文件。在字节码语言层面上，JAVA代码至少从语义上是可以表达出来的。JVM如果不检查输入的字节流，对其完全信任的话，很可能会因为载入了有害的字节流而导致系统崩溃，所以验证是JVM对自身保护的一项重要工作。

验证做的事情

1. 文件格式验证

1.1是否以魔数0xCAFEBABE开头

1.2主次版本号是否在当前虚拟机处理范围之内

Class文件会记录主次版本号，验证的时候会对版本号做校验。高版本的JDK能向下兼容以前版本的class文件，但是不能运行以后的class文件，即使文件格式未发生任何变化，虚拟机也必须拒绝执行超过其版本号的class文件。例如：在JDK1.6生成的class文件，在JDK1.7可以运行，但是JDK1.5无法运行，如果运行将抛出java.lang.UnsupportedClassVersionError。

1.3常量池的常量中是否有不被支持的常量类型（检查常量tag标志）

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

1.5CONSTANT_Utf8_info型的常量中是否有不符合UTF8编码的数据

1.6Class文件名中各个部分及文件本身是否有被删除的或附加的其他信息

。。。。。。。。。。。。。。后续还有很多验证，但是这一步的目的是保证输入的字节流能正确地解析并存储于方法区之内，格式上符合描述一个JAVA类型信息地要求。

1. 元数据验证

这一步地目的是对字节码描述地信息进行语义分析，以保证其描述地信息符合JAVA语言规范地要求。官方的话就是：对类的元数据信息进行语义校验，保证不存在不符合java语言规范的元数据信息，其实就是下面的一些校验

2.1这个类是否有父类（除了java.lang.Object之外所有地类都有父类）

2.2这个类的父类是否继承了不允许被继承的类（被finial修饰的类）

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

2.4类中的字段，方法是否于父类产生矛盾（例如覆盖了父类）的final字段，或者出现不符合规则的方法重载，例如方法参数都一致，但是返回值类型却不同等

。。。。。。。。。。。。。。。。。。看完这些验证是不是觉得和编译工具的校验类似

1. 字节码验证

主要目的：通过数据流和控制流分析，确定程序语义是合法的，符合逻辑的。这个阶段对类的方法体进行校验分析，保证被校验类的方法在运行时不会做出危害JVM安全的事件；例如：保证任意时刻操作数栈的数据类型于指令代码序列都能配合工作。。。。

如果一个类的方法体没有通过字节码验证一定是有问题的，没有通过也不能说明一定没有问题，离散数学有一个很著名的问题Halting Problem，通俗一点就是说不能用程序准确的证明一个程序通过了校验

1. 符号引用验证

这个阶段的校验发生在JVM将符号引用转化为直接引用的时候，这个转化动作将在连接的第三阶段----解析阶段中发生。对类自身以外（常量池中的各种符号引用）的信息进行匹配性校验

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

4.2在指定类中是否存在符合方法的字段描述符以及简单名称所描述的方法和字段

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

。。。。。

如果符号引用没有通过，将抛出java.lang.IllegalAccessError

如果能确保全部代码校验过，可以使用-Xverify:none参数关闭大部分的类校验，缩短JVM加载时间

准备

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

1. 这时候进行内存分配的仅仅是类变量（被static修饰的变量），而不是实例变量，实例变量将会在对象实例化的时候随着对象一起分配在java堆中。
2. 这个阶段赋初始值的变量指的是那些不被final修饰的static变量（“public static int value = 123”），value在准备阶段过后是0而不是123，给value赋值为123将在初始化阶段进行。对于public static final int value = 123；就不一样，在准备阶段JVM就会把123给value。

各种类型初始值

数据类型	初始值
Int	0
long	0L
Short	(short)0
Char	‘\u0000’
Byte	(byte)0
Boolean	False
Float	0.0f
Double	0.0d
Reference	null

 

解析

解析阶段是JVM将常量池内的符号引用替换为直接引用的过程。

符号引用和直接引用的区别

1. 符号引用，

符号引用是编译原理方面的概念，符号引用包括了类和接口的全限定名，字段的名称和描述符，方法的名称和描述符这三类常量。

通过javap -v -verbose输出附加信息

javap -v -verbose UploadOrFindImg.class

Classfile /E:/csdn/build/build/UploadOrFindImg.class

  Last modified 2019-3-8; size 377 bytes

  MD5 checksum 28459a2506307cc95447f30cc5d5453d

  Compiled from "UploadOrFindImg.java"

public class com.ecidi.dam.web.rest.fileupload.UploadOrFindImg

  minor version: 0

  major version: 52

  flags: ACC_PUBLIC, ACC_SUPER

Constant pool:

   #1 = Methodref          #3.#17         // java/lang/Object."<init>":()V

   #2 = Class              #18            // com/ecidi/dam/web/rest/fileupload/UploadOrFindImg

   #3 = Class              #19            // java/lang/Object

   #4 = Utf8               i

   #5 = Utf8               I

   #6 = Utf8               d

   #7 = Utf8               D

   #8 = Utf8               <init>

   #9 = Utf8               ()V

  #10 = Utf8               Code

  #11 = Utf8               LineNumberTable

  #12 = Utf8               print

  #13 = Utf8               trueOrFalse

  #14 = Utf8               ()Z

  #15 = Utf8               SourceFile

  #16 = Utf8               UploadOrFindImg.java

  #17 = NameAndType        #8:#9          // "<init>":()V

  #18 = Utf8               com/ecidi/dam/web/rest/fileupload/UploadOrFindImg

  #19 = Utf8               java/lang/Object

{

  public com.ecidi.dam.web.rest.fileupload.UploadOrFindImg();

    descriptor: ()V

    flags: ACC_PUBLIC

    Code:

      stack=1, locals=1, args_size=1

         0: aload_0

         1: invokespecial #1                  // Method java/lang/Object."<init>":()V

         4: return

      LineNumberTable:

        line 9: 0

 

  public static void print();

    descriptor: ()V

    flags: ACC_PUBLIC, ACC_STATIC

    Code:

      stack=0, locals=0, args_size=0

         0: return

      LineNumberTable:

        line 16: 0

}

SourceFile: "UploadOrFindImg.java"

看到Constant Pool就是常量池中的内容，其中Utf8就是符号引用。#2的值是类的全限定名；#4i和#5I，表示int和Integer类型，#6d，#7D表示double和Double

#18，#19表示的方法名字。

符号引用是对于类，变量，方法的描述。符号引用和JVM内存布局没有关系，引用的目标未必已经加载到内存中了。

1. 直接引用

直接引用可以是直接指向目标的指针，相对偏移量或是一个能间接定位到目标的句柄。直接引用是和JVM实现的内存布局相关的，同一个符号引用在不同JVM示例上翻译出来的直接引用一般不会相同。如果有了直接引用，那引用的目标必定已经存在在内存中了。

初始化

看完初始化之后就会明白为什么 实例化一个子类的时候代码的执行顺序

父类静态块 -> 子类静态块 -> 父类构造函数 -> 子类构造函数

初始阶段是真正执行类中定义的java程序代码（或者说是字节码）的过程。初始化阶段是一个执行类构造器<clinit>()方法的过程，根据程序员通过程序制定的主观计划去初始化类变量和其他资源。说的贴切一些，其实初始化阶段做的事就是给static变量赋予用户指定的值以及执行静态代码块。

注意：JVM保证类的初始化多线程环境中被正确的加锁，同步；即如果多个线程同时去初始化一个类，那么只会有一个类去执行这个类的<clinit>（）方法，其他线程都要阻塞等待，直至活动线程执行<clinit>()方法完毕。因此如果在一个类的<clinit>（）方法中有耗时很长的操作，就可能造成多个进程阻塞。不过其他线程虽然会阻塞，但是执行<clinit>()方法的那条线程退出<clinit>方法后，其他线程不会再次进入<clinit>（）方法了，因为同一个类加载器下，一个类只会初始化一次。实际应用中这种阻塞往往是比较隐藏的，要小心。

JVM规范严格规定了有且只有5种场景必须立即对类进行初始化。

1. 使用new 关键在实例化对象，读取或者设置了一个类的静态字段（被final修饰的静态字段除外），调用一个类的静态方法的时候
2. 使用java.lang.reflect包中的方法对类进行反射调用的时候
3. 初始化一个类，发现其父类还没有初始化过的时候
4. JVM启动的时候，JVM会先初始化用户指定的包含main（）方法的那个类
5. 当使用JDK1.7的动态语言支持时，如果一个java.lang.invoke.MethodHandle实例最后的解析结果REF_getStatic,REF_putStatic,REF_invokeStatic的方法句柄，并且这个方法句柄所对应的类没有进行过初始化，则需要先触发其初始化。

上面5中场景也被称为对一类进行主动引用。除此之后，所有引用类的方式都不会触发初始化，称为被动引用。

1. 通过子类引用父类的静态字段不会导致初始化

 

public class FatherClass {
   static {
      System.out.println("FatherClass");
   }
   public static int value= 3;
}

public class ChildClass extends FatherClass {
   static {
      System.out.println("ChildClass");
   }
}

public class RunMain {
   public static void main(String[] args) {
      System.out.println(ChildClass.value);
   }
}

 

[Loaded com.zzh.redis.config.FatherClass from file:/F:/idea_workspace/learning-codes/redis-study/target/classes/]

[Loaded com.zzh.redis.config.ChildClass from file:/F:/idea_workspace/learning-codes/redis-study/target/classes/]

FatherClass

3

可以看到上面的结果ChildClass 虽然被加载了，但是没有执行静态代码块里面的东西，所以也就没有被初始化。

1. 通过数组定义引用类，不会触发此类的初始化

public class RunMain {
   public static void main(String[] args) {
      FatherClass[] fatherClasses = new FatherClass[5];
   }
}

自己通过设置-XX:+TraceClassLoading参数可以试试，确实是没有执行FatherClass的初始化

1. 直接调用类的（final）静态常量不会触发此类的初始化

这种情况常量时否用final修饰是有区别的。

还用上面的FatherClass

public class RunMain {
   public static void main(String[] args) {
      System.out.println(FatherClass.value);
   }
}

[Loaded com.zzh.redis.config.FatherClass from file:/F:/idea_workspace/learning-codes/redis-study/target/classes/]

FatherClass

3

从结果上来看触发了FatherClass的初始化

改变一下FatherClass，RunMain不变

public class FatherClass {
   static {
      System.out.println("FatherClass");
   }
   public static final int value= 3;
}

3

只会打印出3，没有触发FahterClass的初始化