虚拟机类加载机制

2016-10-29 老王和小杨 Java JVM虚拟机评论字数统计: 3.9k(字) 阅读时长: 15(分)

虚拟机类加载机制概念

虚拟机把描述类的数据从Class文件中读取到内存，并对数据进行校验、转换解析和初始化，最终形成可以被虚拟机直接使用的java类型，这就是虚拟机类加载机制。这个过程在程序运行期间完成。

类加载的时机

类从被加载到虚拟机内存中开始，到卸载出内存为止，整个生命周期包括：

加载（Loading）
验证（Verification）
准备（Prepareation）
解析（Resolution）
初始化（Initialization）
使用（Using）
卸载（Unloading）

==其中：验证、准备解析3个部分统称为连接（Linking）==

为了支持Java语言的运行时绑定（动态绑定），解析阶段不一定按部就班执行，在一些情况下它可以再初始化阶段之后开始。

有且仅有以下5种情况，必须立即对类进行初始化：
在遇到new、getstatic、putstatic或invokestatic这4条字节码指令时，如果类没有进行过初始化，则需要先出发其初始化（即加载、验证、准备也需要在这之前开始）。最常见的Java代码场景是：new对象、读取或设置一个类的静态字段（被final修饰、已在编译器把结果放入常量池的静态字段除外）的时候，以及调用一个类的静态方法的时候。
使用java.lang.reflect包的方法对类进行反射调用时，如果类没有进行过初始化，则需要先出发其初始化。
当初始化一个类的时候，如果发现其父类还没有进行过初始化，则需要先出发其父类的初始化。
当虚拟机启动时，用户需要制定一个要执行的主类（包含main()方法的类），虚拟机会先初始化这个主类。

当使用JDK1.7的动态语言支持时，如果一个java.lang.invoke.MethodHandle实例最后的解析结果REF_getStatic、REF_putStatic、REF_invokeStatic的方法句柄，并且这个句柄所对应的类没有进行过初始化，则需要先触发其初始化。

被动引用的例子

例1：使用子类直接调用父类的静态属性，因为该静态属性是在父类中定义的，所以不会在子类初始化。对于静态字段，只有直接定义这个字段的类才会被初始化。

package com.laowang.vm.classloader;

public class SuperClass {
    static{
        System.out.println("I'm super class!");
    }
    public static int value = 123;
}
class SubClass extends SuperClass{
    static{
        System.out.println("I'm sub class!");
    }

}
package com.laowang.vm.classloader;

public class NotInitialization {
    public static void main(String[] args) {
        System.out.println(SubClass.value);
    }
}

运行结果：

"D:\Program Files (x86)\Java\jdk1.8.0_171\bin\java.exe" ...
I'm super class!
123

Process finished with exit code 0

