JVM(一)-虚拟机类加载机制

Posted by     "zhang.xx" on October 1, 2017

If more of us valued food and cheer and song above hoarded gold, it would be a merrier world. ——John·Ronald·Reuel·Tolkien


前言

初次接触JVM,感觉深奥无比,现在对JVM有几部分内容还不是很清楚,但在java300集中只提到了类加载机制,其他的垃圾回收机制之类的都没有提及,那我暂时先把类加载机制学习并记录一下,作为研究JVM的开端。

概览

虚拟机把描述类的数据从Class文件加载到内存,并对数据进行校验、转换分析和初始化,最终形成可以被虚拟机直接使用的java类型,这就是虚拟机的类加载机制。 —《深入理解java虚拟机》

上面是类加载机制的算是定义吧,通俗一点说就是:将类的.class文件中的二进制数据读入到内存中,将其放在运行时数据区的方法区内,然后在堆区创建一个java.lang.Class对象,用来封装类在方法区内的数据结构。
类的加载的最终产品是位于堆区中的Class对象,Class对象封装了类在方法区内的数据结构,并且向Java程序员提供了访问方法区内的数据结构的接口。

类加载的时机

类的生命周期 如下图,类从被加载到虚拟机内存中开始,到卸载出内存为止,它的整个生命周期包括以下7个阶段:

  • 加载(Loading)
  • 验证(Verification)
  • 准备(Preparation)
  • 解析(Resolution)
  • 初始化(Initialization)
  • 使用(Using)
  • 卸载(Unloading)

类的生命周期

其中,前五个阶段为类的加载全过程,其中验证、准备、解析3个阶段统称为 连接(Linking)
在这五个阶段中,加载、验证、准备和初始化这四个阶段发生的顺序是确定的,而解析阶段则不一定,它在某些情况下可以在初始化阶段之后开始,这是为了支持Java语言的运行时绑定(也成为动态绑定或晚期绑定)。另外注意这里的几个阶段是按顺序开始,而不是按顺序进行或完成,因为这些阶段通常都是互相交叉地混合进行的,通常在一个阶段执行的过程中调用或激活另一个阶段。

简要说明下Java中的绑定:绑定指的是把一个方法的调用与方法所在的类(方法主体)关联起来,对java来说,绑定分为静态绑定和动态绑定:
静态绑定:即前期绑定。在程序执行前方法已经被绑定,此时由编译器或其它连接程序实现。针对java,简单的可以理解为程序编译期的绑定。java当中的方法只有final,static,private和构造方法是前期绑定的。
动态绑定:即晚期绑定,也叫运行时绑定。在运行时根据具体对象的类型进行绑定。在java中,几乎所有的方法都是后期绑定的。

对于类加载过程的第一个阶段:加载,jvm规范中并没有进行强制约束其开始时机,可交由jvm的具体实现来自由把握。但是对于初始化阶段,jvm规范严格规定了有且只有下列5种情况必须对类进行“初始化”(很自然地,加载、验证、准备需要在此之前开始):

  • 遇到newgetstaticputstaticinvokestatic这四条字节码指令时,如果类没有进行过初始化,则必须先触发其初始化。最常见的生成这4条指令的场景是:** 使用new关键字实例化对象的时候;读取或设置一个类的静态字段(被final修饰、已在编译器把结果放入常量池的静态字段除外)** 的时候;以及 调用一个类的静态方法 的时候。
  • 使用 java.lang.reflect包的方法对类进行反射调用的时候,如果类没有进行初始化,则需要先触发其初始化。
  • 当初始化一个类的时候,如果发现其父类还没有进行过初始化,则需要先触发其父类的初始化。
  • 当虚拟机启动时,用户需要制定一个要执行的 主类(包含main方法的那个类),虚拟机会先初始化这个主类;
  • 当使用jdk1.7 的动态语言支持时,如果一个java.lang.invoke.MethodHandle实例最后的解析结果REF_getStatic, REF_putStatic, REF_invokeStatic 的方法句柄,并且这个方法句柄所对应的类没有进行过初始化,则需要先触发其初始化;

