精华内容
下载资源
问答
  • Java虚拟机 类加载过程与机制

    千次阅读 2016-04-25 23:35:14
    虚拟机类加载机制:虚拟机把描述的数据从class文件加载到内存,并对数据进行校验、转换解析和初始化,最终形成可以被虚拟机直接使用的Java类型。 Java语言里,类型的加载和连接过程是在程序运行期间完成的。 ...

    一、ClassLoader基本概念


        与C或C++编写的程序不同,Java程序并不是一个可执行文件,而是由许多独立的类文件组成的,每一个文件对应一个Java类。此外,这些类文件并非全部装入内存,而是根据程序需要逐渐载入。ClassLoader在JVM运行的时候加载Java核心的API,以满足Java程序最基本的需求,其中就包括用户定义的ClassLoader。

        这里所谓的用户定义,是指通过Java程序实现的两个ClassLoader:一个是ExtClassLoader,它的作用是用来加载Java的扩展API,也就是/lib/ext中的类;第二个是APPClassLoader,它是用来加载用户机器上CLASSPATH设置目录只能给的Class的,通常在没有指定ClassLoader的情况下,程序员自定义的类就由该ClassLoader进行加载。


    二、ClassLoader加载流程


        当运行一个程序的时候,JVM启动,运行bootstrap classloader,该ClassLoader加载Java核心API(ExtClassLoader和AppClassLoader也在此时被加载),然后调用ExtClassLoader加载扩展API,③最后AppClassLoader加载CLASSPATH目录下定义的Class,这就是一个程序最基本的加载流程。



    三、类的加载过程(摘自此处)


        虚拟机类加载机制:虚拟机把描述类的数据从class文件加载到内存,并对数据进行校验、转换解析和初始化,最终形成可以被虚拟机直接使用的Java类型。

        Java语言里,类型的加载和连接过程是在程序运行期间完成的。


    类的生命周期

      加载 loading

      验证 verification

      准备 preparation

      解析 resolution

      初始化 initialization

      使用 using

      卸载 unloading



    有且只有以下四种情况必须立即对类进行”初始化”(称为对一个类进行主动引用):

    1.遇到new、getstatic、putstatic、invokestatic这四条字节码指令时(使用new实例化对象的时候、读取或设置一个类的静态字段、调用一个类的静态方法)。


    2.使用java.lang.reflet包的方法对类进行反射调用的时候。


    3.当初始化一个类的时候,如果发现其负类没有进行过初始化,则需要先触发其父类的初始化。


    4.当虚拟机启动时,虚拟机会初始化主类(包含main方法的那个类)。
     


    被动引用

    1.通过子类引用父类的静态字段,不会导致子类初始化(对于静态字段,只有直接定义这个字段的类才会被初始化)。


    2.通过数组定义类应用类:ClassA [] array=new ClassA[10]。触发了一个名为[LClassA的类的初始化,它是一个由虚拟机自动生成的、直接继承于Object的类,创建动作由字节码指令newarray触发。


    3.常量会在编译阶段存入调用类的常量池。
     

    编译器会为接口生成<clinit>()构造器,用于初始化接口中定义的成员变量。一个接口在初始化时,并不要求其父类接口全部完成了初始化,只有在真正使用到父接口的时候才会初始化。


    (1) 加载

    1.通过一个类的全限定名来获取此类的二进制字节流。


    2.将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构。


    3.在java堆中生成一个代表这个类的Class对象,作为方法区这些数据的访问入口。
     

    (2) 验证

        验证:确保Class文件的字节流中包含的信息符合当前虚拟机的要求,并且不会危害虚拟机自身的安全。

    (包括:文件格式验证、元数据验证、字节码验证和符号引用验证)


    虚拟机规范:如果验证到输入的字节流不符合Class文件的存储格式,就抛出一个java.lang.VerifyError异常或其子类异常。



    (3) 准备

        准备阶段是正式为类变量分配内存并设置类变量初始值(各数据类型的零值)的阶段,这些内存将在方法区中进行分配。但是如果类字段的字段属性表中存在ConstantValue属性,那在准备阶段变量值就会初始化为ConstantValue属性指定的值。


        public static final int value=122;


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

        符号引用:符号引用以一组符号来描述所引用的目标,符号可以是任何形式的字面量,只要使用时能无歧义地定位到目标即可。符号引用与虚拟机实现的内存布局无关,引用的目标并不一定已经加载到内存中。

        直接引用:直接引用可以是直接指向目标的指针、相对偏移量或者一个能间接定位到目标的句柄。如果有了直接引用,那引用的目标必定已经在内存中存在。



    (5) 初始化
        初始化阶段是执行类构造器<clinit>()方法的过程。

    1.<clinit>()方法是由编译器自动收集类中的所有类变量的赋值动作和静态语句块(static{}块)中的语句合并产生的,编译器收集的顺序是由语句在源文件中出现的顺序决定的。静态语句块只能访问到定义在静态语句块之前的变量,定义在它之后的变量,在前面的静态语句块中可以赋值,但是不能访问。
     

    2. 方法与实例构造器<init>()不同,不需要显示的调用父类构造器,虚拟机会保证在子类的<clinit>()方法执行之前,父类的<clinit>()已经执行完毕。


    3. <clinit>()方法对于类或接口来说不是必须的,如果一个类中没有静态语句块也没有对变量的赋值操作,那么编译器可以不为这个类生成<clinit>()方法。


    4. 执行接口的<clinit>()不需要先执行父接口的<clinit>()方法,只有当父接口中定义的变量被使用时,父接口才会被初始化。接口的实现类在初始化时也不会执行接口的<clinit>()方法。


    5. 虚拟机会保证一个类的<clinit>()方法在多线程环境中被正确的加锁和同步,如果多个线程同时去初始化一个类,则只会有一个线程去执行这个类的<clinit>()方法,其他线程需要阻塞等待。


    四、类的加载机制


        JVM在加载类时默认采用的是父类委托模式。通俗的讲,就是某个特定的类加载器在接到加载类的请求时,首先将加载任务委托给父类加载器,依次递归,如果父类加载器可以完成类加载任务,就成功返回;只有父类加载器无法完成此加载任务时,才自己去加载。



    使用父类委托模式的原因:

    1.可以避免重复加载,当父类已经加载了该类的时候,就没有必要子ClassLoader再加载一次。

    2.如果不使用这种委托模式,那么可以随时使用自定义的String来动态替代Java核心API中定义的类型,这样会存在非常大的安全隐患,而父类委托的方式就可以避免这种情况,因为String已经在启动时被加载,所以,用户自定义类是无法加载一个自定义的ClassLoader。


    五、总结(摘自此处)


        类加载器是 Java 语言的一个创新。它使得动态安装和更新软件组件成为可能。类加载器的相关话题包括基本概念、代理模式、线程上下文类加载器、与 Web 容器和 OSGi 的关系等。开发人员在遇到ClassNotFoundException和 NoClassDefFoundError等异常的时候,应该检查抛出异常的类的类加类加载器是 Java 语言的一个创新。它使得动态安装和更新软件组件成为可能。


    参考文献:

    http://www.cnblogs.com/yshb/archive/2012/11/05/2756194.html

    http://blog.csdn.net/zhoudaxia/article/details/35824249#t3

    http://www.ibm.com/developerworks/cn/java/j-lo-classloader/

    《Java程序员面试宝典》




    展开全文
  • 一、虚拟机的加载机制 二、虚拟机加载过程 三、加载之后在内存中 初始化详解 加载器 附加:父类委托机制

    读书笔记加自我总结-----------------------------------------------

    《疯狂JAVAj讲义》

    《深入理解JAVA虚拟机》第七章虚拟机加载机制

    《传智播客Java底层公开课视频》教学视频

    参考:


    一、虚拟机的类加载机制

            

    加载  连接   初始化    ------------> 程序运行期完成

    坏处:                        好处:

    性能开销                   灵活性大大增强



    二、虚拟机加载的过程如下






    三、加载之后在内存中的样子


    假设现在有这样一个类

    public class Demo {
    
    	public static void main(String[] args) {
    		new Person();
    	}
    
    }
    
    class Person{
    	private int age;
    	
    	public Person()
    	{
    		System.out.println("this is Person Construct Method");
    	}
    }
    
    class Animal{
    	public static String name;
    	
    }

    它在经过加载之后大致在内存中就如下:(非官方图,个人意淫)



    至于new一个类之后在堆中内存怎么存放,咱们下节再细说



    四、过程5初始化

    自动收集1.类变量赋值,2静态语句块  形成<clinit>方法,各语句的顺序按照在类文件中出现的顺序


    虚拟机会保证一个类的<clinit>()方法在多线程环境被正确的加锁、同步。

    如果多线程同时初始化一个类,只会一个线程执行<clinit>()方法,其他线程阻塞等待。执行的线程执行结束后,其它线程唤醒之后不会再进入<clinit>()。同一个类加载器下,一个类只会初始化一次。




    五、过程1加载:加载器

    过程1由一个特定的组件进行完成:类加载器


    除了加载阶段(图1的阶段1)用户应用程序可以通过自定义加载器参与,剩下的动作完全由虚拟机主导控制

    也就是说类加载器的工作就是“通过一个类的全类名来获取描述此类的二进制字节流”


    有三类加载器:参见我的上一篇博客: 

    深入理解jre,classload,类加载过程


    ClassLoader是一个抽象类

    public abstract class ClassLoader

    JVM中除根加载器之外的所有加载器都是ClassLoader子类的实例


    个人认为它大致有两类方法

    1.静态的工具方法

    比如

    可以通过ClassLoader.getSystemClassLoader();获得AppClass Loader(系统类加载器)

    @CallerSensitive
        public static ClassLoader getSystemClassLoader()

    getParent()获取该加载器的父类加载器

    @CallerSensitive
        public final ClassLoader getParent()


    2 用于加载类的方法

    我们通常通过继承这个类来实现我们的自定义类加载器

    1)public的loadClass方法,对外提供的入口,进行加载类

    public Class<?> loadClass(String name) throws ClassNotFoundException {
            return loadClass(name, false);
        }

    是ClassLoader类的入口点

    为什么叫入口点:

               比如我们自己写的OurClassLoader类

               OurClassLoader ourCL=new OurClassLoader ()

               Class<?> clazz=ourCL.loadClass("OurClass");


    从而加载类并得到它的Class对象

    2)剩下的基本上都是protected方法

    通过覆写这些protected方法定制我们的功能

    loadClass(String name,boolean resolve),注意这个是protected方法,不是外部直接使用的(不是你想调用就调用的),我们可以覆写这个方法

    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 {
                            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;
            }
        }
    它会执行如下步骤

              用findLoadedClass(String)来检查是否已经加载类,如果已经加载则直接返回

              在父类加载器上调用loadClass()方法。如果父类加载器为null,则使用根类加载器来加载

              如果父类加载失败,则调用findClass(String)方法查找类



    findClass(String name)

    protected Class<?> findClass(String name) throws ClassNotFoundException {
            throw new ClassNotFoundException(name);
        }

    我们 要覆写这个方法来自定义自己的加载类的行为

    在这个方法中我们应该调用defineClass方法来把字节码转为Class对象

    defineClass()

    方法负责将字节码分析成运行时的数据结构,并检验有效性。 此方法是final型,我们也无法重写。




    六、附加:父类委托机制

    通过上面的过程我们能看到loadClass的确采用了父类委托缓冲机制

    双亲委派模型见我上一篇文章


    那么问题来了:如果我们覆写loadClass方法呢,成功避开父类委托缓冲机制(为什么这么任性),那能加载一个系统中已经存在的类吗?

    可以,因为:

    JVM是如何判定两个 Java 类是相同的: A.类的全名 B.加载此类的类加载器


    我们自定义的一个新的类加载器,则加载这样一个类 <com.silvia.MyClass  ,    MyClassLoader>

    我们知道CLASSPATH下的类是由Application classloader 系统加载器 加载的,所以如果com.silvia.MyClass放在CLASSPATH下可以被加载

    这样就可以有两个com.silvia.MyClass类啦


    但是

    能不能加载java.lang.Object这种类呢

    不能。JVM里面做了相关安全认证。从而防止不可靠的甚至恶意的代码代替父加载器的可靠代码。


    所以说一般来说我们应该覆写findClass方法就好了,不要绕过父类委托机制(不要覆写loadClass)



    展开全文
  • Java虚拟机类加载顺序

    2010-03-15 15:14:17
    Java虚拟机类加载顺序,Java虚拟机类加载顺序,Java虚拟机类加载顺序
  • 深入理解Java虚拟机--Java虚拟机类加载机制

    本文是《深入理解Java虚拟机》第七章的读书总结。

    Class文件中存储了类(或接口)中的元数据信息和编译后的字节码。这些信息需要存入Java虚拟机中才能被虚拟机利用和执行。而Class文件是需要Java虚拟机加载到虚拟机内存中的。这就涉及到几个问题,什么时候需要加在一个Class文件?虚拟机如何加载Class文件到虚拟机内存中?Class文件中的信息进入虚拟机内存中后会发生怎么样的变化?

    1、概述

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

    与那些在编译时需要进行连接工作的语言不同,在Java语言里,类型的加载、连接和初始化过程都是在程序运行期间完成的,这可能会导致类加载时增加了性能开销,不过这也为Java程序提供了高度的灵活性,Java里天生可以动态扩展的语言特性就是依赖运行期动态加载和动态连接这个特点实现的。这个特性导致了很多有用的功能的出现,比如,可以编写一个面向接口的应用程序,等到运行时再指定接口的实现类;用户可以通过Java预定义的和自定义的类加载器,让一个本地的应用程序可以在运行时从网络或者其他地方加载一个二进制流作为程序代码的一部分。

    2、什么时候加载?

    类的一生就是从被加载到虚拟机内存开始,直到卸载出内存为止。整个生命周期中,一个类经历了加载(Loading)、验证(Verfication)、准备(Preparation)、解析(Resolution)、初始化(Initialization)、使用(Using)和卸载(Unloading)等七个阶段。其中,验证、准备、解析三个阶段称为连接(Linking),过程如下所示:


    在上面的流程图中,加载、验证、准备、初始化和卸载5个阶段是按顺序开始的,不过不一定按顺序进行,因为这些阶段通常是相互交叉的混合进行的,通常在一个阶段执行的过程中调用、激活另一个阶段。但是解析阶段则不一定,它在某些情况下可以在初始化阶段之后再开始,这是为了支持Java语言的运行时绑定(也叫动态绑定和晚期绑定)。

    接下来就应该考虑一个Class文件会在什么时候进行加载。Java虚拟机规范中并没有进行强制约束,由虚拟机来具体实现。不过对于类的初始化阶段,虚拟机规范严格规定了5种情况下必须对类进行初始化,这样,类的加载、验证、准备就在这之前开始了。

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

    这五种情况是Java虚拟机规范规定的主动初始化一个类的情况,除此之外的任何其他引用一个类的情况都不会主动初始化这个类,这叫做被动引用。下面以三个例子说明什么是被动引用。

    (1)通过子类引用父类的静态字段,并不会初始化子类

    代码如下:

    1. package ch07;  
    2.   
    3. public class SuperClass {  
    4.     static{  
    5.         System.out.println("Super Class init.");  
    6.     }  
    7.     public static int value=123;  
    8. }  
    9.   
    10. public class SubClass extends SuperClass {  
    11.     static{  
    12.         System.out.println("Sub Class init.");  
    13.     }  
    14. }  
    15.   
    16. public class Test1 {  
    17.     @SuppressWarnings("unused")  
    18.     public static void main(String[] args) {  
    19.         System.out.println(SubClass.value);  
    20.     }  
    21. }  

    这里定义了一个父类和一个子类,在Test1中通过子类引用父类的静态字段,结果如下:

    Super Class init.
    123

    可以看到,并没有输出“SubClass init.”,对于静态字段,只有直接定义这个字段的类才会被初始化。不过,对于是否会加载并解析子类,Java虚拟机规范没有明确规定,HotSpot虚拟机可以使用-XX:TraceClassLoading参数来查看类加载的情况,结果如下(只显示了涉及到上面两个类的内容):

    [Loaded ch07.SuperClass from file:/G:/Java/UnderstandingJVM/bin/]
    [Loaded ch07.SubClass from file:/G:/Java/UnderstandingJVM/bin/]

    说明HotSpot虚拟机会加载子类,不过要先加载父类然后加载子类。

    (2)通过数组定义来引用类,不会触发此类的初始化

    代码如下:

    1. public class Test1 {  
    2.     @SuppressWarnings("unused")  
    3.     public static void main(String[] args) {  
    4.         SuperClass[] sca=new SuperClass[10];  
    5.     }  
    6. }  

    这里复用了上面的父类和子类的代码,使用new关键字创建了一个父类的数组,结果并没有"SuperClass init."输出,说明没有触发SuperClass类的初始化阶段。不过这会导致另一个叫做“[Lch07.SuperClass”的类的初始化过程,这是一个由虚拟机自动生成的、直接继承于java.lang.Object的子类,创建动作由字节码指令newarray触发。

    这意味着,数组也是对象,而且是和成员类型不同的一个对象。

    这个类代表了SuperClass的一维数组,数组中应有的属性和方法(用户可以访问到的只有length属性和clone方法)都实现在这个类里。Java语言中对数组的访问要比C/C++相对安全是因为这个类封装了数组元素的访问方法,而C/C++直接翻译为对数组指针的移动。在Java语言里,当检查到发生数组越界时会抛出java.lang.ArrayIndexOutOfBoundsException异常。

    (3)常量在编译阶段会存入调用类的常量池

    代码如下:

    1. public class ConstClass{  
    2.     static{  
    3.         System.out.println("ConstClass init.");  
    4.     }  
    5.     public static final String GREETING="Hello World.";  
    6. }  
    7.   
    8. public class Test1{  
    9.     public static void main(String[] args){  
    10.         System.out.println(ConstClass.GREETING);  
    11.     }  
    12. }  

    这里的ConstClass里定义了一个常量,运行后也没有“ConstClass init.”输出,这时因为在编译阶段将这个常量的值存储到了Test1类的常量池中,以后Test1类对这个常量的引用实际上都会被转化为Test类对自身常量池的引用,即使在Java源码中引用了ConstClass的GREETING常量。也就是说,实际上Test1的Class文件中并没有对ConstClass类的符号引用入口,两者在编译成Class文件后就没有关系了。

    接口的加载过程和类的加载过程有一些不同,不过接口也有初始化过程,上面的代码都是用静态代码块“static{}”来输出初始化信息的,而接口中不能使用“static{}”语句块,但编译器仍然会为接口生成“<clinit()>”类构造器,用于初始化接口中所定义的成员变量。接口与类真正有所区别的是在前面五种情况中的第三种:当一个类在初始化时,它的所有父类都完成了初始化,但对一个接口初始化时,并不要求所有的父接口都完成初始化,只有在真正用药父接口的时候才会初始化。

    3、怎么加载?

    接下来就是怎么加载的问题了。这里涉及到前面图中的五个阶段:加载、验证、准备、解析和初始化。

    3.1、加载阶段

    这个加载的步骤只是类加载过程的一个阶段。这在个阶段,虚拟机要做的事情有如下三个:

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

    流程图如下:


    虚拟机规范的这三点要求并不具体,虚拟机的实现很自由。

    首先要有Class文件。虽然说是文件,但获取Class二进制流的方式非常对,只要能得到这个虚拟机所需要的内容即可。比如可以使用如下的方式获取二进制流:

    • 从ZIP包中读取,这就是JAR、EAR和WAR格式的基础;
    • 从网络中获取,典型应用就是Applet;
    • 运行时计算生成,使用最多的就是动态代理技术;
    • 由其他文件生成,典型场景是JSP应用,即由JSP文件生成对应的Class类;
    • 从数据库汇中读取;

    总之,获取Class文件的方式非常多。

    将Class文件加载到内存中是由类加载器完成的。相比于类加载的其他阶段,加载这个阶段的灵活性很大,因为开发者可以自己定义一个类加载器,来达到灵活加载的目的(即重写一个类加载器的loadClass()方法)。

    前面提到过,数组也是一个类,但数组类的加载和非数组类不同,它不是通过类加载器创建的,而是由Java虚拟机直接创建的。但数组类和非数组类也有很大的联系,毕竟组成数组的元素就是非数组类(对于一维数组来说,而对于多维数组来说,可以递归加载),非数组类的创建需要类加载器完成。加载创建一个数组类的过程如下:

    • 如果数组的元素类型是引用类型,就递归加载这个元素类型,这个数组将在加载该元素类型的类加载器的类名称空间上被标识;
    • 如果数组的元素类型不是引用类型(比如int[]数组),Java虚拟机将会把数组标记为与引导类加载器关联;
    • 数组类的可见性与元素类型的可见性一致,如果元素类型是不引用类型,那么数组的可见性默认是public;

    加载阶段完成后,原来虚拟机外部的二进制字节流就按照虚拟机所需的格式存储在方法区之中,不过方法区中的数据格式Java虚拟机规范没有规定。在这之后,虚拟机会在内存中实例化一个java.lang.Class类的对象。对于HotSpot虚拟机,虽然这是一个对象,按理说应该在Java堆中创建,不过HotSpot虚拟机是在方法区中创建的。这个对象将作为程序访问方法区中的这些数据类型的外部入口。

    需要注意的是,加载阶段与连接阶段的部分内容是交叉进行的。

    3.2、验证阶段

    验证是连接阶段的第一步,这一阶段的目的是为了确保Class文件的字节流中包含的信息符合当前虚拟机的要求,并且不会危害虚拟机自身的安全。

    不过,如果Java源代码本身有安全问题的话(比如数组越界访问),编译器就不会编译成功,也就没有Class文件。是不是就是说,如果有Class文件,那么这个Class文件就是安全的呢?如果这样,也就不需要验证了,是不是可以提高虚拟机的执行性能呢?

    当然不是,前面的加载阶段提到过,Class文件不一定是编译器生成的,获取Class文件的方式有很多,甚至可以使用十六进制编辑器自己手工写一个Class文件。这样,Java语言方面的安全检查就没有用了,如果虚拟机不检查输入的字节流,很可能会因为载入了有害的字节流导致虚拟机崩溃。即,验证阶段是虚拟机的自我保护的一个手段。

    从整体上看,验证阶段大致可以分为四个方面:文件格式验证、元数据验证、字节码验证和符号引用验证。

    (1)文件格式验证

    首先要验证文件的格式是否符合Class文件格式的规范,并且能被当前版本的虚拟机处理。这个阶段可能验证的内容有:

    • 文件的开始是否是0xCAFEBABE这个魔数;
    • 主次版本号是否在当前虚拟机的处理范围内;
    • 常量池的常量中是否有不被支持的常量类型(即检查tag标志);
    • 指向常量的各种索引值是否有指向不存在的常量或不符合类型的常量;
    • CONSTANT_Utf8_info类型的常量中是否有不符合UTF8编码的数据;
    • Class文件中各个部分及文件本身是否有被删除的或附加的其他信息等;

    其实这只是一小部分,这个阶段要验证的内容还挺多,主要目的就是保证输入的字节流能正常地解析并存储于方法区内,格式上符合描述一个Java类型信息的要求。这个阶段验证的是基于二进制字节流的,只有通过这个阶段的验证,字节流才会进入方法区中,所以后面的三个验证阶段是基于方法区的存储结构进行的。

    从这里可以看出,在虚拟机找到Class文件之后就开始了验证阶段,两个阶段是交叉进行的。如果这两个阶段细分的话,可以是:寻找Class文件——>找到后进行文件格式验证——>验证通过后存入方法区——>进行其他方面的验证与加载工作。

    (2)元数据验证

    接下来就是对字节码描述的信息进行语义分析,验证这些信息是否符合Java语言规范的要求,这个阶段验证的内容有:

    • 这个类是否有父类(除了java.lang.Object外都有父类);
    • 这个类的父类是否继承了不被允许继承的类(被final修饰的类,如String);
    • 如果这个类不是抽象类,是否实现了其父类或接口中要求实现的所有方法;
    • 类中的字段、方法是否与父类产生矛盾(比如覆盖了父类的final字段、或出现不符合规则的方法重载等);

    对元数据的验证内容还有很多,主要是保证不存在不符合Java语言规范的元数据信息。

    (3)字节码验证

    接下来就是字节码验证,这部分是整个验证过程中最复杂的一部分,主要目的是通过数据流和控制流分析,确定程序语义是合法的、符合逻辑的。在第二阶段完成对元数据信息中的数据类型的验证后,这个阶段将对类的方法体进行校验分析,保证被校验的类的方法在运行时不会做出危害虚拟机安全的事件,比如:

    • 保证任意时刻操作数栈的数据类型与指令序列都能配合工作,即不会出现指令是iload但操作数是long的情况;
    • 保证跳转指令不会跳转到方法体以外的字节码指令上;
    • 保证方法体中的类型转换是有效的;

    这部分的验证内容还有很多。如果一个类方法体的字节码没有通过字节码验证,那么这肯定是有问题的;不过,如果字节码通过了字节码验证也不一定是没有问题的。

    由于数据流验证的高复杂性,虚拟机设计团队在JDK 1.6之后的Javac编译器和Java虚拟机中进行了一项优化,给方法体的Code属性的属性表中增加了一个叫StackMapTable的属性,这个属性用来描述方法体中所有的基本快(按照控制流拆分的代码块)开始时本地变量表和操作数栈应有的状态,在字节码验证期间,就不需要根据程序员推导这些状态的合法性,只需要检查StackMapTable属性中的记录是否合法即可。不过这个属性也有被篡改的可能。

    在JDK 1.6的HotSpot虚拟机中提供了-XX:UseSplitVerifier选项来关闭这项优化,或者使用参数-XX:FailOverToOldVerifier要求在类型校验失败的时候回退到旧的类型推导方式进行校验。而在JDK 1.7之后,对于版本号大于50的Class文件,使用类型检查来完成数据流分析校验是唯一的选择,不允许回退到类型推导的校验方式。

    (4)符号引用验证

    最后一个验证阶段就是符号引用验证。这一阶段发生在虚拟机将符号引用转化为直接引用的时候,这个转化动作将在连接的第三阶段——解析阶段中发生。符号引用验证可以看做是对类自身以外(常量池的各种符号引用)的信息进行匹配性校验,通常要校验如下内容:

    • 符号引用中通过字符串描述的全限定名是否能找到对应的类;
    • 在指定类中是否存在符号方法的字段描述符以及简单名称所描述的方法和字段;
    • 符号引用中的类、字段和方法的访问性是否可以被当前类访问;

    符号引用验证的目的是确保解析动作能正常执行,如果无法通过符号引用验证,那么就会抛出一个java.lang.IncompatibleClassChangeError异常的子类,如java.lang.IllegalAccessError、java.lang.NoSuchFieldError、java.lang.NoSuchMethodError等。

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

    3.3、准备阶段

    准备阶段是正式为类变量分配内存并设置类变量初始值的阶段,这些变量所使用的内存都将在方法区中进行分配。这个阶段中需要注意两点,首先,这个时候进行内存分配的仅包括类变量(被static修饰的变量)而不包括实例变量,实例变量就在对象实例化时随着对象一起分配在Java堆中。其次,这里所说的初始值通常是数据类型的零值,比如下面的类变量定义:

    1. public static int value=10;  

    那么value在准备阶段的初始值是0而不是10,因为这个时候还没开始执行任何Java方法,而将value赋值为10的putstatic指令是程序被编译后,存放于类构造器<clinit>()方法中,所以把value赋值为10的动作将在初始化阶段才会执行。下标列出了所有基本类型的零值:

    数据类型

    零值

    数据类型

    零值

    int

    0

    boolean

    False

    long

    0L

    float

    0.0f

    short

    (short)0

    double

    0.0d

    char

    ‘\u0000’

    reference

    Null

    byte

    (byte)0

     

     

    不过也有特殊情况,将类变量赋值为非零值。如果类字段的字段属性表中存在ConstantValue属性,那么在准备阶段变量value就会被初始化为ConstantValue属性所指定的值,比如:

    1. public static final int value=10;  

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

    3.4、解析阶段

    解析阶段是虚拟机将常量池内的符号引用替换为直接引用的过程,在Class文件结构中层多次提到过符号引用,它以CONSTANT_Class_info、CONSTANT_Fieldref_info、CONSTANT_Methodref_info等类型的常量出现。在解析阶段的符号引用和直接引用的区别如下:

    • 符号引用(Symbolic References):符号引用以一组符号来描述索引用的目标,符号引用可以是任何形式的字面量,只要使用时能无歧义地定位到目标即可。符号引用与虚拟机实现的内存布局无关,引用的目标不一定已经加载到内存中。各种虚拟机实现的内存布局可以各不相同,但是它们能接受的符号引用都是一样的;
    • 直接引用(Direct References):直接引用可以是直接指向目标的指针、相对偏移量或是一个能间接定位到目标的句柄。直接引用是和虚拟机实现的内存布局有关的,同一个符号引用在不同的虚拟机上翻译出来的直接引用一般不相同。如果有了直接引用,那么引用的目标一定在内存中。

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

    对同一个符号引用进行多次解析请求是很常见的事情,除了invokedynamic指令外,虚拟机实现可以对第一次解析的结果进行缓存(在运行时常量池中记录直接引用,并把常量标识为已解析状态)从而避免重复解析。无论是否真正执行了多次解析动作,虚拟机需要保证的是在同一个实体中,如果一个符号引用之前就已经被成功解析过,那么后续的引用解析请求就应当是一直成功;同样的,如果第一次解析失败了,那么其它指令对这个符号的解析请求也应该收到同样的异常。

    解析动作主要是对类或接口、字段、类方法、接口方法、方法类型、方法句柄和调用点限定符7类符号引用进行解析,分别对应CONSTANT_Class_info、CONSTANT_Fieldref_info、CONSTANT_Methodref_info、CONSTANT_InterfaceMethodref_info、CONSTANT_MethodType_info、CONSTANT_MethodHandle_info和CONSTANT_InvokeDynamic_info7种常量类型。这里仅仅介绍前四种,因为后三种和动态类型语言支持有关。

    (1)   类或接口的解析

    假设当前代码处于类D中,如果要把一个从未解析过的符号引用N解析为一个类或接口C的直接引用,虚拟机将经历如下的过程:

    • 如果C不是一个数组类型,那虚拟机将会把代表N的全限定名传递给D的类加载器区加载这个类。在加载过程中,由于元数据验证、字节码验证的需要,又可能触发其他相关类的加载,比如这个类的父类或实现的接口。如果加载过程出现异常,解析过程就失败。
    • 如果C是一个数组类型,并且数组的元素类型是对象,就会按照第一点加载数组元素类型。接着由虚拟机生成一个代表着数组维度和元素的数组对象。
    • 如果上面的步骤没有异常,那么C在虚拟机中实际上已经成为一个有效的类或接口了,但在解析完成之前还要进行符号引用验证,确认D是否具备对C的访问权限。

    (2)   字段解析

    要解析一个未被解析过的字段符号引用,首先将会对字段表内class_index项中索引的CONSTANT_Class_info符号引用进行解析,也就是字段所属的类或借口的符号引用。如果解析这个类或接口时发生异常,都会导致解析字段的失败。如果解析成功,才会继续解析这个字段。具体的规则如下:

    • 如果类或接口C本身就包含了简单名称和字段描述符都与目标匹配的字段,则返回这个字段的直接引用,查找结束;
    • 否则,如果在C中实现了接口,将会按照继承关系从下到上递归搜索各个接口和它的父接口,如果接口中包含了简单名称和字段描述符都与目标匹配的字段,则返回这个字段的直接引用,查找结束;
    • 否则,如果C不是Object的话,将会按照继承关系从下到上递归搜索父类,如果父类中包含了简单名称和字段描述符都与目标匹配的字段,返回这个字段的直接引用,查找结束;
    • 否则,查找失败。
    • 之后,还会对返回的字段进行权限验证,如果不具备对字段的访问权限,将抛出java.lang.IllegalAccessError异常。

    (3)   类方法解析

    类方法解析的第一个步骤和字段解析一样,也需要先解析出类方法表的class_index项中索引的方法所属的类或接口的符号引用,如果解析成功,按照如下步骤继续(同样以C来表示这个类):

    • 类方法和接口方法符号引用的常量类型定义是分开的,如果在类方法表中发现class_index中索引的C是一个接口,直接失败;
    • 然后,会在类C中查找这个方法;
    • 否则,在类C的父类中递归查找这个方法;
    • 否则,在类C实现的接口列表中递归查找这个方法。如果找到一个匹配的方法,说明类C是一个抽象类,查找结束,抛出java.lang.AbstractMethodError异常;
    • 否则,查找失败,抛出java.lang.NoSuchMethodError异常。
    • 同样,成功返回后还要进行权限验证。

    (4)   接口方法解析

    接口方法也要解析接口方法表的class_index所属的类或接口引用,如果解析成功,用C表示这个类或接口,虚拟机按照如下的规则搜索:

    • 与类方法解析不同,如果在接口方法表中发现class_index是一个类而不是接口,直接抛出java.lang.IncompatibleClassChangeError异常;
    • 否则,在接口C中查找这个方法;
    • 否则,在接口C的父接口中递归查找;
    • 否则,查找失败,抛出java.lang.NoSuchMethodError异常。

    返回成功后不会验证权限,因为接口的方法都是public的。

    3.5、初始化阶段

    类初始化阶段是类加载过程的最后一步,前面的类加载过程中,除了在加载阶段用户应用程序可以通过自定义类加载器参与之外,其余动作完全由虚拟机主导和控制。到了初始化阶段,才真正开始执行类中定义的Java程序。

    前面已经知道,在准备阶段变量已经赋值过一次系统初始值了,而在初始化阶段,则会根据程序员通过程序制定的主观计划去初始化类变量和其它内容。即,初始化阶段是执行类构造器<clinit>()方法的过程。下面是<clinit>()方法的特点:

    • <clinit>()方法是由编译器自动收集类中的所有类变量的赋值动作和静态语句块中的语句合并产生的,编译器收集的顺序由语句块在源文件中的顺序决定的,静态语句块中只能访问到定义在静态语句块之前的变量,定义在之后的变量不能访问,但能赋值。
    • <clinit>()方法与类构造器<init>()不同,它不需要显式调用父类的<clinit>()方法,虚拟机保证在子类<clinit>()方法执行之前,父类的<clinit>()方法已经执行完毕。
    • 由于父类的<clinit>()方法先执行,意味着父类中定义的静态语句块要优先于子类的变量赋值操作。
    • <clinit>()方法对于类或接口来说并不是必须的,如果一个类中没有静态语句块,也没有对变脸的赋值操作,那么编译器就不会生成<clinit>()方法。
    • 接口中不能使用静态语句块,但仍然有变量初始化的赋值操作,因此接口与类一样都会生成<clinit>()方法。但接口与类不同的是,执行接口的<clinit>()方法不需要先执行父接口的<clinit>()方法。即,只有使用一个接口中的变量时,才会执行这个接口的<clinit>()方法。
    • 虚拟机会保证一个类的<clinit>()方法在多线程环境下中被正确的加锁、同步,如果多个线程同时去初始化一个类,那么只有一个线程会去执行这个类的<clinit>()方法,其他线程都需要阻塞等待,直到活动线程执行<clinit>()方法完毕。

    4、类加载器

    类加载的过程是通过类加载器来完成的。类加载器是Java语言的一个重要创新,许多有用的技术都是基于类加载器实现的,比如类层次划分、OSGi、热部署、代码加密等。

    4.1、类与类加载器

    虽然类加载器只用于类的加载动作,但在Java程序中还有着很大的作用。对于任意一个类,都需要加载它的类加载器和这个类本身来确定这个类在Java虚拟机中的唯一性,每一个类加载器都有一个独立的类名称空间。也就是说,如果比较两个类是否是同一个类,除了这比较这两个类本身的全限定名是否相同之外,还要比较这两个类是否是同一个类加载器加载的。即使同一个类文件两次加载到同一个虚拟机中,但如果是由两个不同的类加载器加载的,那这两个类仍然不是同一个类。

    这个相等性比较会影响一些方法,比如Class对象的equals方法、isAssignableFrom方法、isInstance方法等,还有instanceof关键字做对象所属关系判定等。下面的代码演示了不同的类加载器对instanceof关键字的影响:

    1. package jvm;  
    2.   
    3. import java.io.IOException;  
    4. import java.io.InputStream;  
    5.   
    6. public class ClassLoaderTest {  
    7.     public static void main(String[] args) throws Exception{  
    8.         ClassLoader loader=new ClassLoader() {  
    9.             @Override  
    10.             public Class<?> loadClass(String name)throws ClassNotFoundException{  
    11.                 try{  
    12.                     String filename=name.substring(name.lastIndexOf(".")+1)+".class";  
    13.                     InputStream is=getClass().getResourceAsStream(filename);  
    14.                     if(is==null){  
    15.                         return super.loadClass(name);  
    16.                     }  
    17.                     byte[] b=new byte[is.available()];  
    18.                     is.read(b);  
    19.                     return defineClass(name,b,0,b.length);  
    20.                 }catch(IOException e){  
    21.                     throw new ClassNotFoundException(name);  
    22.                 }  
    23.             }  
    24.         };  
    25.         Object obj=loader.loadClass("jvm.ClassLoaderTest").newInstance();  
    26.         System.out.println(obj.getClass());  
    27.         System.out.println(obj instanceof jvm.ClassLoaderTest);  
    28.     }  
    29. }  

    运行结果:
    class jvm.ClassLoaderTest
    false

    这里构造了一个简单的类加载器,它可以加载与自己在同一个路径下的Class文件。然后使用这个类加载器去加载全限定名是“jvm.ClassLoaderTest”的类,并实例化了这个类的对象。从第一行输出可以看出,这个对象确实是jvm.ClassLoaderTest类的一个实例,但第二句输出表明在做instanceof检查时出现了false,这是因为这时虚拟机中有两个jvm.ClassLoaderTest类,一个是系统应用程序类加载器加载的,另一个是自定义的类加载器加载的,这两个类虽然来自同一个Class文件,但是加载它们的类加载器不同,导致类型检查时结果是false。

    4.2、双亲委派模型

    从Java虚拟机的角度看,只有两种不同的类加载器,一种是启动类加载器,这个类加载是由C++实现的,是虚拟机的一部分;另一个是所有其它的类加载器,都是由Java实现的,独立在虚拟机外部,并且全部继承自java.lang.ClassLoader抽象类。

    不过在Java开发者看来,类加载器的细致划分可以划分为三种:

    • 启动类加载器:负责将存放在<JAVA_HOME>\lib目录中的,或者被-Xbootclasspath参数所指定的路径中的,并且是虚拟机识别的类库加载到虚拟机内存中。启动类加载器无法被Java程序直接引用,用户在编写自定义类加载器时,如果需要把加载请求委派给引导类加载器,那直接使用null代替即可。
    • 扩展类加载器:这个加载器由sun.misc.Launcher$ExtClassLoader实现,负责加载<JAVA_HOME>\lib\ext目录下的,或者被java.ext.dirs系统变量所指定的路径中的所有类库,开发者可以直接使用扩展类加载器。
    • 应用程序类加载器:这个类加载器是由sun.misc.Launcher$AppClassLoader实现的。由于这个类加载器是ClassLoader中的getSystemClassLoader方法的返回值,所以也叫系统类加载器。它负责加载用户类路径上所指定的类库,开发者可以直接使用这个类加载器,如果应用程序中没有自定义过自己的类加载器,一般情况下这个就是程序中默认的类加载器。

    用户的应用程序就是在这三个类加载器的配合下加载的。不过,用户还可以加入自己的类加载器,这些类加载器的关系如下图:


    这种类加载的层次关系,称为类加载器的双亲委派模型。双亲委派模型要求除了顶层的启动类加载器之外,其余的类加载器都应当有自己的父类加载器。不过这个父子关系不是通过继承实现的,而是使用组合关系来复用父加载器的代码。

    双亲委派模型的工作过程如下:如果一个类加载器收到了类加载的请求,它首先不会自己去尝试加载这个类,而是把这个请求委派给父类加载器去完成,每一个层次的类加载器都是如此,因此所有的加载请求最终都会传送到顶层的启动类加载器中,只有当父类加载器反馈自己无法完成这个加载请求(它的搜索范围内没找到这个类)时,自加载器才会尝试自己加载。

    这种模型的一个好处就是由于类加载器有一种层次关系,导致类也有一种层次关系,从而有了优先级。比如类java.lang.Object,它存放在rt.jar中,无论哪个类加载器要加载这个类,最终都要委派给启动类加载器去加载,因此Object类在各个类加载器环境中都是同一个类。相反,如果没有使用双亲委派模型,由各个类加载器去自行加载,如果用户自己编写了一个称为java.lang.Object的类,并放在程序的ClassPath中,那系统将会有多个不同的Object类,java类型体系中最基础的行为也就没有办法保证了。

    4.3、双亲委派模型的破坏

    不过,双亲委派模型并不是一个强制性的约束模型,而是一个推荐实现类加载的方式。但也会有例外,导致破坏双亲委派模型。

    首先,双亲委派模型是JDK 1.2之后引入的,而ClassLoader类在JDK 1.0就有了,为了向前兼容,不得做出一些妥协。

    还有,类加载器的层次结构解决了基础类的统一问题,但是如果基础类要回调用户的代码呢?这也破坏了双亲委托模型。

    最后就是语言动态性造成的。

    这部分对于双亲委派模型的破坏的介绍不是很多,只要知道这只是一个推荐模型即可。

    展开全文
  • Java虚拟机类加载过程

    千次阅读 2017-09-02 18:03:31
    在什么情况下进行加载虚拟机加载时机并没有明确的规定,是由具体的虚拟机实现的,当时明确规定了,在以下5种情况下(有且只有),必须进行初始化(加载、验证、准备必须在初始化之前)。这5种方式也被...

    1. 类加载的时机:

    • 类从被加载到虚拟机内存开始到卸载出内存,整个生命周期包括以下七个阶段,其中加载,验证,准备,初始化,卸载这5个阶段的顺序是确定的。
      类生命周期

    • 类在什么情况下进行加载: 虚拟机对类的加载时机并没有明确的规定,是由具体的虚拟机实现的,当时明确规定了,在以下5种情况下(有且只有),类必须进行初始化(加载、验证、准备必须在初始化之前)。这5种方式也被称为主动引用,除此之外的其他引用都不会触发初始化,称为被动引用。

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

    2. 类加载的过程:

    2.1 加载:

    • 加载过程中虚拟机需要完成的几件事:
      • 通过一个类的全限定名类获取定义此类的二进制字节流–可从多种渠道获取(jar,war,网络等)
      • 将这个字节流所代表的静态存储结构转换为方法区的运行时数据结构
      • 在内存中生成一个代表这个类的java.lang.Class对象,作为这个方法区这个类的各种数据的访问入口(HotSpot虚拟机将这个对象存储在方法区中,该对象将作为程序访问方法区中这些数据类型的外部接口)

    2.2 验证:确保Class文件中的字节流中包含的信息符合当前虚拟机的要求,并且不会危害虚拟机自身的安全。

    • 验证阶段大致会完成以下4个阶段的检验动作:
      • 文件格式验证:字节流是否符合Class文件格式的规范,并且能被当前版本的虚拟机处理。
        • 包括魔数校验:是否以0xCAFEBABE开头
        • 主次版本号是否在当前虚拟机的处理范围内
        • 。。。。
      • 元数据验证:对字节码描述的信息进行语义分析,保证其描述的信息符合java语言规范的要求。
        • 这个类是否有父类
        • 这个类的弗雷是否继承了不允许被继承的类(被final修饰的类)
        • 如果这个类不是抽象类,是否实现了其父类或接口之中要求实现的所有方法
        • 类中的字段,方法是否和父类产生矛盾(如覆盖率弗雷的final字段,或者出现不符合规则的方法的重载,例如方法参数都一致,但返回值类型却不相同等)
      • 字节码验证:通过数据流和控制流分析,确定程序的语义是否是合法的,符合逻辑的
        • 保证跳转指令不会跳转到方法体之外的字节码指令上
        • 保证方法体中的类型转换是有效的,例如可以把子类对象赋值给父类数据类型,这是安全的,但是不能吧父类对象赋值给子类数据类型,甚至是毫不相关的类型
        • 保证任意时刻操作数栈的数据类型和指令码序列都能配合工作。
      • 符号引用验证:对类自身以外(常量池中的各种符号引用)的信息进行匹配性校验, 这一阶段的校验发生在虚拟机将符号引用转换为直接引用的时候,这个动作发生在连接的第三阶段(解析阶段)中发生。
        • 符号引用中通过字符串描述的全限定名是否能找到相应的类
        • 在指定的类中是否存在符合方法的字段描述符以及简单名称所描述的方法和字段
        • 符号引用中的类、字段、方法的访问性(private、protected、public、default)是否可被当前类访问

    2.3 准备:正式为类变量分配内存并设置类变量初始值的阶段,这些变量所使用的内存都将在方法区中进行分配

    • 这个时候进行内存分配的只包括类变量(被static修饰的变量),并不包括实例变量,实例变量是在对象实例化时随对象一起分配在java堆中。
    • 分配的初始值为零值,假设一个变量定义为:public static int value = 123;则设置变量的初始值应该为0, 而不是123. 把value赋值为123的putstatic指令是在程序被编译后,存放于类构造器<clinit>()方法之中,所以吧value赋值为123的动作将在初始化阶段才会执行。
    • 如果字段属性表中存在ConstantValue属性,那么在准备阶段会将value赋值为ConstantValue属性所指定的值
      • 例如:public static final int value = 123; 那么在准备阶段,则会将value赋值为123;

    2.4 解析 :将符号引用转换成直接引用的过程

    • 符号引用和直接引用的定义:

      • 符号应用:符号引用是一组以符号来描述所引用的目标,符号可以是任何形式的字面量,只要使用是能无歧义的定位到目标即可。符号引用与虚拟机实现的内存布局无关,引用的目标并不一定已经加载到内存中。各种虚拟机实现的内存布局可以各不相同,但是它们能接受的符号引用必须都是一致的,因为符号引用的字面量形式明确定义在java虚拟机规范的Class文件格式中。符号引用在Class文件中以CONSTANT_Class_info(类或接口的符号引用)、CONSTANT_Fieldref_info(字段的符号引用)、CONSTANT_Methodref_info(方法的符号引用)等类型的常量出现。

        符号引用主要包括以下三类常量:

        • 类和接口的全限定名:java.lang.String的全限定名为:java/lang/String
        • 字段的名称和描述符:java.lang.String[][]二维数组的描述符为:[[Ljava.lang.String
        • 方法的名称和描述符:java.lang.String.toString()方法的描述符为:()Ljava.lang.String
      • 直接引用:直接引用可以是直接指向目标的指针、相对偏移量或是一个能间接定位到目标的句柄。直接引用是和虚拟机实现的内存布局相关的,同一个符号引用在不同虚拟机实例上翻译出来的直接引用一般不会相同。如果有了直接应用,那引用的目标必定已经在内存中存在
    • 解析阶段的发生时间:

      • 虚拟机规范中并没有规定解析阶段发生的具体时间,值要求类在执行:anewarray、checkcast、getfield、getstatic、instanceof、invokedynamic、invokeinterface、invokespecial、invokestatic、invokevirtual、ldc、ldc_w、multianewarray、new、putfield、putstatic这16个用于操作符号引用的字节码指令之前,先对它们所使用的符号引用进行解析。
    • 解析针对的符号引用类型:
      • 解析动作主要针对:类或接口(CONSTANT_Class_info)、字段(CONSTANT_Fieldref_info)、类方法(CONSTANT_Methodref_info)、接口方法(CONSTANT_InterfaceMethodref_info)、方法类型(CONSTANT_MethodType_info)、方法句柄(CONSTANT_MethodHandle_info)和调用点限定符(CONSTANT_InvokeDynamic_info)7类符号引用进行。(CONSTANT_String_info也需要解析过程)
    • 解析符号引用过程分析:

      • 类或接口的解析(CONSTANT_Class_info)
        • 假设当前代码所处的类为D,如果要吧一个未解析过的符号引用N解析为一个类或接口C的符号引用,虚拟机需要完成以下3个步骤:
          1. 如果C不是一个数字类型,那虚拟机将会吧代表N的全限定名传递个D的类加载器去加载这个类C。
          2. 如果C是一个数组类型?
          3. 如果加载没有异常,那么C在虚拟机中实际已经成为一个有效的类或接口了,但在解析完成之前还需要进行符号引用的校验,确认D是否具备对C的访问权限。如果不具备会抛出java.lang.IllegalAccessError异常。
      • 字段解析:解析一个未被解析过的字段符号引用,首先会对字段所属的类或接口的符号引用进行解析。如果解析成功,则将这个字段所属的类或接口用C表示,虚拟机规范要求安装如下步骤对C进行后续字段的搜索:

        • 如果C本身就宝航了简单名称和字段描述符都与目标相匹配的字段,则返回这个字段的直接引用,查找结束。
        • 否则,如果在C中实现了接口,将会按照继承关系从下往上递归搜索各个接口和他的父接口,如果接口中包含了简单名称和字段描述符都与目标相匹配的字段,则返回这个字段的直接引用,查找结束。
        • 否则:如果C不是java.lang.Object的话,将会按照继承关系从下往上递归搜索其弗雷,如果在父类中包含了简单名称和字段描述符都与目标相匹配的字段,则返回这个字段的字节引用,查找结束。
        • 否则查找失败,抛出java.lang.NoSushFieldError异常。

        如果查找过程中返回了引用,则需要对这个字段进行权限校验,如果发现不具备对字段的访问权限,将抛出java.lang.IllegalAccessError异常。

      • 类方法解析:首先会对方法所属的类或接口的符号引用进行解析。如果解析成功,则将这个方法所属的类或接口用C表示,虚拟机规范要求安装如下步骤对C进行后续的类方法搜索:

        • 类方法和接口方法符号引用的常量类型定义是分开的,如果在类方法表中发现class_index中索引的C是一个接口,那就直接抛出:java.lang.IncompatibleClassChangeError异常
        • 如果通过了第一步,在类C中查找是否有简单名称和描述符都与目标相匹配的方法,如果有这返回这个方法的直接引用,查找结束。
        • 否则,在类C的父类中递归查找是否有简单名称和描述符都与目标相匹配的方法,如果有,则返回这个方法的直接引用,查找结束。
        • 否则,在类C实现的接口列表及它们的弗雷接口之中递归查找是否有简单名称和描述符都与目标相匹配的方法,如果存在匹配法方法,说明类C是一个抽象类,这时查找结束,抛出java.lang.AbstractMethodError异常。
        • 否则,宣告方法查找失败,抛出java.lang.NoSushMethodError

        最后,如果查找过程成功放回了直接引用,将会对这个方法进行权限验证,如果发现不具备对此方法的访问权限,将抛出java.lang.IllegalAccessError异常

      • 接口方法的解析:接口方法也需要先解析出接口方法表的class_index项中索引的方法所属的类或接口的符号引用。如果解析成功,则将这个方法所属的类或接口用C表示,虚拟机规范要求安装如下步骤对C进行后续的类方法搜索:

        • 与类方法的解析不同,如果在接口方法中发现class_index中的索引C是个类而不是接口,那就直接抛出java.lang.IncompatibleClassChangeError异常。
        • 否则,在接口C中查找是否有简单名称和描述符都与目标相陪陪的方法,如果有则返回这个方法的直接引用,查找结束。
        • 否则,在接口C的父接口中递归查找,直到java.lang.Object类(查找范围会包含Object类)为止,看是否有简单名称和描述符都与目标相匹配的方法,如果有则返回这个方法的直接引用,查找结束。
        • 否则,宣告查找失败,抛出java.lang.NoSushMethodError异常。

        接口中的所有方法默认都是public的,所以不存在访问权限问题,因此接口方法的符号解析应当不会出现java.lang.IllegalAccessError异常

    2.5 初始化:初始化阶段才真正开始执行类中定义的java程序代码(字节码)

    • 在准备阶段,变量已经赋过一次系统要求的初始值,而在初始化阶段,则根据程序猿通过程序指定的主观计划去初始化类变量和其他资源,或者可以从另外一个角度来表达:初始化阶段是执行类构造器<clinit>()方法的过程。

      <clinit>()方法解析:

      • <clinit>方法是有编译器自动收集类中的所有类变量的赋值动作和静态语句块(static{}块)中的语句合并产生的,编译器手机的顺序是由语句在源文件中出现的顺序决定的,静态语句块中只能访问到定义在静态语句块之前的变量,定义在他之后的变量,在前面的静态语句块可以赋值,但不能访问:

        public class Test
        {
            static
            {
                i = 0;//给变量赋值可以正常通过
                System.out.println(i);//这句话会编译提示”非法向前访问“
            }
        }
        
      • <clinit>方法与类的构造器(或者说实例构造器<init>()方法)不同,它不需要显示地调用父类构造器,虚拟机会保证在子类的<clinit>()方法执行前,父类的<clinit>()方法已经执行完毕,因此在虚拟机中的一个被执行的<clinit>()方法的类肯定是java.lang.Object。

      • 由于父类的<clinit>()方法先执行,也就意味着父类中定义的静态语句块要优先于子类的变量的操作。
      • <clinit>()方法对于类或接口来说并不是必需的,如果一个类中没有静态语句块,也没有对变量的赋值操作,那么编译器可以不为这个类生成<clinit>()方法。
      • 接口中不能使用静态语句块,但仍然有变量初始化的赋值操作,因此接口与类一样都会生成<clinit>()方法,但接口与类不同的是,执行接口的<clinit>()方法不需要先执行父接口的<clinit>()方法。只有当父接口中定义的变量使用时,父接口才会初始化。另外,接口的实现类在初始化时也一样不会执行接口的<clinit>()方法。
      • 虚拟机会保证一个类的<clinit>()方法在多线程环境中被正确的加锁、同步,如果多个线程同时去初始化一个类,那么只会有一个线程去执行这个类的<clinit>()方法,其他线程都需要阻塞等待,知道活动线程执行<clinit>()方法完毕。如果在一个类的<clinit>()方法中有耗时很长的操作,就可能会造成多个进程阻塞,在实际应用中这种阻塞往往是很隐蔽的。
    展开全文
  • 面试官,不要再问我“Java虚拟机类加载机制”了

    万次阅读 多人点赞 2019-10-27 16:28:39
    关于Java虚拟机类加载机制往往有两方面的面试题:根据程序判断输出结果和讲讲虚拟机类加载机制的流程。其实这两题本质上都是考察面试者对Java虚拟机类加载机制的了解。 面试题试水 现在有这样一道判断程序输出结果...
  • 在《Java虚拟机类加载机制》一文中详细阐述了类加载过程,并举了几个例子进行了简要分析,在文章的后留了一个悬念给各位,这里来揭开这个悬念。建议先看完《Java虚拟机类加载机制》这篇再来看这个,印象会比较深刻...
  • Java虚拟机类加载机制——案例分析

    万次阅读 多人点赞 2016-03-09 19:16:33
    在《Java虚拟机类加载机制》一文中详细阐述了类加载过程,并举了几个例子进行了简要分析,在文章的最后留了一个悬念给各位,这里来揭开这个悬念。建议先看完《Java虚拟机类加载机制》这篇再来看这个,印象会比较...
  • Java虚拟机类加载器及双亲委派机制

    千次阅读 2019-10-29 15:28:13
    所谓的类加载器(Class Loader)就是加载JavaJava虚拟机中的,前面《面试官,不要再问我“Java虚拟机类加载机制”了》中已经介绍了具体加载class文件的机制。本篇文章我们重点介绍加载器和双亲委派机制。 类加载...
  •  虚拟机将描述的数据从Class文件加载到内存,并对数据进行校验、准备、解析和初始化,终会形成可以被虚拟机使用的Java类型,这是一个虚拟机类加载机制。Java中的是动态加载的,只有在运行期间使用到该的...
  • 详解Java虚拟机类加载

    2015-07-25 16:53:17
    虚拟机把描述的数据从Class文件或其它地方加载到内存,并对数据进行校验、转换解析和初始化,最终形成可以被虚拟机直接使用的Java类型,这就是虚拟机类加载过程类加载的时机加载、验证、准备、初始化和卸载这5...
  • Java虚拟机类加载机制及双亲委派模型
  • Java虚拟机类加载机制

    千次阅读 2016-06-05 21:44:58
    而Class文件是需要Java虚拟机加载到虚拟机内存中的。这就涉及到几个问题,什么时候需要加在一个Class文件?虚拟机如何加载Class文件到虚拟机内存中?Class文件中的信息进入虚拟机内存中后会发生怎么样的变化? 1
  • Java虚拟机 类加载过程

    千次阅读 2013-06-30 12:22:36
    类加载的全过程分为五个阶段:加载、验证、准备、解析、初始化。 1. 加载 这个阶段可分为三段: (1)加载二进制字节流 根据的全限定名(包名+类名),获取此类的二进制字节流。 虚拟机规范没有指定二进制字节流...
  • Java虚拟机类加载机制-双亲委派模型

    万次阅读 2019-12-20 20:09:19
    类加载过程 加载 验证 准备 解析 初始化 •类加载器 •写在前面 其实类加载机制并不是很神秘,可以说我们无时无刻不在是由类加载,只是很多时候我们不需要关注类加载机制会给我们带来啥影响,不过如果你...
  • Java虚拟机类加载

    千次阅读 2019-12-31 10:45:14
    虚拟机设计团队把类加载阶段中的获取二进制字节流这个动作放到Java虚拟机外部去实现,一遍让程序自己决定如何去获取所需要的,实现这个动作的代码块被称为“类加载器”。 同一个Class文件如果被不同的类加载器所...
  • 文章目录1、Java虚拟机类加载机制概述2、Java虚拟机中的类加载器2.1、查看类加载加载的路径2.1.1、查看启动类加载器2.1.2、查看扩展类加载器3、类加载器之间的关系3.1、每个类加载器都有一个父加载器3.2、父加载...
  • 参考书籍:《深入理解Java虚拟机——JVM高级特性与最佳实践(第2版)》 虚拟机把描述的数据从Class文件加载到内存,并对数据进行校验、 转换解析和初始化,最终形成可以被虚拟机直接使用的Java类型,这就是虚拟机的...
  • Java虚拟机类加载机制是把Class文件加载到内存,并对Class文件中的数据进行校验、转换解析和初始化,最终形成可以被虚拟机直接使用的java类型的过程。  java可动态扩展的语言特性就是依赖运行期动态加载和动态...
  • Java虚拟机类加载和执行机制

    千次阅读 2016-08-23 09:00:38
    Java虚拟机类加载和执行机制 虚拟机的类加载和执行机制是虚拟机的最主要功能,在这里简单的对所知的内容进行一次温习,并记录以方便日后重温。 本篇主要引用《深入理解Java虚拟机——JVM高级特性与最佳实践》...
  • java虚拟机类加载过程

    千次阅读 2017-04-03 15:13:33
    java虚拟机把描述的数据从Class文件加载到内存,并对数据进行校验、 转换解析和初始化,最终形成可以被虚拟机直接使用的Java类型,这就是虚拟机的类加载机制。 与那些在编译时需要进行连接工作的语言不同,在Java...
  • 虚拟机把描述的数据从Class文件中加载到内存,并对数据进行校验、转换解析和初始化,最终形成可被虚拟机直接使用的Java类型,这就是虚拟机加载机制。
  • Java虚拟机类加载(解析阶段)

    千次阅读 2017-10-20 09:27:39
    在进行解析之前需要对符号引用进行解析,不同虚拟机实现可以根据需要判断到底是在加载加载的时候对常量池的符号引用进行解析(也就是初始化之前),还是等到一个符号引用被使用之前进行解析(也就是在初始化...
  • Java虚拟机类加载机制

    千次阅读 2015-07-28 08:49:30
    Java虚拟机类加载过程是把Class文件加载到内存,并对Class文件中的数据进行校验、转换解析和初始化,最终形成可以被虚拟机直接使用的java类型的过程。 在加载阶段,java虚拟机需要完成以下3件事: a.通过一个...
  • java虚拟机java虚拟机类加载机制

    千次阅读 多人点赞 2016-07-01 08:24:50
    这篇博文主要来总结一下java虚拟机加载一个过程,为了避免枯燥的解说,为了让读者在读完本文后能彻底理解加载的过程,首先来看一段java代码,我们从一个例子入手: //ClassLoaderProcess.java文件 class ...
  • Java虚拟机:虚拟机类加载机制

    千次阅读 2018-01-12 22:10:10
    概述虚拟机把描述的数据从Class文件加载到内存,并对数据进行校验、转换解析和初始化,最终形成可以被虚拟机直接使用的Java类型,这就是虚拟机类加载机制。与那些在编译时需要进行连接工作的语言不同,在Java...
  • 对于C/C++开发者来说,他们在内存管理方面具有至高的权利,但是也承担着巨大的维护责任。...JVM的类加载机制Java程序的执行过程Java文件被编译为class文件后,就可以通过(java ClassName)来执行你的Java

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 218,726
精华内容 87,490
关键字:

java虚拟机类加载过程

java 订阅