【深入理解Java虚拟机】类加载机制
来源：程序员人生 发布时间：2016-07-01 15:24:10 阅读次数：2235次
本文内容来源于《深入理解Java虚拟机》1书，非常推荐大家去看1下这本书。
本系列其他文章：
【深入理解Java虚拟机】Java内存区域模型、对象创建进程、常见OOM
【深入理解Java虚拟机】垃圾回收机制
1、类加载机制概述
虚拟机把描写类的数据从Class文件加载到内存，并对数据进行校验、转换解析和初始化，终究构成可以被虚拟机直接使用的Java类型，这就是虚拟机的类加载机制。
在java中，类型的加载、连接和初始化进程都是在程序运行期间完成的，这类策略虽然会带来1些性能开消，但是却为java利用程序提供了高度的灵活性，java动态扩大的语言特性就是依赖运行期动态加载和动态链接这个特点构成的，所谓java动态扩大，比如，如果编写了1个面向接口的利用程序，可以等到运行时再指定其实际的实现类。
2、类加载的时机
类从被加载到虚拟机内存中开始，到卸载出内存为止，全部生命周期包括：加载、验证、准备、解析、初始化、使用、卸载，共7个阶段。其中，验证、准备、解析3个阶段称为连接（Linking），7个进程产生顺序以下：
上面这7个进程，除解析这个进程外，其余进程必须循序渐进地履行，即顺序是肯定的，而解析进程不1定，在某些情况下可以在初始化阶段以后再履行，这是为了支持java语言的运行时绑定（也称为动态绑定或晚期绑定）。
java虚拟机规范中，并没有规定类加载进程中的第1个阶段（即加载阶段）的履行时机，但是对初始化阶段，虚拟机规范中严格规定了“有且只有”下面5种情况下必须立即对类进行初始化（而这时候，加载、验证、准备自然需要在此之前开始）：
（1）遇到new、getstatic、putstatic、invokestatic这4条指令时，必须触发其初始化。这4条指令最多见的场景是：使用new关键字实例化对象、读取或设置1个类的静态字段（被final修饰、已在编译期把结果放入常量池的静态字段除外，即常量除外）、调用1个类的静态方法的时候；
（2）进行反射调用的时候；
（3）初始化1个类的时候，如果其父类还没有初始化，则需要先触发其父类的初始化；
（4）当虚拟机启动时，需要先初始化那个包括main方法的要履行的主类；
（5）当使用JDK1.7的动态语言支持时，如果1个java.lang.invoke.MethodHandle实例最后的解析结果为REF_getStatic 、REF_putStatic、REF_invokeStatic的方法句柄，句柄对应的类会被初始化；
上面5种场景触发类进行初始化的行动称为对1个类进行“主动援用”，除此以外，所有其他援用类的方式都不会触发初始化步骤（注意，此时已是援用了，只不过不会触发初始化，其他阶段是不是触发要看具体虚拟机的实现），这些援用称为“被动援用”。
被动援用的几个例子：
（1）对静态字段，只有直接定义这个字段的类才会被初始化，因此通过其子类来援用父类中定义的静态字段，只会触发父类的初始化而不会触发子类的初始化。至因而否要动身子类的加载、验证需要看具体虚拟机实现；以下：
class SuperClass{
static{
System.out.println("SuperClass init!");
}
public static int value = 123;
}
class SubClass extends SuperClass{
static{
System.out.println("SubClass init!");//子类中援用父类的静态字段，不会致使类初始化
}
}
public class Test {
public static void main(String[] args) {
System.out.println(SubClass.value);
}
}
运行结果：
可以看到，只会打印出父类的初始化语句。
（2）通过数组定义来援用类，不会触发此类的初始化。如 A[] ints = new A[10] ， 不会触发A 类的初始化。而是会触发名为 LA的类初始化。它是1个由虚拟机自动生成的、直接继承于Object 的子类，创建动作由字节码指令 newarray 触发。这个类代表了1个元素类型为 A 的1位数组，数组中的属性和方法都实现在这个类中。Java 语言中数组的访问比C/C++ 安全是由于这个类封装了数组元素的访问方法。以下：
public class Test {
public static void main(String[] args) {
SuperClass[] sca = new SuperClass[10];
}
}
SuperClass类为上面的那个，运行后发现并没有打印出SuperClass init!，说明没有触发SuperClass类的初始化阶段。
（3）常量在编译阶段会存入调用类的常量池中，本质上并没有直接援用到定义常量的类，因此不会触发定义常量的类的初始化，以下：
class ConstClass{
static{
System.out.println("ConstClass init!");
}
public static final String HELLOWORLD = "hello world";
}
public class Test {
public static void main(String[] args) {
System.out.println(ConstClass.HELLOWORLD);
}
}
运行结果：
只是输出了hello world，并没有输出ConstClass init!，可见ConstClass类并没有被初始化。
注意：
上面讲的3个例子是被动援用的情况，很多情况下我们会通过new来初始化1个类，这个情形它属于上面提到的5种主动援用的场景，因此会触发这个类的初始化，如果这个类有父类的话，会先触发父类的初始化。注意不要和上面的被动援用弄混了。
接口的初始化
上面代码中用static语句块进行初始化，而结构中不能使用static语句块，但是编译器依然回味接口生成<clinit>()类构造器来初始化接口中的成员变量（常量）；接口与类初始化的区分主要是在上面5种主动援用中的第3种：当1个类在初始化时，要求其父类全部已初始化过了，但是对接口的初始化来讲，并不要求其父接口全部都完成了初始化，只有在真正使用到付接口的时候（如援用接口中定义的常量）才会初始化。
3、类加载进程
3.1 加载
在加载阶段，需要完成3件事情：
（1）通过1个类的全限定名来获得其定义的2进制字节流。
（2）将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构。
（3）在内存中生成1个代表这个类的java.lang.Class对象（并没有明确规定是在java堆中，对HotSpot虚拟机来讲，Class对象比较特殊，它虽然是对象，但是寄存在方法区里面），作为对方法区中这些数据的访问入口。
对（1），并没有指明2进制字节流的获得途径，也即不1定都是从1个Class文件中获得，还可以从以下方式获得：
1）从紧缩包中获得，比如 JAR包、EAR、WAR包等
2）从网络中获得，比如红极1时的Applet技术
3）从运行进程中动态生成，最出名的便是动态代理技术，在java.lang.reflect.Proxy 中，就是用了 ProxyGenerator.generateProxyClass 来为特定接口生成情势为“$Proxy”的代理类的2进制流
4）从其它文件生成，如JSP文件生成Class 类
相对类加载进程的其他阶段，加载这1步骤是开发人员可控的，便可以通过自定义类加载器来控制加载进程。
对数组来讲，数组类本身不通过类加载器创建，它是由Java虚拟机直接创建的，但是数组的元素类型，终究是要靠类加载器去创建。
3.2 验证
验证阶段的目的是为了确保Class文件的字节流中包括的信息符合当前虚拟机的要求，并且不会危害虚拟机本身的安全。
Java语言本身是相对安全的，由于使用纯洁的java代码没法做到诸如访问数组边界意外的数据、讲1个对象转型为它并未实现的类型、跳转到不存在的代码行之类的事情，如果我们这样做了，那编译器将谢绝编译，也就保证了安全。但是前面说过，Class文件其实不1定要用Java源码编译而来，它还可以从很多途径产生，在字节码层面，其他方式可能能做到java代码没法做到的事情，因此虚拟机需要对加载尽可能的字节流进行验证。验证进程分为4步：
（1）文件格式验证
这1阶段是要验证字节流是不是符合Class文件格式的规范，并且能被当前版本的虚拟机处理。包括以下这些验证点：
- 是不是以魔数0xCAFEBABE开头
- 主、次版本号是不是在当前虚拟机处理范围以内
- 常量池的常量中是不是有不被支持的常量类型（检查常量tag标志）
- 指向常量的各种索引值中是不是有指向不存在的常量或不符合类型的常量
- CONSTANT_Utf8_info 型的常量中是不是有不符合UTF8 编码的数据
- Class 文件中各个部份和文件本身是不是有被删除的或被附加的其它信息
...
这1阶段验证的目的是保证输入的字节流能正确的解析并存储到方法区中，这阶段是基于2进制字节流进行的，通过验证后，字节流才会进入到内存的方法区中进行存储。因此，后面的3个验证阶段是基于方法区的存储结构进行分析的，不会再直接操作字节流了。
（2）元数据验证
对字节码描写的信息进行语义分析，以保证其描写的信息符合Java语言规范的要求，主要是验证类的继承关系、数据类型是不是符合，验证点包括：
- 这个类是不是有父类（除Object类外，其他所有类都应当有父类）
- 这个类的父类是不是继承了不允许被继承的类（final 修饰的类）
- 这个类如果不是抽象类，是不是实现了其父类或接口当中要求实现的所有方法
- 类中的字段、方法是不是和父类产生矛盾（如覆盖了父类final 字段，出现了非法的方法重载，如方法参数1致，但返回类型却不同）
（3）字节码验证
最复杂的1个阶段，主要目的是通过数据流和控制流分析，肯定程序语义是合法的、符合逻辑的。在元数据验证阶段对数据类型做完校验后，这个阶段将对类的方法体进行校验分析，以保证被校验类的方法在运行时不会做出危害虚拟机安全的事件，有以下1些验证点：
- 保证任什么时候候，操作数栈的数据类型与指令代码序列都能配合工作，例如不会出现类似这样的情况：在操作栈放入了1个int类型数据，使用时却按 long 类型加载到本地变量表中
- 保证跳转指令不会跳转到方法体外的字节码指令上
- 保证方法体中类型转换是有效的
（4）符号援用验证
这1阶段产生在虚拟机将符号援用转化为直接援用的时候，而这个转化动作产生在解析阶段，符号援用可以看作是对类本身之外（常量池中的各种符号援用）的信息进行匹配性校验，验证点以下：
- 符号援用中通过字符串描写的全限定名是不是能找到相应的类
- 在指定类中对否存在符合方法的字段描写符和简单名称所描写的方法和字段
- 符号援用中的类、字段、方法的访问性（private、protected、public、default）是不是可被当前类访问
这1阶段验证的目的是确保解析动作能正常履行。
对虚拟机来讲，验证阶段是1个非常重要的，但不是1定必要（由于对程序运行期没有影响）的的阶段。
3.3 准备
准备阶段是正式为类变量分配内存并设置类变量初始值的阶段，这些变量所使用的内存都将在方法区中进行分配。有两点需要注意：
（1）这阶段进行内存分配的仅包括类变量（即被static修饰的变量），不包括实例变量，实例变量会在对象实例化时随着对象1起分配在Java堆中；
（2）这里所说的初始值“通常情况”下是数据类型的零值，假定1个类变量的定义以下：
public static int value = 123;
那变量value在准备阶段过后的零值为0而不是123，由于这时候候并未履行任何Java方法，把value赋值为123的动作是在初始化阶段才会进行。对“非通常情况”，是指定义为常量的那些变量（即final修饰的），会在这1阶段就被赋值，如：
public static final int value = 123;
此时在准备阶段过后，value的值将会被赋值为123。
3.4 解析
解析阶段是虚拟机将常量池中的符号援用转化为直接援用的进程。
- 符号援用（Symbolic References）：即用1组符号来描写所援用的目标。它与虚拟机的内存布局无关，援用的目标不1定已加载到内存中。
- 直接援用（Direct References）：直接援用可以是指向目标的指针、相对偏移量或是1个能间接定位到目标的句柄。它是和虚拟机内存布局相干的，如果有了直接援用，那援用的目标一定已在内存中存在了。
解析动作主要针对 类或接口、字段、类方法、接口方法、方法类型、方法句柄 和 调用限定符 7类符号援用进行。
（1）类或接口的解析
判断所要转化成的直接援用是对数组类型，还是普通的对象类型的援用，从而进行不同的解析。
（2）字段解析
在对字段进行解析前，会先查看该字段所属的类或接口的符号援用是不是已解析过，没有就先对字段所属的接口或类进行解析。在对字段进行解析的时候，先查找本类或接口中是不是有该字段，有就直接返回；否则，再对实现的接口进行遍历，会依照继承关系从下往上递归（也就是说，每一个父接口都会走1遍）搜索各个接口和它的父接口，返回最近1个接口的直接援用；再对继承的父类进行遍历，会依照继承关系从下往上递归（也就是说，每一个父类都会走1遍）搜索各个父类，返回最近1个父类的直接援用。
（3）类方法解析
和字段解析搜索步骤差不多，只不过是先搜索父类，再搜索接口。
（4）接口方法解析
和类方法解析差不多，只不过接口中不会有父类，因此只需要对父接口进行搜索便可。
3.5 初始化
初始化是类加载进程的最后1步，此阶段才开始真正履行类中定义的Java程序代码（或说字节码，也仅限与履行<clinit>()方法）。在准备阶段，我们已给变量付过1次系统要求的初始值（零值），而在初始化阶段，则会根据程序员的意愿给类变量和其他资源赋值。主要是通过<clinit>()方法来履行的：
（1）<clinit>（）方法是由编译器自动搜集类中的所有类变量的赋值动作和静态语句块中的语句合并产生的，编译器搜集的顺序是由语句在源文件中出现的顺序所决定的，静态语句块中只能访问到定义在静态语句块之前的变量，定义在它以后的变量，在前面的静态语句中可以赋值，但是不能访问。以下：
public class Test {
static{
i = 0;//可以给变量赋值，编译通过
System.out.println(i);//编译不通过！！不能进行访问后面的静态变量
}
static int i =1;
}
有点与我们平常的认知相反，这里是可以下赋值，却不能访问...
（2）<clinit>（）方法与实例构造器<init>（）方法（类的构造函数）不同，它不需要显式地调用父类构造器，虚拟机会保证在子类的<clinit>（）方法履行之前，父类的<clinit>（）方法已履行终了。因此，在虚拟机中第1个被履行的<clinit>（）方法的类肯定是java.lang.Object。
（3）<clinit>（）方法对类或接口来讲其实不是必须的，如果1个类中没有静态语句块，也没有对类变量的赋值操作，那末编译器可以不为这个类生成<clinit>（）方法。
（4）接口中不能使用静态语句块，但依然有类变量（final static）初始化的赋值操作，因此接口与类1样会生成<clinit>（）方法。但是接口与类不同的是：履行接口的<clinit>（）方法不需要先履行父接口的<clinit>（）方法，只有当父接口中定义的变量被使用时，父接口才会被初始化。另外，接口的实现类在初始化时也1样不会履行接口的<clinit>（）方法。
（5）虚拟机会保证1个类的<clinit>（）方法在多线程环境中被正确地加锁和同步，如果多个线程同时去初始化1个类，那末只会有1个线程去履行这个类的<clinit>（）方法，其他线程都需要阻塞等待，直到活动线程履行<clinit>（）方法终了。如果在1个类的<clinit>（）方法中有耗时很长的操作，那便可能造成多个线程阻塞，在实际利用中这类阻塞常常是很隐蔽的。
4、类加载器
前面说过，在类加载进程的第1个阶段：加载阶段，除可使用系统提供的引导类加载器外，还可使用用户自定义的类加载器，以便让用户决定如何去获得所需要的类（是从Class文件中？还是从jar、或其他方式...可以自由决定）。
4.1 类和类加载器
任意1个类，都需要由加载它的类加载器和这个类本身共同肯定其在Java 虚拟机中的唯1性，每个类加载器，都具有1个独立的类名称空间。这句话可以表达的更通俗1些：比较两个类是不是相等，只有在这两个类是同1个类加载器加载的条件下才意义。否则，即便这两个类来自同1个Class文件，被同1个虚拟机加载，但只要加载他们的类加载器不同，那这两个类就一定不相等。
这里的“相等”，包括代表类的 Class 对象的equals() 方法、isAssignableFrom() 方法、isInstance() 方法的返回结果，也包括 instanceof 关键字对对象所属关系判定等情况。下面代码演示了不同类加载器对 instanceof 关键字运算的结果的影响。
public class ClassLoaderTest {
public static void main(String[] args) throws Exception {
ClassLoader myLoader = new ClassLoader() {
@Override
public Class<?> loadClass(String name)
throws ClassNotFoundException {
try {
String fileName = name.substring(name.lastIndexOf(".") + 1)
+ ".class";
InputStream is = getClass().getResourceAsStream(fileName);
if (is == null) {
return super.loadClass(name);
}
byte[] b = new byte[is.available()];
is.read(b);
return defineClass(name, b, 0, b.length);
} catch (IOException e) {
throw new ClassNotFoundException(name);
}
}
};
Class c = myLoader.loadClass("org.bupt.xiaoye.blog.ClassLoaderTest");
Object obj = c.newInstance();
System.out.println(obj.getClass());
System.out.println(ClassLoaderTest.class);
System.out.println(obj instanceof ClassLoaderTest);
}
}
运行结果以下：
class org.bupt.xiaoye.blog.ClassLoaderTest
class org.bupt.xiaoye.blog.ClassLoaderTest
false
我们使用了1个自定义的类加载器去加载ClassLoaderTest，由第1句也能够看出这个对象也的确是ClassLoaderTest实例化出来的对象，但是这个对象在与类class org.bupt.xiaoye.blog.ClassLoaderTest 做属性检查的时候却反悔了false，这就是由于虚拟机中存在了两个ClassLoaderTest类，1个由系统利用程序类加载器加载，1个由我们自定义的类加载器加载，虽然是 来自同1个Class文件，但仍然是两个独立的类。
因此，类是不是相等，取决于类本身和加载该类的类加载器是不是是同1个类加载器。
4.2 双亲委派模型
从虚拟机的角度来说，只存在两种不同的类加载器：
1种是启动类加载器（Bootstrap ClassLoader），这个类加载器用 C++ 语言实现， 是虚拟机本身的1部份：
另外一种就是所有其它的类加载器， 这些类加载器用Java 语言实现，独立于虚拟机外部，并且全都继承与抽象类 java.lang.ClassLoader。
从Java 开发人员的角度来看，类加载器还可以划分的更细致1些，绝大多数Java 程序都会用到以下3种系统提供的类加载器：
（1）启动类加载器（Bootstrap ClassLoader） ： 这个类加载器负责将寄存在 <JAVA_HOME>\lib 目录中的，或被 -Xbootclasspath 参数指定的路径中的，并且是虚拟机辨认的(仅依照文件名辨认,如rt.jar ，名字不符合类库不会加载) 类库加载到虚拟机内存中。启动类加载器没法被 java 程序直接援用，如需要，直接使用 null 代替便可。
（2）扩大类加载器（Extension ClassLoader）：这个加载器由sun.misc.Launcher$ExtClassLoader 实现，它负责加载<JAVA_HOME>\lib\ext 目录中的，或被 java.ext.dirs 系统变量所指定的路径中的所有类库，开发者可以直接使用扩大类加载器。
（3）利用程序类加载器(Application ClassLoader)：这个类加载器由 sun.misc.Launcher$AppClassLoader 实现。这个这个类加载器是 ClassLoader 中的getSystemClassLoader() 方法的返回值，所以1般称它为系统类加载器。它负责加载用户路径(ClassPath)上所指定的类库，开发者可使用这个类加载器，如果利用程序没有自定义过自己的类加载器，1般情况下这个就是程序中默许的类加载器。
我们的利用程序都是由这3中类加载器相互配合进行加载的，如果有必要，还可以加入自己定义的类加载器。这些类加载器之间的关系1般以下图所示：
图中的类加载器之间的这类层次关系，称为类加载器的双亲委派模型。双亲委派模型要求除顶层的启动类加载器，其余的类加载器都应当有自己的父类加载器。这里类加载器之间的父子关系1般不会以继承关系来实现，而是使用组合关系来复用父加载器的代码。
双亲委派模型的工作进程是：如果1个类加载器收到了类加载器的要求，它首先不会自己尝试加载这个类，而是把这个要求委派给父类加载器去完成，每个层次的类加载器都是如此，因此所有的加载要求终究都应当传送到顶层的启动类加载器中，只有当父类加载器反馈自己没法完成这个加载要求（它的搜索范围中没有找到所需的类时），子加载类才会尝试自己去加载。
使用双亲委派模型的好处：就是Java类随着它的类加载器1起具有了1种带有优先级的层次关系。比如对类Object来讲，它寄存在rt.jar中，不管哪个类加载器要加载这个类，终究都是委派给处于模型最顶真个启动类加载器去加载，因此Object类在程序中的各种类加载器环境中都是同1个类。相反，如果没有使用双亲委派模型，由各个类自己去加载的话，依照我们前面说的，如果用户自己编写了1个Object类，并放在程序的ClassPath中，那系统中将会出现多个不同的Object类，此时Java类型提示中最基础的行动也就没法保证了，利用程序也将变得混乱。
因此，双亲委派模型对保证Java程序的稳定运作很重要，但是他的实现其实很简单，实现双亲委派模型的代码几种在java.lang.ClassLoader的loadClass()方法当中，逻辑清晰易懂：先检查类是不是被加载过，若没有则调用父加载器的loadClass() 方法，若父加载器为空则默许使用启动类加载器作为父加载器。如果父加载器失败，抛出 ClassNotFoundException 异常后，再调用自己的 finClass() 方法进行加载，以下：
protected Class<?> loadClass(String name, boolean resolve)
throws ClassNotFoundException {
synchronized (getClassLoadingLock(name)) {
// 首先检查类是不是已被加载过
Class c = findLoadedClass(name);
if (c == null) {
long t0 = System.nanoTime();
try {
if (parent != null) {
// 调用父类加载器加载
c = parent.loadClass(name, false);
} else {
c = findBootstrapClassOrNull(name);
}
} catch (ClassNotFoundException e) {
// ClassNotFoundException thrown if class not found
// from the non-null parent class loader
}
if (c == null) {
// If still not found, then invoke findClass in order
// to find the class.
//父类加载器没法完成加载，调用本身的加载器加载
long t1 = System.nanoTime();
c = findClass(name);
// this is the defining class loader; record the stats
sun.misc.PerfCounter.getParentDelegationTime().addTime(
t1 - t0);
sun.misc.PerfCounter.getFindClassTime().addElapsedTimeFrom(
t1);
sun.misc.PerfCounter.getFindClasses().increment();
}
}
if (resolve) {
resolveClass(c);
}
return c;
}
}
（注：文中图片来源于：
http://blog.csdn.net/zq602316498/article/details/38871785
http://blog.csdn.net/zq602316498/article/details/38902355
）
生活不易，码农辛苦
如果您觉得本网站对您的学习有所帮助,可以手机扫描二维码进行捐赠