以上5种场景中的行为称为对一个类进行主动引用。除此之外,所有引用类的方式都不会触发初始化,称为被动引用。被动引用的常见例子包括:

  • 通过子类引用父类的静态字段,不会导致子类初始化。
  • 通过数组定义来引用类,不会触发此类的初始化,如SuperClass[] sca = new SuperClass[10];
  • 常量 在编译阶段会存入调用类的常量池中,本质上并没有直接引用到定义常量的类,因此不会触发定义常量的类的初始化。

接口的加载过程 和类加载过程略有不同,它们真正的区别在于在前文提到的5种需要开始初始化场景中的第3种:当一个类在初始化时,要求其父类全部都已经初始化过了,但是一个接口在初始化时,并不要求其父接口全部都完成了初始化,只有在真正使用到父接口的时候(如引用接口中定义的常量)才会初始化。

类加载的过程

加载

加载类加载(Class Loading) 过程的一个阶段,两者不要混淆。虚拟机规范规定了在在加载阶段,jvm需要完成以下三件事情:

  • 通过一个类的全限定名来获取定义此类的 二进制字节流
  • 将这个字节流所代表的静态存储结构转化为 方法区的运行时存储结构
  • 在内存中生成一个代表这个类的java.lang.Class对象,作为方法区这个类的各种 数据的访问入口

这三点要求不算具体,在jvm实现时灵活度很大。例如上面的第一条,它没有指明二进制字节流要从一个Class文件中获取,准确地说没有指明要从哪里获取、怎样获取。这也为许多Java技术提供了基础,例如:

  • 从ZIP包读取,这很常见,最终成为日后JAR、EAR、WAR格式的基础。
  • 从网络中获取,这种场景最典型的应用是Applet。
  • 运行时计算生成,这种场景使用得最多得就是动态代理技术,在java.lang.reflect.Proxy中,就是用了ProxyGenerator.generateProxyClass的代理类的二进制字节流。
  • 由其他文件生成,典型场景是JSP应用,即由JSP文件生成对应的Class类。
  • 从数据库读取,这种场景相对少见,例如有些中间件服务器(如SAP Netweaver)可以选择把程序安装到数据库中来完成程序代码在集群间的分发。

相对于类加载的其他阶段而言,加载阶段(准确地说,是加载阶段获取类的二进制字节流的动作)是可控性最强的阶段,因为开发人员既可以使用系统提供的类加载器来完成加载,也可以自定义自己的类加载器来完成加载。

加载阶段完成后,虚拟机外部的二进制字节流就按照虚拟机所需的格式存储在方法区之中,而且在Java堆中也创建一个java.lang.Class类的对象,这样便可以通过该对象访问方法区中的这些数据。

连接

验证

验证是连接阶段的第一步,这一阶段的目的是确保 输入的Class文件的字节流能正确地解析并存储于方法区之内,格式上符合描述一个Java类型信息的要求,并且不会危害虚拟机自身的安全。验证阶段是否严谨,直接决定了Java虚拟机是否能承受恶意代码的攻击。 从整体上看,验证阶段大致上会完成下面四个阶段的检验动作:

  • 文件格式验证:验证字节流是否符合Class文件格式的规范;例如:是否以0xCAFEBABE开头、主次版本号是否在当前虚拟机的处理范围之内、常量池中的常量是否有不被支持的类型。
  • 元数据验证:对字节码描述的信息进行语义分析(注意:对比javac编译阶段的语义分析),以保证其描述的信息符合Java语言规范的要求;例如:这个类是否有父类,除了java.lang.Object之外。
  • 字节码验证:通过数据流和控制流分析,确定程序语义是合法的、符合逻辑的。
  • 符号引用验证:确保解析动作能正确执行。

对于jvm的类加载机制来说,验证阶段是一个非常重要但不是一定必要(因为对运行期没有影响)的阶段。如果所运行的全部代码都已经被反复验证过,那么在实施阶段就可以考虑使用`-Xverify:none`参数来关闭大部分的类验证措施,以缩短虚拟机类加载的时间。

