JVM类加载机制
JVM把描述类的数据从Class文件加载到内存,并对数据进行效验,转换解析和初始化,最终可以被JVM直接使用的java类型.
类加载的时机
类被加载到JVM内存中开始,到卸载为止,整个生命周期包括:加载,验证,准备,解析,初始化,使用和卸载7个阶段
加载,验证,准备,初始化,卸载这五个步骤顺序是固定的,而解析阶段则不一定:它在某些情况下可以在初始化之后再来时,这个是为了支持java语言运行时绑定(动态绑定或晚期绑定)
JVM规范规定有且只有五种情况必须立即对类进行初始化
1.遇到new、getstatic、putstatic或invokestatic这4条字节码指令时，如果类没有进行过初始化，则需要触发其初始化.生成这四条指令 常见的场景是:使用new关键字实例化对象的时候,读取或设置一个类的静态字段(被final修饰,已在编译期把结果放入常量池的静态字段除外)的时候,和调用一个类的静态方法的时候.
- 使用java.lang.reflect包对类进行反射调用时,如果这个类没有被初始化,那么将对其初始化
- 当初始化类的时候,如果发现它的父类还没有被初始化的时候,将会先初始化其父类
- 当jvm启动时,指定的执行类(main方法的类),JVM会先初始化这个类
- 当使用jdk1.7的动态语言支持时,如果一个java.lang.invoke.MethodHandle实例最后的解析结果REF_getStatic、REF_putStatic、REF_invokeStatic的方法句柄，并且这个方法句柄所对应的类没有进行过初始化，则需要先触发其初始化
被动引用
- 通过子类引用父类的静态字段,不会导致子类初始化
- 通过数组定义来引用类,不会触发该类初始化
- 常量在编译期间会存入调用类的常量池中,本质上并没有直接引用到定义常量的类,因此不会触发此类的初始化
接口的初始化:接口在初始化时,并不要求其父接口全部完成类初始化,只有在真正用到父接口的时候(如引用接口中定义的常量)才会初始化
类加载的过程
- 通过类的全限定名类获取定义此类的二进制字节流
- 将这字节类所代表的静态存储结构转化为方法区运行的数据结构
- 在内存中产生一个代表这个类的java.lang.Class对象,作为方法区这个类的各种数据的访问入口
获取二进制字节流:
数组类本身不通过类加载器创建,由JVM直接创建.
数组类创建过程中遵循以下规则
- 如果数组的组件类型(指的是数组去掉一个维度的类型)是引用类型(也可以理解为对象数组),那就采用上面的加载过程去加载这个组件类型,数组C将在加载该组件类型的类加载器的类名称空间上被标识.
- 如果数组的组件类型不是引用类型(如int类型),JVM会把数据C标识为与引导类加载器关联.
- 数组类的可见性与它的组件类型的可见性一致,如果组件类型不是引用类型,那数组类的可见性为public
验证阶段4个阶段的检验动作:文件格式验证,元数据验证,字节码验证,符号引用验证
- 文件格式验证
主要验证字符流是否符合Class文件格式的规范,并且能被当前JVM所处理, 包括:
这个阶段的验证是在基于二进制字节流进行的,只有通过这个验证后,字节流才会进入内存的方法区进行存储,所以后面那三个验证都是基于方法区的存储结构进行的,不会直接操作字节流.
2 元数据验证
第二阶段的主要目的是对类元数据信息进行语义效验,保证不存在不符合JAVA语言规范的元数据信息
3.字节码验证
这个阶段是最复杂的一个阶段,主要目的似乎通过数据流和控制流分析，确定程序语言是合法的、符合逻辑的。在第二阶段对元数据信息中的数据类型做完校验后，这个阶段将对类的方法体进行校验分析，保证被校验类的方法在运行时不会做出危害虚拟机安全的事件。
4. 符号引用验证
发生在JVM将符号引用转化为直接引用的时候,
1.符号引用中通过字符串描述的全限定名是否能找到相对应的类
2.在指定类中是否存在符合方法的字段描述符以及简单名称所描述的方法和字段
3.符号引用中的类、字段、方法的访问性是否可被当前类访问
对于jvm的类加载来说,验证非常重要,但是不一定必要(对程序运行期没有影响)的阶段.如果全部代码都已经反复使用和验证过,那么在实施阶段就可以考虑使用Xverify:none参数来关闭大部分的类验证措施,来减少JVM类加载的时间
准备阶段
准备阶段是正式为类变量分配内存并设置类变量初始值的阶段，这些变量都在方法区中进行分配。这个时候进行内存分配的仅包括类变量(被static修饰的变量)，而不包括实例变量，实例变量将会在对象实例化时随着对象一起分配在Java堆中。其次，这里说的初始值通常下是数据类型的零值。如下:
假设public static int value = 123；那变量value在准备阶段过后的初始值为0而不是123，因为这时候尚未开始执行任何Java方法，而把value赋值为123的putstatic指令是程序被编译后，存放于类构造器<clinit>()方法之中，所以把value赋值为123的动作将在初始化阶段才会执行，但是如果使用final修饰，则在这个阶段其初始值设置为123
解析
将JVM常量池内符号引用替换成直接引用的过程
初始化
是类加载的最后一步,前面类加载的过程中, 除了加载阶段用户应用程序可以通过自定义类加载器参与之中,其余动作完全由JVM主导和控制.到了初始化阶段,才正真开始执行类中定义的JAVA程序代码(或者是字节码)
类的加载器:
双亲委派模型
只存在两种不同的类加载器:启动类加载器,用C++实现,是JVM自身的一部分.另一种是所有其他类的加载器,用JAVA实现,独立于JVM,并且全部继承自抽象类java.lang.ClassLoader.
启动类加载器,负责将存放在<java+Home>\lib目录中的,或者被-Xbootclasspath参数所制定的路径中的,并且是JVM识别的(仅按照文件名识别,如rt.jar,如果名字不符合,即放在lib目录中也不会被加载),加载到JVM内存中,启动类加载器无法被JAVA程序直接引用.
扩展类加载器,由sun.misc.Launcher$ExtClassLoader实现，负责加载<JAVA_HOME>\lib\ext目录中的，或者被java.ext.dirs系统变量所指定的路径中的所有类库，开发者可以直接使用扩展类加载器。
应用程序加载器,由sun.misc.Launcher$AppClassLoader来实现。由于这个类加载器是ClassLoader中的getSystemClassLoader()方法的返回值，所以一般称它为系统类加载器。负责加载用户类路径（ClassPath）上所指定的类库，开发者可以直接使用这个类加载器，如果应用程序中没有自定义过自己的类加载器，一般情况下这个就是程序中默认的类加载器。
这张图表示类加载器的双亲委派模型,双亲委派模型要求除了顶层的启动加载类外,其余的类加载器都应当有自己的父类加载器,这里类加载器之间的父子关系一般不会以继承的关系来实现，而是使用组合关系来复用父类加载器的代码。
双亲委派模型的工作过程是:
如果一个类加载器收到了类加载的请求，它首先不会自己去尝试加载这个类，而是把这个请求委派给父类加载器去完成，每一个层次的类加载器都是如此，因此所有的加载请求最终都是应该传送到顶层的启动类加载器中，只有当父类加载器反馈自己无法完成这个加载请求（它的搜索范围中没有找到所需的类）时，子加载器才会尝试自己去加载。
这样做的好处是:
就是保证某个范围的类一定是被某个类加载器所加载的，这就保证在程序中同 一个类不会被不同的类加载器加载。这样做的一个主要的考量，就是从安全层 面上，杜绝通过使用和JRE相同的类名冒充现有JRE的类达到替换的攻击方式.
以上是在JVM规范书本上学习记下的笔记,拿出来给各位分享
阅读更多