例2：复用以上的SuperClass，使用数组定义来引用类，也不会触发此类的初始化。但，它会触发另外一个名为”[Lcom.laowang.vm.classloader.SuperClass”的类的初始化阶段，这个类是由虚拟机自动生成、直接继承于java.lang.Object的子类，创建动作由字节码newarray触发。

package com.laowang.vm.classloader;

public class NotInitialization {
    public static void main(String[] args) {
        //System.out.println(SubClass.value);
        SuperClass[] sca = new SuperClass[10];
    }
}

运行结果：

1
2
3

"D:\Program Files (x86)\Java\jdk1.8.0_171\bin\java.exe" ...

Process finished with exit code 0

例3：常量在编译阶段会存入调用类的常量池中，本质上并没有直接引用到定义常量的类，因此不会触发定义常量的类的初始化。

public class ConstantClass {
    static{
        System.out.println("ConstantClass init!");
    }
    public static final String HELLOWORLD = "hello world!";
}

public class NotInitialization {
    public static void main(String[] args) {
        //System.out.println(SubClass.value);
        //SuperClass[] sca = new SuperClass[10];
        System.out.println(ConstantClass.HELLOWORLD);
    }
}

运行结果：

"D:\Program Files (x86)\Java\jdk1.8.0_171\bin\java.exe" ...
hello world!

Process finished with exit code 0

类加载过程

加载

通过一个类的全限定名来获取定义此类的二进制字节流。
将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构。
在内存中生成一个代表这个类的java.lang.Class对象，作为方法区这个类的各种数据的访问入口。
验证
验证是连接阶段的第一步，这一阶段的目的是为了确保Class文件的字节流中包含的信息符合当前虚拟机要求，并且不会危害虚拟机自身的安全。

验证阶段大致分为以下四个：
文件格式验证
验证是否符合Class文件格式的规范，并且能够被当前版本的虚拟机处理。只有这个阶段是基于二进制流的方式进行的，其他的阶段都是基于方法区的存储结构进行的。包括以下几个验证点：
是否以魔数0xCAFEBABE开头。
主、次版本号是否在当前虚拟机处理范围之内。
常量池的常量中是否有不被支持的常量类型（检查常量tag标志）。
指向常量的各种索引值中是否有指向不存在的常量或不符合类型的常量。
CONSTANT_Utf8_info型的常量中是否有不符合UTF8编码的数据。
Class文件中各个部分及文件本身是否有被删除的或附加的其他信息。
…
元数据验证
对字节码描述的信息进行语义分析，以保证其描述的信息符合Java语言规范的要求，包括以下几点：
是否有父类
父类是否继承了不允许被继承的类（final修饰）
如果这个类不是抽象类，是否实现了其父类或接口之中要求实现的所有方法。
类中的字段、方法是否与父类产生矛盾。
…
字节码验证
整个验证过程中最复杂的一个阶段，主要目的是通过数据流和控制流分析确定程序语义是否是合法的、符合逻辑的。如以下几点：
保证任意时刻操作数栈的数据类型与指令代码序列都能配合工作。
保证跳转指令不会跳转到方法体以外的字节码指令上。
保证方法体中的类型转换是有效的。
…
符号引用验证
发生在虚拟机将符号引用转化为直接引用的时候，这个转化动作将在连接的第三阶段-解析阶段中发生。符号引用验证可以看做是对类自身以外的信息进行匹配性校验。通常校验以下内容：
符号引用中通过字符串描述的全限定名是否能找到对应的类。
在指定类中是否存在符合方法的字段描述符以及简单名称所描述的方法和字段。
符号引用中的类、字段、方法的访问性是否可以被当前类访问。
…
可以使用-Xveriy:none参数来关闭大部分的类验证措施，缩短虚拟机类加载的时间。
准备
正式为类变量分配内存并设置类变量初始值的阶段，这些变量所使用的内存都将在方法区中进行分配。
如：
1
public static int value = 123;

在准备阶段，value的初始值为0（通常情况下）,而不是123。因为这个时候尚未开始执行任何Java方法，而赋值为123的putstatic指令时程序被编译后，存放于类构造器,()方法中，所以把value赋值为123的动作是在初始化阶段才会执行。
相对于通常情况下，有一些特殊情况。如果类字段的字段属性表中存在ConstantValue属性，那么就在准备阶段就会被赋值为ConstantValue的值。如：

1	public static final int value = 123;

编译时Javac将会为value生成ConstantValue属性，这段代码就会在准备阶段为value赋值为ConstantValue的值。

解析

解析阶段是虚拟机将常量池内的符号引用替换为直接引用的过程。

符号引用(Symbolic References)：与虚拟机实现的内存布局无关，引用的目标不一定已经加载到内存中。各种虚拟机实现的内存布局可能不同，但是能接受的符号引用必须一致，因为符号引用的字面量形式明确定义在Java虚拟机规范的Class文件格式中。
直接引用(Direct References)：与迅疾实现的内存布局相关，同一个符号引用在不同的虚拟机实例上翻译出来的直接引用一般不会相同。如果有了直接引用，那引用的目标必定已经存在内存中。
- 类或接口解析
- 字段解析
- 类方法解析
- 接口方法解析
  初始化
  真正开始执行类中定义的Java程序代码（或者说是字节码），这是类加载过程的最后一步。
()方法（执行类构造器方法）是由编译器自动收集类中的所有类变量的赋值动作和静态语句块(static{}块)中的语句合并产生的。收集顺序是由语句在源文件中出现的顺序所决定。静态语句块中只能访问定义在静态语句块之前的变量，定义在之后的比那辆，只能赋值，但不能访问。如以下代码所示：
1
2
3
4
5
6
7
public class Test {
static{
i = 0;//正常编译
System.out.println(i);//报 illegal forward reference（非法向前引用）
}
static int i = 1;
}
()方法与类的构造函数（或者说实例构造器()方法）不同，它不需要显式地调用父类构造器，虚拟机会保证在子类的()方法执行前，父类的()方法已经执行完毕。因此在虚拟机中第一个被执行的()方法的类肯定是java.lang.Object。

由于父类的()方法先执行，也就意味着父类中定义的静态语句块要优先于子类的变量赋值操作，如以下代码所示：

public class Test2 {
    static class Parent{
        public static int A = 1;
        static{
            A = 2;
        }
    static class Sub extends Parent {
            public static int B = A;
        }
    }

    public static void main(String[] args) {
        System.out.println(Parent.Sub.B);
    }
}

运行结果：

因为父类在进行初始化的时候，会在静态代码块中将A的赋值为2。因为这个过程顺序是优于子类的。

()方法对于类或接口来说并不是必需的，如果一个类中没有静态语句块，也没有对变量的赋值才做，那么编译器可以不为这个类生成()方法。
接口中不能使用静态语句块，但仍然有变量初始化的赋值操作，因此接口与类一样都会生成()方法。只有当父接口中定义的变量使用时，父接口才会初始化。这与普通的类不同。接口的实现类在初始化时也一样不会执行接口的()方法。

虚拟机会保证一个类的()方法在多线程环境中被正确地加锁、同步，如果多个线程同时去初始化一个类，那么只有一个线程会去执行这个类的()方法，其他线程阻塞。如以下代码所示：

public class Clinit {
    static class DeadLoopClass {
        static {
            if (true) {
                System.out.println(Thread.currentThread() + "init DeadLoopClass");
                while (true) {
                }
            }
        }
    }

    public static void main(String[] args) {
        Runnable script = new Runnable() {
            @Override
            public void run() {
                System.out.println(Thread.currentThread() + "start");
                DeadLoopClass dlc = new DeadLoopClass();
                System.out.println(Thread.currentThread() + "run over");
            }
        };
        Thread thread1 = new Thread(script);
        Thread thread2 = new Thread(script);
        thread1.start();
        thread2.start();
    }
}

运行结果如下，死循环：

1
2
3

Thread[Thread-1,5,main]start
Thread[Thread-0,5,main]start
Thread[Thread-1,5,main]init DeadLoopClass

类加载器

类与类加载器

判断两个类是否相等，是需要建立在同一个类加载器加载的前提下。也就是说，如果两个类的Class文件一样，被同一个虚拟机加载，只要他们的类加载器不同，那么这两个类必定不相等。

相等包括：

equals()方法
isAssignableFrom()方法
isInstance()方法的返回结果。

instanceof
例：

package com.laowang.vm.classloader;

import java.io.IOException;
import java.io.InputStream;

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);
                }
            }
        };
        Object obj = myLoader.loadClass("com.laowang.vm.classloader.ClassLoaderTest").newInstance();
        System.out.println(obj.getClass());
        System.out.println(obj instanceof com.laowang.vm.classloader.ClassLoaderTest);
    }
}