准备

为类的 静态变量 分配内存,并将其初始化为默认值

准备阶段是正式为类变量分配内存并设置类变量初始值的阶段,这些内存都将在方法区中分配。对于该阶段有以下几点需要注意:

  • 1、这时候进行内存分配的仅包括类变量(static),而不包括实例变量,实例变量会在对象实例化时随着对象一块分配在Java堆中。
  • 2、这里所设置的初始值通常情况下是数据类型默认的零值(如0、0L、null、false等),而不是被在Java代码中被显式地赋予的值。

假设一个类变量的定义为:

public static int value = 123;

那变量value在准备阶段过后的初始值为0而不是123,因为这时候尚未开始执行任何Java方法,而把value赋值为123的putstatic指令是程序被编译后,存放于类构造器<clinit>()方法之中,所以把value赋值为123的动作在 初始化阶段 才会执行。 值得注意的是,如果类字段的字段属性中存在ConstantValue属性(即同时被final和static修饰),那在准备阶段变量value就会被初始化为ConstantValue属性所指定的值,假设上面类变量value的定义变为:

public static final int value = 123;

编译时 Javac将会为value生成ConstantValue属性,在准备阶段虚拟机就会根据ConstantValue的设置将value赋值为123。

解析

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

  • 符号引用(Symbol References): 符号引用以一组符号来描述所引用的目标符号 可以是 任何形式的字面量,只要使用时能无歧义地定位到目标即可。符号引用与虚拟机实现的内存布局无关,引用的目标并不一定已经加载到内存中。各种虚拟机实现的内存布局可以各不相同,但是它们能接受的符号引用必须一致,因为符号引用的字面量形式明确定义在Java虚拟机规范的Class文件格式中
  • 直接引用(Direct References): 直接引用可以是直接目标的指针相对偏移量 或是一个 能间接定位到目标的句柄。直接引用是和虚拟机实现的内存布局有关的,同一个符号引用在不同虚拟机实例上翻译出来的直接引用一般不会相同。如果有了直接引用,那么引用的目标必定已经在内存中存在。

虚拟机规范并未规定解析动作发生的具体时间,仅要求在执行anewarray、checkcast、getfield、getstatic、instanceof、invokeinterface、invokespecial、invokestatic、invokevirtual、multianewarray、new、putfield和putstatic这13个用于操作符号引用的字节码指令之前,先对它们所使用的符号引用进行解析。所以虚拟机实现可以根据需要来判断到底是在类被加载器加载时就对常量池中的符号进行解析,还是等到一个符号引用将要被使用前才去解析它。

对同一个符号引用进行多次解析请求 是很常见的,除 invokedynamic 指令外( invokedynamic指令是用于动态语言支持的,它所对应的引用称为 “动态调用点限定符”,必须等到程序实际运行到这条指令的时候,解析动作才能进行)虚拟机实现可能会对第一次解析的结果进行 缓存(将直接引用保存在运行时常量池中),无论是否真正执行了多次解析动作,虚拟机实现必须保证在同一个实体中,如果一个符号引用之前已经被成功解析过,后续的引用解析请求就应当一直成功,反之亦然。

解析动作主要针对以下7类符号引用

  • 类或接口
  • 字段
  • 类方法(静态方法)
  • 接口方法
  • 方法类型
  • 方法句柄
  • 调用点限定符

其中后三种与java的动态语言支持息息相关。

书上只写了前四种的解析,是不是书的版本太老了(2011),需查阅新的版本书籍。

初始化

类初始化阶段是“类加载过程”中最后一步,在之前的阶段,除了在加载阶段用户应用程序可以通过自定义类加载器参与之外,其它动作完全由虚拟机主导和控制,直到初始化阶段,才真正开始 执行类中定义的Java程序代码(或者说是字节码)

在准备阶段,变量已经赋过一次系统要求的初始值,而在初始化阶段,根据程序员通过程序制定的主观计划去初始化类变量和其它资源,简单说,初始化阶段即虚拟机执行类构造器<clinit>()方法的过程

