JVM学习--（四）虚拟机类加载机制

JVM学习–（四）虚拟机类加载机制

当源码被编译成为class文件后，就需要加载到虚拟机之中被运用和使用，这个过程被称为虚拟机的类加载机制。
类加载机制只要通过加载、连接（验证、准备、解析）、初始化、使用、卸载。
类型的加载连接和初始化过程都是在程序运行的过程中完成的，给java带来了天生可以动态扩展的优势。

加载 验证 准备 初始化以及卸载必须顺序开始，但解析阶段某些情况下可以在初始化后进行。
对于初始化阶段，有且只有六种情况必须对类进行“初始化”，即为主动引用：
①遇到new、getstatic、putstatic或者invokestatic这四条命令时，其中的典型场景：1.使用new实例化对象。2.读取或者设置一个类型的静态变量（被final修饰的除外）。3.调用一个类型的静态方法。
②使用java.lang.reflect反射包进行发射，若没有初始化必须先初始化。
③若父类没有初始化，先初始化父类。
④启动时先初始化main所在的类。
⑤jdk7新加的动态语言支持，若有REF_getStatic、REF_putStatic、REF_invokeStatic、REF_newInvokeSpecial则先初始化。
⑥jdk8加入的default修饰的接口，需要对实现类进行初始化并且接口也要初始化。
下列的引用不会初始化，被称为被动引用：
①通过子类引用父类的静态方法，不会初始化子类。
②通过数组定义来引用类，不会触发此类的初始化。(会直接加载由虚拟机生成的数组)
③常量在编译阶段存于常量池，调用常量不会引起初始化。

**接口的不同点：接口初始化过程中不需要其父接口全部初始化。

一.加载

主要完成了三件事：
1️⃣通过一个类的全限定名来获得此类的二进制字节流。
2️⃣将字节流所代表的静态储存结构转化为方法区运行时的数据结构。
3️⃣在内存中（JAVA堆）生成这个类的class对象，作为方法区这个类的各种数据入口。

其中第一条规则灵活性非常大，用户可以从zip、web applet、jsp等等场景获得，是可控性最强的环节。
数组类而言情况不同，创建过程：
1️⃣如果组件类型是引用类型，先加载这个组件类型。
2️⃣如果组件类型是元素类型，把数组C标记为与引导类加载器关联。
3️⃣数组类的访问性应该与组件类型的访问性相同。

二.连接

1.验证

确保class文件中包含的信息符是符合规范的。
1️⃣文件格式验证。包括魔数验证、版本验证等等，这是环节是保证字节流可以布置到方法区上，下面的几步都是关于方法区的存储结构上的，与二进制字节流无关。
2️⃣元数据验证。对于描述的信息进行语义分析。包括类是否有父类、父类是否继承了不允许继承的等等。
3️⃣字节码验证。通过数据流分析和控制流分析确定程序语义是合法的符合逻辑的。相当于对于方法体中的code进行检查，但是不可能用程序做到准确判断一段程序是否有bug，jdk6后属性表中多了stackmaptable，用来判断是否合法。
4️⃣符号引用验证。检查虚拟机将符号引用转化为直接引用。转化动作是在解析中发生的。

2.准备

为类中定义的变量（静态变量）分配内存并设置类变量初始值的阶段。
jdk7之前是在方法区（永久代），jdk8后跟class对象一起放在java堆。
初始值指的是零值。

3.解析

将常量池中的符号引用替换成直接引用。
其中四种解析（静态）：
1️⃣类或接口的解析。
2️⃣字段解析。
3️⃣方法解析。
4️⃣接口解析。

三.初始化

类加载过程的最后一个步骤，java虚拟机真正开始执行类中编写的java程序代码。
初始化阶段就是执行类构造器< clinit >（）方法：包括对于类变量（静态变量）的赋值以及static静态代码块的执行。
类构造器会保证先执行父类的类构造器，这个构造器也不是必须的。
接口与类不同的是，执行子类的类构造器不需要先执行父类的类构造器，接口实现类初始化也不会执行接口的方法。

类加载器

类加载器的作用就是通过一个类的全限定名来获取描述该类的二进制字节流。
**不同的类加载器就算是加载同一个class文件，所生成的类也是不一样的。

双亲委派模型

对于java虚拟机角度：只有2种类加载器，一种是启动类加载器，用C++实现。第二种是其他所有类加载器，用java实现。
细分下来可以分成3种类加载器：
1️⃣启动类加载器：放在lib目录下或者被-Xbootclasspath参数指定的路径存放，此加载器无法被Java程序直接引用，getClassLoader中一般用null代替。
2️⃣扩展类加载器：加载lib/ext下的文件，可以拓展通用性类库。
3️⃣应用程序类加载器：加载ClassPath上的所有类库。
jdk9前都是这三种互相配合加载，其中之间的关系也被称为“双亲委派关系”：只有当父类加载器反馈无法完成加载请求，子加载器才尝试自己去完成加载。好处是可以保证在不同的加载器环境下都是同一个类。

三次破坏双亲委派情况

1️⃣在jdk1.2前的原始时代，双亲委派还没有引入，但是classloader在第一个版本中就有，因此已经存在用户自定义的加载器的代码，所以对于以后的代码设计了一个findclass方法，引导用户尽量重写这个方法，如果父类加载失败就加载这个类，这就做到了向上兼容又符合双亲委派。
2️⃣第二次破坏是因为自身存在缺陷，比如有些基础类型需要调回用户的代码，这时候引入了线程上下文类加载器。有了线程上下文类加载器，允许父类加载器去请求子类加载器完成类加载的行为。
3️⃣第三次破坏是由于对程序动态性的追求所导致的，通过类加载器来实现热部署，当需要更换程序模版时，就连同类加载器一起换掉，而这里的类加载器其中很多需要用到平级搜索。