前言
上一篇咱们粗略的介绍了一下Java虚拟机的运行时数据区，并对运行时数据区内的划分进行了解释，明天咱们就会从类加载开始剖析并会深刻去看看数据是具体以什么格局存储到运行时数据区的。
编译
一个.java文件通过编译之后，变成了了.class文件，次要通过留下步骤：
.java -> 词法分析器 -> tokens流 -> 语法分析器 -> 语法树/形象语法树 -> 语义分析器 -> 注解形象语法树 -> 字节码生成器 -> .class文件 。
具体的过程不做剖析，波及到编译原理比较复杂，咱们须要剖析的是.class文件到底是一个什么样的文件？
Class文件
在Java中，每个类文件蕴含单个类或接口，每个类文件由一个8位字节流组成。所有16位、32位和64位的量都是通过别离读取2个、4个和8个间断的8位字节来构建的。
Java虚拟机标准中规定，Class文件格式应用一种相似于C语言的伪构造来存储数据，class文件中只有两种数据类型，无符号数和表。留神，class文件中没有任何对齐和填充的说法，所有数据都依照特定的程序紧凑的排列在Class文件中。
- 无符号数
属于数据的根本类型，以u1,u2,u4,u8来示意1个字节，2个儿字节，4个字节,8个字节(在Java SE平台中，这些类型能够通过readUnsignedByte、readUnsignedShort和接口java.io.DataInput中的的readInt办法进行读取)。 - 表
由0个或多个大小可变的项组成，用于多个类文件构造中，也就是说一个类其实就相当于是一个表。
Class文件构造
一个Class文件大抵由如下构造组成：
ClassFile { u4 magic;//魔数 u2 minor_version;//次版本号 u2 major_version;//主版本号 u2 constant_pool_count;//常量池数量 cp_info constant_pool[constant_pool_count-1];//常量池信息 u2 access_flags;//拜访标记 u2 this_class;//类索引 u2 super_class;//父类索引 u2 interfaces_count;//接口数(2位，所以一个类最多65535个接口) u2 interfaces[interfaces_count];//接口索引 u2 fields_count;//字段数 field_info fields[fields_count];//字段表汇合 u2 methods_count;//办法数 method_info methods[methods_count];//办法汇合 u2 attributes_count;//属性数 attribute_info attributes[attributes_count];//属性表汇合}这个构造在本篇文章里不会一一去解释，如果一一去解释的话一来显得很干燥，二来可能会占据大量篇幅，这些货色脑子外面有个整体的概念，须要的时候再查下材料就好了，前面的内容中，如果遇到一些十分罕用的类构造含意会进行阐明，如魔数等还是有必要理解一下的。
Class文件示例
咱们先任意写一个示例TestClassFormat.java文件：
package com.zwx.jvm;public class TestClassFormat { public static void main(String[] args) { System.out.println("Hello JVM"); }}而后进行编译，失去TestClassFormat.class，利用16进制关上：
因为Java虚拟机只认Class文件，所以必然会对Class文件的格局有严格的安全性校验。
魔数
每个Class文件中都会以一个4字节的魔数(magic)结尾(u4)，即上图中的CA FE BA BE（咖啡宝贝）用来标记一个文件是不是一个Class文件。
主次版本号
魔数之后的2个字节(u2)就是minor_version(次版本号)，再往后2个字节(u2)记录的是major_version(次版本号)，这个还是十分有必要理解的，上面这个异样我想可能很多人都已经遇到过：
java.lang.UnsupportedClassVersionError: com/zwx/demo : Unsupported major.minor version 52.0 at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClassCond(ClassLoader.java:631)这个异样就是提醒主版本号不对。
Java中的版本号是从45开始的，也就是JDK1.0对应到Class文件的主版本号就是45，而JDK8对应到的主版本就是52。
上图中类文件的主版本号(第7和第8位)00 34 ，转成10进制就是52，也就是这个类就用JDK1.8来编译的，而后因为我用的是JDK1.6来运行，就会报下面的错了，因为高版本的JDK能向下兼容低版本的Class文件，然而不能向上兼容更高版本的Class文件，所以就会呈现下面的异样。
其余
其余还有很多校验，比如说常量池的一些信息和计数，拜访权限(public等)及其他一些规定，都是依照Class文件规定好的程序往后紧凑的排在一起。
类加载机制
.java文件通过编译之后，就须要将class文件加载到内存了了，并将数据依照分类存储在运行时数据区的不同区域。
一个类从被加载到内存，再到应用结束之后卸载，总共会通过5大步骤(7个阶段)：
加载(Loading)，连贯(Linking)，初始化(Initialization)，应用(Using)，卸载(Unloading) ,其中连贯(Linking)又分为：验证(Verification),筹备(Preparation)，解析(Resolution)。
加载(Loading)
加载指的是通过一个残缺的类或接口名称来取得其二进制流的模式并将其依照Java虚拟机标准将数据存储到运行时数据区。
类的加载次要是要做以下三件事：
- 1、通过一个类的全限定名获取定义此类的二进制字节流。
- 2、将这个二进制字节流所代表的动态存储构造转化为办法区的运行时数据结构。
- 3、在Java堆中生成一个代表这个类的java.lang.Class对象，作为对办法区中这些数据的拜访入口。
下面的第1步在虚拟机标准中并没有阐明Class来源于哪里,也没有阐明怎么获取，所以就会产生了十分多的不同实现形式，上面就是一些罕用的实现形式：
- 1、最失常的形式，读取本地通过编译后的.class文件。
- 2、从压缩包,如：zip,jar,war等文件中读取。
- 3、从网络中获取。
- 4、通过动静代理动静生成.class文件。
- 5、从数据库中读取。
执行Class(类或者接口)的加载操作须要一个类加载器，而一个良好的，合格的类加载器须要具备以下两个属性：
- 1、对于同一个Class名称，任何时候都应该返回雷同的类对象
- 2、如果类加载器L1委派另一个类加载器L2来加载一个Class对象C，那么以下场景呈现的任何类型T，两个类加载器L1和L2应返回雷同的Class对象：
(1) C的间接父类或者父接口类型；
(2) C中的字段类型；
(3) C中办法或构造函数的中的参数类型；
(4) C中办法的返回类型
在Java中的类加载器不止一种，而对于同一个类，用不同的类加载器加载进去的对象是不相等的，那么Java是如何保障下面的两点的呢？
这就是双亲委派模式，Java中通过双亲委派模式来避免歹意加载，双亲委派模式也确保了Java的安全性。
双亲委派模式
双亲委派模式的工作流程很简略，当一个类加载器收到加载申请时，本人不去加载，而是交给它的父加载器去加载，以此类推，直到传递到最顶层类加载器，而只有当父加载器反馈说本人无奈加载这个类，子加载器才会尝试去加载这个类。
上图中就是双亲委派模型，仔细的人可能留神到，顶层加载器我应用了虚线来示意，因为顶层加载器是一个非凡的存在，没有父加载器，而且从实现上来说，也没有子加载器，是一个独立的加载器，因为扩大类加载器(Extension ClassLoader)和应用程序类加载器(Application ClassLoader)两个加载器从继承关系来看，是有父子关系的，均继承了URLClassLoader。然而尽管从类的继承关系来说启动类加载器(Bootstrap ClassLoader)没有子加载器，然而逻辑上扩大类加载器(Extension ClassLoader)还是会将收到的申请优先交给启动类加载器(Bootstrap ClassLoader)来进行优先加载。
- 启动类加载器(Bootstrap ClassLoader)，负责加载$JAVA_HOMElib下的类或者被参数-Xbootclasspath指定的能被虚拟机辨认的类(通过jar名字辨认，如：rt.jar)，启动类加载器由Java虚拟机间接管制，开发者不能间接应用启动类加载器。
- 扩大类加载器(Extension ClassLoader)，负责加载$JAVA_HOMElibext下的类或者被java.ext.dirs零碎变量指定的门路中所有类库(System.getProperty(“java.ext.dirs”))，开发者能够间接应用这个类加载器。
- 应用程序类加载器(Application ClassLoader)，负责加载$CLASS_PATH中指定的类库。开发者能间接应用这个类加载器，失常状况下如果在咱们的应用程序中没有自定义类加载器，个别用的就是这个类加载器。
- 自定义类加载器。如果须要，能够通过java.lang.ClassLoader的子类来定义本人的类加载器,个别咱们都抉择继承URLClassLoader来进行适当的改写就能够了。
毁坏双亲委派模式
双亲委派模式并不是一个强制性的束缚模型，只是一种举荐的加载模型，尽管大家大都恪守了这个规定，然而也有不恪守双亲委派模型的，比方：JNDI,JDBC等相干的SPI动作并没有齐全恪守双亲委派模式
毁坏双亲委派模式的一个最简略的形式就是：继承ClassLoader类，而后重写其中的loadClass办法(因为双亲委派的逻辑就写在了loadClass()办法中)。
常见异样
如果加载过程中产生异样，那么可能抛出以下异样(均为LinkageError的子类)：
- ClassCircularityError：extends或者implements了本人的类或接口
- ClassFormatError：类或者接口的二进制格局不正确
- NoClassDefFoundError：依据提供的全限定类名找不到对应的类或者接口
ClassNotFoundException和NoClassDefFoundError
还有一个异样ClassNotFoundException可能也会常常遇到，这个看起来和NoClassDefFoundError很类似，但其实看名字就晓得ClassNotFoundException是继承自Exception，而NoClassDefFoundError是继承自Error。
- ClassNotFoundException
当JVM要加载指定文件的字节码到内存时，发现这个文件并不存在，就会抛出这个异样。这个异样个别呈现在显式加载中，次要有以下三种场景：
(1)调用Class.forName() 办法
(2)调用ClassLoader中的findSystemClass() 办法
(3)调用ClassLoader中的loadClass() 办法
解决办法：个别须要查看classpath目录下是否存在指定文件。 - NoClassDefFoundError
这个异样个别呈现在隐式加载中，呈现的状况是可能应用了new关键字，或者是属性援用了某个类，或者是继承了某个类或者接口，或者是办法中的某个参数中援用了某个类，这时候就会触发JVM隐式加载，而在加载时发现类并不存在，则会抛出这个异样。
解决办法：确保每个援用的类都在以后classpath下
连贯(Linking)
链接是获取类或接口类型的二进制模式并将其联合到Java虚拟机的运行时状态以便执行的过程。链蕴含三个步骤：验证，筹备和解析。
留神：因为链接波及到新数据结构的调配，所以它可能会抛出异样OutOfMemoryError。
验证(Verification)
这个步骤很好了解，类加载进来了必定是须要对格局做一个校验，要不然什么货色都间接放到内存外面，Java的安全性就齐全无奈失去保障。
次要验证以下几个方面：
- 1、文件格式的验证：比如说是不是以魔数结尾，jdk版本号的正确性等等。
- 2、元数据验证：比如说类中的字段是否非法，是否有父类，父类是否非法等等
- 3、字节码验证：次要是确定程序的语义和控制流是否合乎逻辑
如果验证失败，会抛出一个异样VerifyError（继承自LinkageError）。
筹备(Preparation)
筹备工作是正式开始调配内存地址的一个阶段，次要为类或接口创立动态字段(类变量和常量)，并将这些字段初始化为默认值。
以下是一些罕用的初始值：
数据类型
默认值
int
0
long
0L
short
(short)0
float
0.0f
double
0.0d
char
‘u0000’
byte
(byte)0
boolean
false
援用类型
null
须要留神的是，假如某些字段的在常量池中曾经存在了，则会间接在春被阶段就会将其赋值。
如：
static final int i = 100;这种被final润饰的会间接被赋初始值，而不会赋默认值。
解析(Resolution)
解析阶段就是将常量池中符号援用替换为间接援用的过程。在应用符号援用之前，它必须通过解析，解析过程中符号援用会对符号援用的正确性进行查看。
留神：因为Java是反对动静绑定的，有些援用须要等到具体应用的时候才会晓得具体须要指向的对象，所以解析这个步骤是能够在初始化之后才进行的。
常见异样
解析过程中可能会产生以下异样：
- IllegalAccessError：权限异样，比方一个办法或者属性被申明为private，然而又被调用了，就会抛出这个异样。
- InstantiationError：实例化谬误。在解析符号援用时，发现指向了一个接口或者抽象类而导致对象不能被实例化，就会抛出这个异样。
- NoSuchFieldError：遇到了援用特定类或接口的特定字段的符号援用，然而类或接口不蕴含该名称的字段。
- NoSuchMethodError：遇到了援用特定类或接口的特定办法的符号援用，但该类或接口不蕴含该签名的办法。
符号援用
符号援用以一组符号来形容锁援用的指标，其中的符号能够是任何模式的字面量，只有依据符号惟一的定位到指标即可。比如说：String s = xx，xx就是一个符号，只有依据这个符号能定位到这个xx就是变量s的值就行。
间接援用
间接指向指标的指针、绝对偏移量或是一个能间接定位到指标的句柄。对于同一个符号援用通过不同虚拟机转换而失去的间接饮用个别是不雷同的。当有了间接援用之后，那么援用的指标必然曾经存在于内存，所以这一步要在筹备之后，因为筹备阶段会分配内存，而这一步实际上也就是一个地址的配对的过程。
初始化(Initialization)
这个阶段就是执行真正的赋值，会将之前赋的默认值替换为真正的初始值，在这一步，会执行结构器办法。
那么一个类什么时候须要初始化？父类和子类的初始化程序又是如何？
初始化程序
在Java虚拟机标准中规定了5种状况必须立刻对类进行初始化，被动触发初始化的行为也被称之为被动援用(除了以下5种状况之外，其余不会触发初始化的援用都称之为被动援用)。
- 1、虚拟机启动时候，会先初始化咱们指定的须要执行的主类(即main办法所在类)。
- 2、应用new关键字实例化对象时候，读取或者设置一个类的动态字段(final润饰除外)，以及调用一个类的静态方法时。
- 3、初始化一个类的时候，如果其父类没被初始化，则会先触发父类的初始化。
- 4、应用反射调用类的时候。
- 5、JDK1.7开始提供的动静语言反对时，如果一个
java.lang.invoke.MethodHandle实例解析的后果REF_getStatic，REF_putStatic，REF_invokeStatic的办法句柄对应的类没有被初始化，须要触发其初始化。
留神：接口的初始化在第3点会有点不一样，就是当一个接口在初始化的时候，并不要求其父接口全副都初始化，只有在真正应用到父接口的时候(如调用接口中定义的常量)才会初始化。
初始化实战举例
上面咱们来看一些初始化的例子：
package com.zwx.jvm;public class TestInit1 { public static void main(String[] args) { System.out.println(new SubClass());//A-先初始化父类，后初始化子类// System.out.println(SubClass.value);//B-只初始化父类，因为对于static字段，只会初始化字段所在类// System.out.println(SubClass.finalValue);//C-不会初始化任何类，final润饰的数据初始化之前就会放到常量池// System.out.println(SubClass.s1);//D-不会初始化任何类，final润饰的数据初始化之前就会放到常量池// SubClass[] arr = new SubClass[5];//E-数组不会触发初始化 }}class SuperClass{ static { System.out.println("Init SuperClass"); } static int value = 100; final static int finalValue = 200; final static String s1 = "Hello JVM";}class SubClass extends SuperClass{ static { System.out.println("Init SubClass"); }}- 1、语句A输入后果为：
Init SuperClass Init SubClass com.zwx.jvm.SubClass@xxxxxx
因为new关键字会触发SubClass的初始化(被动援用状况2)，而其父类没有被初始化会先触发父类的初始化(被动援用状况3)
- 2、语句B输入后果为：
Init SuperClass 100
调用了类的动态常量(被动援用状况2)，尽管是通过子类调用的，然而动态常量却定义在父类，所以只会触发其父类初始化，因为动态属性的调用只会触发属性所在类
- 3、语句C和语句D输入后果为：
200
因为被final润饰的动态常量存在于常量池中，在连贯的筹备阶段就会将属性间接进行赋值了，不须要初始化类。
- 4、语句E不会输入任何后果
因为结构数组对象和间接结构对象是通过不同的字节码指令来实现的，创立数组是通过一个独自的newarray指令来实现的，并不会初始化对象。
应用(Using)
通过下面五个步骤之后，一个残缺的对象曾经加载到内存中了，接下来在咱们的代码中就能够间接应用啦。
卸载(Unloading)
当一个对象不再被应用之后，会被垃圾回收掉，垃圾回收会在JVM系列后续文章中进行介绍。
总结
本文次要介绍了Java虚拟机的类加载机制，置信看完这篇再联合上一篇对运行时数据区的解说，大家对Java虚拟机的类加载机制的工作原理有了一个整体的认知，那么下一篇，咱们会从更深层次的字节码上来更具体更深刻的剖析Java虚拟机的办法调用流程及办法重载和办法重写的原理剖析。
请关注我，一起学习提高