下面来详细讲解<clinit>()方法是怎么生成的,首先来了解此方法执行过程中可能会影响到程序运行行为的特点和细节:

  • <clinit>()方法是由编译器自动收集类中所有类变量的赋值动作和静态语句块(static{} 块)中的语句合并产生的,编译器收集的顺序由语句在源文件中出现的顺序决定,特别注意的是,静态语句块只能访问到定义在它之前的类变量,定义在它之后的类变量只能赋值,不能访问。例如以下代码:
public class Test {
    static {
        i = 0;  //  给变量复制可以正常编译通过
        System.out.print(i);  // 这句编译器会提示“非法向前引用”  
    }
    static int i = 1;
}
  • <clinit>()方法与类的构造函数(或者说实例构造器<init>() 方法)不同,不需要显式的调用父类的()方法。虚拟机会自动保证在子类的<clinit>()方法运行之前,父类的<clinit>()方法已经执行结束。因此虚拟机中第一个执行<clinit>()方法的类肯定为java.lang.Object
  • 由于父类的<clinit>()方法先执行,也就意味着父类中定义的静态语句块要优于子类的变量赋值操作。例如以下代码:
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(Sub.B);//输出结果是父类中的静态变量值A,也就是2
}
  • <clinit>()方法对于类或接口不是必须的,如果一个类中不包含静态语句块,也没有对类变量的赋值操作,编译器可以不为该类生成<clinit>()方法。
  • 接口中不可以使用静态语句块,但仍然有类变量初始化的赋值操作,因此接口与类一样都会生成<clinit>()方法。但接口与类不同的是,执行接口的<clinit>()方法不需要先执行父接口的<clinit>()方法。只有当父接口中定义的变量使用时,父接口才会初始化。另外,接口的实现类在初始化时也一样不会执行接口的<clinit>()方法。
  • 虚拟机会保证一个类的<clinit>()方法在多线程环境下被正确的加锁和同步,如果多个线程同时初始化一个类,只会有一个线程执行这个类的<clinit>()方法,其它线程都会阻塞等待,直到活动线程执行<clinit>()方法完毕。如果在一个类的<clinit>()方法中有耗时的操作,就可能造成多个进程阻塞,在实际过程中此种阻塞很隐蔽。

类加载器

类加载器在类层次划分,OSGi、热部署、代码加密等领域大放异彩,成为了java体系中的一块重要基石。

类与类加载器

对于任意一个类,都需要有加载它的类加载器和这个类一同确定其在java虚拟机中的唯一性。
即:比较两个类是否’相等’,只有在这两个类是由同一个类加载器加载的前提下才有意义,否则,即使这两个类是来源于同一个Class文件,只要加载它们的类加载器不同,那么,这两个类就必定不相等。

双亲委派模型

站在Java虚拟机的角度来讲,只存在两种不同的类加载器:启动类加载器:它使用C++实现(这里仅限于Hotspot,也就是JDK1.5之后默认的虚拟机,有很多其他的虚拟机是用Java语言实现的),是虚拟机自身的一部分;所有其它的类加载器:这些类加载器都由Java语言实现,独立于虚拟机之外,并且全部继承自抽象类java.lang.ClassLoader,这些类加载器需要由启动类加载器加载到内存中之后才能去加载其他的类。

站在Java开发人员的角度来看,类加载器可以大致划分为以下三类:

启动类加载器Bootstrap ClassLoader,负责加载存放在JDK\jre\lib(JDK代表JDK的安装目录,下同)下,或被-Xbootclasspath参数指定的路径中的,并且能被虚拟机识别的类库(如rt.jar,所有的java.开头的类均被Bootstrap ClassLoader加载)。启动类加载器是无法被Java程序直接引用的。
扩展类加载器Extension ClassLoader,该加载器由sun.misc.Launcher$ExtClassLoader实现,它负责加载JDK\jre\lib\ext目录中,或者由java.ext.dirs系统变量指定的路径中的所有类库(如javax.开头的类),开发者可以直接使用扩展类加载器。 应用程序类加载器Application ClassLoader,该类加载器由sun.misc.Launcher$AppClassLoader来实现,它负责加载用户类路径(ClassPath)所指定的类,开发者可以直接使用该类加载器,如果应用程序中没有自定义过自己的类加载器,一般情况下这个就是程序中默认的类加载器。