运行结果：

class com.laowang.vm.classloader.ClassLoaderTest
false

Process finished with exit code 0

双亲委派模型

从Java虚拟机的角度来讲，只存在两种不同的类加载器：

BootstrapClassLoader：启动类加载器，这个类加载器由C++语言实现，是虚拟机自身的一部分。
所有其他的类加载器：这些类加载器由Java语言实现，独立于虚拟机外部，并且全部继承自java.lang.ClassLoader。

但从Java开发人员的角度来看，类可以分为更细致一些，基本上分为以下3种系统提供的类加载器：

BootstrapClassLoader：放在<JAVA_HOME>\lib目录中，或者被-Xbootclasspath参数所指定的目录中，并且被虚拟机按照名字识别，名字不符合的即使放在lib目录下也不会被加载。
Extension ClassLoader：这个加载器由sun.misc.Laucher$ExtClassLoader实现，它负责加载<JAVA_HOME>\lib\ext目录中的类库，或者被java.ext.dirs系统变量所指定的路径中的所有类库，开发者可以直接使用扩展类的加载器。
Application ClassLoader：这个类加载器由sun.misc.Laucher$AppClassLoader实现。由于这个类加载器是ClassLoader中的getSystemClassLoader()方法的返回值，所以一般也称它为系统类加载器。它负责加载用户类路径classpath上所指定的类库，开发者可以直接使用这个类加载器，如果应用程序中没有自定义过自己的类加载器，一般情况下这个就是程序中默认的类加载器。
双亲委派模型的工作过程
如果一个类加载器收到了类加载的请求，它首先不会自己去尝试加载这个类，而是把这个请求委派给父类加载器去完成，每一个层次的类加载器都是如此，因此所有的加载请求最终都应该传送到顶层的BootstrapClassLoader中，只有当父加载器反馈自己无法完成这个加载请求的时候，子加载器才会尝试自己去加载。
比如，java.lang.Object类，它在rt.jar中，无论哪一个类加载器要加载这个类，最终都是委派给BootstrapClassLoader进行加载，因此Object类在程序的各种类加载器环境中都是同一个类。相反，如果不是双亲委派模型，由各个类加载器自行去加载的话，如果用户自己编写了一个java.lang.Object类，并放在程序的classpath中，那系统中将会出现多个不同的Object，Java类型体系中最基础的行为也就无法保证。
破坏双亲委派模型*
JDK1.2以前
线程上下问类加载器（Thread Context ClassLoader）
OSGi：Bundle实现热部署。

本文链接： https://blog.mmzsblog.cn/Java/虚拟机类加载机制/

版权声明： 本博客所有文章除特别声明外，均采用 CC BY 4.0 CN协议许可协议。转载请注明出处！

mmzsblogWeb Developer & Java Developer

这里是一群热爱技术的人儿！这里只聊技术，不聊其它，因为没有比编程更纯粹的事了。

虚拟机类加载机制

虚拟机类加载机制概念

类加载的时机

被动引用的例子

类加载过程

加载

验证

文件格式验证

元数据验证

字节码验证

符号引用验证

准备

解析

初始化

类加载器

类与类加载器

双亲委派模型

双亲委派模型的工作过程

破坏双亲委派模型*

mmzsblogWeb Developer & Java Developer