深入理解Java虚拟机（二） 类加载机制

Write Once Run Anywhere，一次编写多处运行

一、Java类文件结构

　　　　　　


　　上图为类文件的结构，从上到下排序依次为：

magic_number魔数：每个Class文件的头四个字节称为魔数，它的唯一作用就是确定这个文件是否为一个能被虚拟机接受的Class文件。

minor_version:次版本号

major_version:主版本号

constant_pool_count:Class文件中常量池的数目，由于常量池的计数从1开始，因此常量池的容量是constant_pool_count-1

constant_pool:常量池是Class类文件中出现的第一个表类型数据，常量池主要存放两大类常量：a.字面量(Literal)：包括文本字符串、final类型常量值。b.符号引用(SymbolicReferences)：包括类和接口的全限定名、字段的名称和描述符、方 法的名称和描述符。

access_flags：用于表示Class或接口层次的访问标志，即类或接口层面的访问控制信息，通常存储的信息包括：Class类文件是类、接口、枚举或是注解；是否定义为public类型；是否定义为abstract类型；类是否被定义为final等等。

this_class、super_class和interfaces：this_class类索引用于确定类的全限定名，super_class父类索引用于确定父类的全限定名，interfaces接口索引用于确定接口的全限定名，由于java中可以实现多个接口，因此使用interfaces_count来存储接口数量。

field:field_info字段表用于描述接口或者类中声明的变量，field字段包括了类级变量(静态变量)和实例级变量(成员变量)，但不包括方法内部的局部变量。
fields_count字段数目表示Class文件中的类和实例变量总数，字段存放的信息包括：字段访问标志、是否静态、是否final、是否并发可见volatile、是否可序列化transient、数据类型、字段名称等等。
注意：字段表中不包含从父类或者接口中继承而来的字段，但是会添加原本代码中不存在的字段，例如this，以及内部类对外部类访问而自动添加的外部类实例字段等。

method：method_info方法表用于描述类或者接口中声明的方法，methods_count用于表示Class文件中方法总数，method方法存储了方法的访问标识、是否静态、是否final、是否同步synchronized、是否本地方法native、是否抽象方法abstract、方法返回值类型、方法名称、方法参数列表等信息。
方法的代码指令并没有直接存放在方法表中，而是存放着属性表中的方法表Code中。
注意：如果父类的方法在子类没有被重写，方法表中不会出现来自父类的方法信息，但是编译器会自动添加类构造器”<clinit>”方法和实例构造器”<init>”方法。
Java编译器的方法特征签名只包括：方法名称、参数顺序和参数类型，不包括方法返回值类型，因此java的方法重载不能通过方法的返回值类区别，但是在Class文件中，方法特征签名包括方法的返回值类型，因此Class文件中可以共存两个名称和参数完全相同而返回值类型不同的方法。

attribute:attribute_info属性表是Class文件格式中最具扩展性的一种数据项目，用于存放field_info字段表、method_info方法表以及Class文件的专有信息，属性表不要求各个属性有严格顺序，只要求不与已有的属性名字重复即可

二、类加载机制

　　在加载阶段，java虚拟机需要完成以下3件事：
　　a.通过一个类的全限定名来获取定义此类的二进制字节流。
　　b.将定义类的二进制字节流所代表的静态存储结构转换为方法区的运行时数据结构。
　　c.在java堆中生成一个代表该类的java.lang.Class对象，作为方法区数据的访问入口。
　　Java虚拟机的类加载是通过类加载器实现的， Java中的类加载器体系结构如下：

　　


BootStrap ClassLoader：启动类加载器，负责加载存放在%JAVA_HOME%\lib目录中的，或者通被-Xbootclasspath参数所指定的路径中的，并且被java虚拟机识别的(仅按照文件名识别，如rt.jar，名字不符合的类库，即使放在指定路径中也不会被加载)类库到虚拟机的内存中，启动类加载器无法被java程序直接引用。

Extension ClassLoader：扩展类加载器，由sun.misc.Launcher$ExtClassLoader实现，负责加载%JAVA_HOME%\lib\ext目录中的，或者被java.ext.dirs系统变量所指定的路径中的所有类库，开发者可以直接使用扩展类加载器。

Application ClassLoader：应用程序类加载器，由sun.misc.Launcher$AppClassLoader实现，负责加载用户类路径classpath上所指定的类库，是类加载器ClassLoader中的getSystemClassLoader()方法的返回值，开发者可以直接使用应用程序类加载器，如果程序中没有自定义过类加载器，该加载器就是程序中默认的类加载器。

　　注意：上述三个JDK提供的类加载器虽然是父子类加载器关系，但是没有使用继承，而是使用了组合关系。

　　从JDK1.2开始，java虚拟机规范推荐开发者使用双亲委派模式(ParentsDelegation Model)进行类加载，其加载过程如下：

如果一个类加载器收到了类加载请求，它首先不会自己去尝试加载这个类，而是把类加载请求委派给父类加载器去完成。

每一层的类加载器都把类加载请求委派给父类加载器，直到所有的类加载请求都应该传递给顶层的启动类加载器。

如果顶层的启动类加载器无法完成加载请求，子类加载器尝试去加载，如果连最初发起类加载请求的类加载器也无法完成加载请求时，将会抛出ClassNotFoundException，而不再调用其子类加载器去进行类加载。

　　双亲委派 模式的类加载机制的优点是java类它的类加载器一起具备了一种带优先级的层次关系，越是基础的类，越是被上层的类加载器进行加载，保证了java程序的稳定运行。