应用程序都是由这三种类加载器互相配合进行加载的,如果有必要,我们还可以加入 自定义的类加载器 。因为JVM自带的ClassLoader只是懂得从本地文件系统加载标准的java class文件,因此如果编写了自己的ClassLoader,便可以做到如下几点:

1、在执行非置信代码之前,自动验证数字签名。 2、动态地创建符合用户特定需要的定制化构建类。 3、从特定的场所取得java class,例如数据库中和网络中。

双亲委派模型的工作流程是:如果一个类加载器收到了类加载的请求,它首先不会自己去尝试加载这个类,而是把请求委托给父加载器去完成,依次向上,因此,所有的类加载请求最终都应该被传递到顶层的启动类加载器中,只有当父加载器在它的搜索范围中没有找到所需的类时,即无法完成该加载,子加载器才会尝试自己去加载该类。

双亲委派机制:

1、当AppClassLoader加载一个class时,它首先不会自己去尝试加载这个类,而是把类加载请求委派给父类加载器ExtClassLoader去完成。 2、当ExtClassLoader加载一个class时,它首先也不会自己去尝试加载这个类,而是把类加载请求委派给BootStrapClassLoader去完成。 3、如果BootStrapClassLoader加载失败(例如在$JAVA_HOME/jre/lib里未查找到该class),会使用ExtClassLoader来尝试加载; 4、若ExtClassLoader也加载失败,则会使用AppClassLoader来加载,如果AppClassLoader也加载失败,则会报出异常ClassNotFoundException。

双亲委派模型意义:

  • 系统类防止内存中出现多份同样的字节码
  • 保证Java程序安全稳定运行

ClassLoader源码:

    protected Class<?> loadClass(String name, boolean resolve)
        throws ClassNotFoundException
    {
        synchronized (getClassLoadingLock(name)) {
            // First, check if the class has already been loaded
            // 首先判断该类型是否已经被加载
            Class<?> c = findLoadedClass(name);
            if (c == null) {
                long t0 = System.nanoTime();
                // 如果没有被加载,就委托给父类加载或者委派给启动类加载器加载
                try {
                    if (parent != null) {
                        // 如果存在父类加载器,就委派给父类加载器加载
                        c = parent.loadClass(name, false);
                    } else {
                        // 如果不存在父类加载器,就检查是否是由启动类加载器加载的类,通过调用本地方法native Class findBootstrapClass(String name)
                        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;
        }
    }

破坏双亲委派模型

自定义类加载器

  TODO:待添加代码

自定义类加载器的核心在于对字节码文件的获取,如果是加密的字节码则需要在该类中对文件进行解密。由于这里只是演示,我并未对class文件进行加密,因此没有解密的过程。这里有几点需要注意:

1、这里传递的文件名需要是类的全限定性名称,即com.paddx.test.classloading.Test格式的,因为 defineClass 方法是按这种格式进行处理的。 2、最好不要重写loadClass方法,因为这样容易破坏双亲委托模式。 3、这类Test 类本身可以被 AppClassLoader类加载,因此我们不能把com/paddx/test/classloading/Test.class放在类路径下。否则,由于双亲委托机制的存在,会直接导致该类由AppClassLoader加载,而不会通过我们自定义类加载器来加载。

总结与参考

参考了尚学堂高淇的JVM核心机制视频集218-223,以及下面相关博客
代码示例在jdk1.8下编译通过

参考:

jvm系列(一):java类的加载机制
【深入Java虚拟机】之四:类加载机制
深入理解JVM(5)——虚拟机类加载机制
深入理解Java虚拟机——JVM高级特性与最佳实践

2017年10月-by zhang.xx