Java语言是一种编译后再经过解释器执行的过程, 解释器主要就是如何处理解释Class文件的二进制字节流。JVM主要包含三大核心部分:运行时数据区,类加载器和执行引擎。
虚拟机将描述类的数据从Class文件加载到内存,并对数据进行校验、准备、解析和初始化,最终就会形成可以被虚拟机使用的Java类型,这就是一个虚拟机的类加载机制。Java中的类是动态加载的,只有在运行期间使用到该类的时候,才会将该类加载到内存中,Java依赖于运行期动态加载和动态链接来实现类的动态使用。
一个类的整个生命周期如下:
加载,验证,准备,初始化和卸载在开始的顺序上是固定的,但是可以交叉进行。
在Java中,对于类有且仅有四种情况会对类进行“初始化”。
1) 使用new关键字实例化对象的时候,读取或设置一个类的静态字段时候(除final修饰的static外),调用类的静态方法时候,都只会初始化该静态字段或者静态方法所定义的类。
2) 使用reflect包对类进行放射调用的时候,如果类没有进行初始化,则先要初始化该类
3) 当初始化一个类的时候,如果其父类没有初始化过,则先要触发其父类初始化。
4) 虚拟机启动的时候,会初始化一个有main方法的主类。
注意:通过子类引用父类静态字段,只会初始化父类不会初始化子类;通过数组定义来引用类,也不会触发该类的初始化;常量在编译阶段会存入调用类的常量池中,本质上没有直接引用到定义常量的类,因此也不会触发定义常量的类的初始化。
加载阶段主要完成三件事,即通过一个类的全限定名来获取定义此类的二进制字节流,将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构,在Java堆中生成一个代表此类的Class对象,作为访问方法区这些数据的入口。这个加载过程主要就是靠类加载器实现的,这个过程可以由用户自定义类的加载过程。
这个阶段目的在于确保Class文件的字节流中包含信息符合当前虚拟机要求,不会危害虚拟机自身安全。主要包括四种验证:
文件格式验证:基于字节流验证,验证字节流是否符合Class文件格式的规范,并且能被当前虚拟机处理。
元数据验证:基于方法区的存储结构验证,对字节码描述信息进行语义验证。
字节码验证:基于方法区的存储结构验证,进行数据流和控制流的验证。
符号引用验证:基于方法区的存储结构验证,发生在解析中,是否可以将符号引用成功解析为直接引用。
仅仅为类变量(即static修饰的字段变量)分配内存并且设置该类变量的初始值即零值,这里不包含用final修饰的static,因为final在编译的时候就会分配了,同时这里也不会为实例变量分配初始化。类变量会分配在方法区中,而实例变量是会随着对象一起分配到Java堆中。
解析主要就是将常量池中的符号引用替换为直接引用的过程。符号引用就是一组符号来描述目标,可以是任何字面量,而直接引用就是直接指向目标的指针、相对偏移量或一个间接定位到目标的句柄。有类或接口的解析,字段解析,类方法解析,接口方法解析。
这里要注意如果有一个同名字段同时出现在一个类的接口和父类中,那么编译器一般都会拒绝编译。
初始化阶段依旧是初始化类变量和其他资源,这里将执行用户的static字段和静态语句块的赋值操作。这个过程就是执行类构造器<clinit>方法的过程。
<clinit>方法是由编译器收集类中所有类变量的赋值动作和静态语句块的语句生成的,类构造器<clinit>方法与实例构造器<init>方法不同,这里面不用显示的调用父类的<clinit>方法,父类的<clinit>方法会自动先执行于子类的<clinit>方法。即父类定义的静态语句块和静态字段都要优先子类的变量赋值操作。
启动类加载器(Bootstrap ClassLoader): 主要负责加载<JAVA_HOME>\lib目录中的,或是-Xbootclasspath参数指定的路径中的,并且可以被虚拟机识别(仅仅按照文件名识别的)的类库到虚拟机内存中。它加载的是System.getProperty("sun.boot.class.path")所指定的路径或jar。
扩展类加载器(Extension ClassLoader):主要负责加载<JAVA_HOME>\lib\ext目录中的,或者被java.ext.dirs系统变量所指定的路径中的所有类库。它加载的是
System.getProperty("java.ext.dirs")所指定的路径或jar。
应用程序类加载器(Application ClassLoader):也叫系统类加载器,主要负责加载ClassPath路径上的类库,如果应用程序没有自定义自己类加载器,则这个就是默认的类加载器。
它加载的是System.getProperty("java.class.path")所指定的路径或jar。
1)运行一个程序时,总是由Application Loader(系统类加载器)开始加载指定的类。
2)在加载类时,每个类加载器会将加载任务上交给其父,如果其父找不到,再由自己去加载。
3)Bootstrap Loader(启动类加载器)是最顶级的类加载器了,其父加载器为null.
类加载器双亲委派模型的工作过程是:如果一个类加载器收到一个类加载的请求,它首先将这个请求委派给父类加载器去完成,每一个层次类加载器都是如此,则所有的类加载请求都会传送到顶层的启动类加载器,只有父加载器无法完成这个加载请求(即它的搜索范围中没有找到所要的类),子类才尝试加载。
使用双亲委派模型主要是两个原因:1)可以避免重复加载,当父类已经加载了,则就子类不需再次加载;2)安全因素,如果不用这种,则用户可以随意的自定义加载器来替代Java核心API,则就会带来安全隐患。
下面是一个类加载器双亲委派模型,这里各个类加载器并不是继承关系,它们利用组合实现的父类与子类关系。
1) 命令行启动应用时候由JVM初始化加载,加载含有main的主类。
2)通过Class.forName("Hello")方法动态加载类,默认会执行初始化块,这是因为Class.forName("Hello")其实就是Class.forName("Hello",true,CALLCLASS.getClassLoader()),第二个参数就是类加载过程中的连接操作。如果指定了ClassLoader,则不会执行初始化块。
3)通过ClassLoader.loadClass("Hello")方法动态加载类,不会执行初始化块,因为loadClass方法有两个参数,用户只是用第一个参数,第二个参数默认为false,即不对该类进行解析则就不会初始化。
当在命令行下执行:java HelloWorld(HelloWorld是含有main方法的类的Class文件),JVM会将HelloWorld.class加载到内存中,并在堆中形成一个Class的对象HelloWorld.class。
基本的加载流程如下:
1)寻找jre目录,寻找jvm.dll,并初始化JVM;
2)产生一个Bootstrap Loader(启动类加载器);
3)Bootstrap Loader,该加载器会加载它指定路径下的Java核心API,并且再自动加载Extended Loader(标准扩展类加载器),Extended Loader会加载指定路径下的扩展JavaAPI,并将其父Loader设为BootstrapLoader。
4)Bootstrap Loader也会同时自动加载AppClass Loader(系统类加载器),并将其父Loader设为ExtendedLoader。
5)最后由AppClass Loader加载CLASSPATH目录下定义的类,HelloWorld类。
本文出自 “在云端的追梦” 博客,请务必保留此出处http://computerdragon.blog.51cto.com/6235984/1223354