精华内容
参与话题
问答
  • 类加载过程

    多人点赞 2019-11-11 20:38:41
    类加载过程的第一步,主要完成下面3件事情: 通过全类名获取定义此类的二进制字节流 将字节流所代表的静态存储结构转换为方法区的运行时数据结构 在内存中生成一个代表该类的 Class 对象,作为方法区这些数据的...

    加载

    类加载过程的第一步,主要完成下面3件事情:

    1. 通过全类名获取定义此类的二进制字节流
    2. 将字节流所代表的静态存储结构转换为方法区的运行时数据结构
    3. 在内存中生成一个代表该类的 Class 对象,作为方法区这些数据的访问入口

    虚拟机规范多上面这3点并不具体,因此是非常灵活的。比如:"通过全类名获取定义此类的二进制字节流" 并没有指明具体从哪里获取、怎样获取。比如:比较常见的就是从 ZIP 包中读取(日后出现的JAR、EAR、WAR格式的基础)、其他文件生成(典型应用就是JSP)等等。

    一个非数组类的加载阶段(加载阶段获取类的二进制字节流的动作)是可控性最强的阶段,这一步我们可以去完成还可以自定义类加载器去控制字节流的获取方式(重写一个类加载器的 loadClass() 方法)。

    数组类型不通过类加载器创建,它由 Java 虚拟机直接创建。

    加载阶段和连接阶段的部分内容是交叉进行的,加载阶段尚未结束,连接阶段可能就已经开始了。

    验证

    准备

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

    1. 这时候进行内存分配的仅包括类变量(static),而不包括实例变量,实例变量会在对象实例化时随着对象一块分配在 Java 堆中。
    2. 这里所设置的初始值"通常情况"下是数据类型默认的零值(如0、0L、null、false等),比如我们定义了public static int value=111 ,那么 value 变量在准备阶段的初始值就是 0 而不是111(初始化阶段才会复制)。特殊情况:比如给 value 变量加上了 fianl 关键字public static final int value=111 ,那么准备阶段 value 的值就被复制为 111。

    基本数据类型的零值:

    基本数据类型的零值

    解析

    解析阶段是虚拟机将常量池内的符号引用替换为直接引用的过程。解析动作主要针对类或接口、字段、类方法、接口方法、方法类型、方法句柄和调用限定符7类符号引用进行。

    符号引用就是一组符号来描述目标,可以是任何字面量。直接引用就是直接指向目标的指针、相对偏移量或一个间接定位到目标的句柄。在程序实际运行时,只有符号引用是不够的,举个例子:在程序执行方法时,系统需要明确知道这个方法所在的位置。Java 虚拟机为每个类都准备了一张方法表来存放类中所有的方法。当需要调用一个类的方法的时候,只要知道这个方法在方发表中的偏移量就可以直接调用该方法了。通过解析操作符号引用就可以直接转变为目标方法在类中方法表的位置,从而使得方法可以被调用。

    综上,解析阶段是虚拟机将常量池内的符号引用替换为直接引用的过程,也就是得到类或者字段、方法在内存中的指针或者偏移量。

    初始化

    初始化是类加载的最后一步,也是真正执行类中定义的 Java 程序代码(字节码),初始化阶段是执行类构造器 <clinit> ()方法的过程。

    对于<clinit>() 方法的调用,虚拟机会自己确保其在多线程环境中的安全性。因为 <clinit>() 方法是带锁线程安全,所以在多线程环境下进行类初始化的话可能会引起死锁,并且这种死锁很难被发现。

    对于初始化阶段,虚拟机严格规范了有且只有5种情况下,必须对类进行初始化:

    1. 当遇到 new 、 getstatic、putstatic或invokestatic 这4条直接码指令时,比如 new 一个类,读取一个静态字段(未被 final 修饰)、或调用一个类的静态方法时。
    2. 使用 java.lang.reflect 包的方法对类进行反射调用时 ,如果类没初始化,需要触发其初始化。
    3. 初始化一个类,如果其父类还未初始化,则先触发该父类的初始化。
    4. 当虚拟机启动时,用户需要定义一个要执行的主类 (包含 main 方法的那个类),虚拟机会先初始化这个类。
    5. 当使用 JDK1.7 的动态动态语言时,如果一个 MethodHandle 实例的最后解析结构为 REF_getStatic、REF_putStatic、REF_invokeStatic、的方法句柄,并且这个句柄没有初始化,则需要先触发器初始化。
    展开全文
  • JVM类加载过程

    万次阅读 多人点赞 2019-06-20 15:10:25
    1. JVM类加载过程 1.概述 从类的生命周期而言,一个类包括如下阶段: 加载、验证、准备、初始化和卸载这5个阶段的顺序是确定的,类的加载过程必须按照这种顺序进行,而解析阶段则不一定,它在某些情况下...

    1. JVM类加载过程

        1.概述

        从类的生命周期而言,一个类包括如下阶段:

        

            加载、验证、准备、初始化和卸载这5个阶段的顺序是确定的,类的加载过程必须按照这种顺序进行,而解析阶段则不一定,它在某些情况下可能在初始化阶段后在开始,因为java支持运行时绑定。

        2. 类加载时机

        加载(loading)阶段,java虚拟机规范中没有进行约束,但初始化阶段,java虚拟机严格规定了有且只有如下5种情况必须立即进行初始化(初始化前,必须经过加载、验证、准备阶段):

        (1)使用new实例化对象时,读取和设置类的静态变量、静态非字面值常量(静态字面值常量除外)时,调用静态方法时。

        (2)对内进行反射调用时。

        (3)当初始化一个类时,如果父类没有进行初始化,需要先初始化父类。

        (4)启动程序所使用的main方法所在类

        (5)当使用1.7的动态语音支持时。

        如上5种场景又被称为主动引用,除此之外的引用称为被动引用,被动引用有如下3种常见情况

    • 通过子类引用父类的静态字段,只会触发父类的初始化,而不会触发子类的初始化。
    • 定义对象数组和集合,不会触发该类的初始化
    • 类A引用类B的static final常量不会导致类B初始化(注意静态常量必须是字面值常量,否则还是会触发B的初始化)
    public class TestClass {
        public static void main(String[] args) {
            System.out.println(ClassInit.str);
            System.out.println(ClassInit.id);
        }
    }
    class ClassInit{
        public static final long id=IdGenerator.getIdWorker().nextId();//需要初始化ClassInit类
        public static final String str="abc";//字面值常量
        static{
            System.out.println("ClassInit init");
        }
    }
    • 通过类名获取Class对象,不会触发类的初始化。如System.out.println(Person.class);
    • 通过Class.forName加载指定类时,如果指定参数initialize为false时,也不会触发类初始化。
    • 通过ClassLoader默认的loadClass方法,也不会触发初始化动作

        注意:被动引用不会导致类初始化,但不代表类不会经历加载、验证、准备阶段。

        3. 类加载方式

        这里的类加载不是指类加载阶段,而是指整个类加载过程,即类加载阶段到初始化完成。

       (1)隐式加载

    • 创建类对象
    • 使用类的静态域
    • 创建子类对象
    • 使用子类的静态域
    • 在JVM启动时,BootStrapLoader会加载一些JVM自身运行所需的class
    • 在JVM启动时,ExtClassLoader会加载指定目录下一些特殊的class
    • 在JVM启动时,AppClassLoader会加载classpath路径下的class,以及main函数所在的类的class文件

        (2)显式加载

    • ClassLoader.loadClass(className),只加载和连接、不会进行初始化
    • Class.forName(String name, boolean initialize,ClassLoader loader); 使用loader进行加载和连接,根据参数initialize决定是否初始化。

    2. 加载阶段

        加载是类加载过程中的一个阶段,不要将这2个概念混淆了。

        在加载阶段,虚拟机需要完成以下3件事情:

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

        加载.class文件的方式

    • 从本地系统中直接加载
    • 通过网络下载.class文件
    • 从zip,jar等归档文件中加载.class文件
    • 从专有数据库中提取.class文件
    • 将Java源文件动态编译为.class文件    

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

    3. 连接阶段

      3.1 验证:确保被加载的类的正确性

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

    • 文件格式验证:验证字节流是否符合Class文件格式的规范,如:是否以模数0xCAFEBABE开头、主次版本号是否在当前虚拟机处理范围内等等。
    • 元数据验证:对字节码描述的信息进行语义分析,以保证其描述的信息符合Java语言规范的要求;如:这个类是否有父类,是否实现了父类的抽象方法,是否重写了父类的final方法,是否继承了被final修饰的类等等。
    • 字节码验证:通过数据流和控制流分析,确定程序语义是合法的、符合逻辑的,如:操作数栈的数据类型与指令代码序列能配合工作,保证方法中的类型转换有效等等。
    • 符号引用验证:确保解析动作能正确执行;如:通过符合引用能找到对应的类和方法,符号引用中类、属性、方法的访问性是否能被当前类访问等等。

        验证阶段是非常重要的,但不是必须的。可以采用-Xverify:none参数来关闭大部分的类验证措施。

      3.2 准备:为类的静态变量分配内存,并将其赋默认值

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

    • 只对static修饰的静态变量进行内存分配、赋默认值(如0、0L、null、false等)。
    • 对final的静态字面值常量直接赋初值(赋初值不是赋默认值,如果不是字面值静态常量,那么会和静态变量一样赋默认值)。

      3.3 解析:将常量池中的符号引用替换为直接引用(内存地址)的过程

        符号引用就是一组符号来描述目标,可以是任何字面量。属于编译原理方面的概念如:包括类和接口的全限定名、字段的名称和描述符、方法的名称和描述符。

        直接引用就是直接指向目标的指针、相对偏移量或一个间接定位到目标的句柄。如指向方法区某个类的一个指针。

        假设:一个类有一个静态变量,该静态变量是一个自定义的类型,那么经过解析后,该静态变量将是一个指针,指向该类在方法区的内存地址。 具体见后续文章。

    4. 初始化:为类的静态变量赋初值

        赋初值两种方式:

    • 定义静态变量时指定初始值。如 private static String x="123";
    • 静态代码块里为静态变量赋值。如 static{ x="123"; } 

        注意:只有对类的主动使用才会导致类的初始化。

    5. clinit 与 init

        在编译生成class文件时,编译器会产生两个方法加于class文件中,一个是类的初始化方法clinit, 另一个是实例的初始化方法init。

      5.1 clinit 

        clinit指的是类构造器,主要作用是在类加载过程中的初始化阶段进行执行,执行内容包括静态变量初始化和静态块的执行。

        注意事项:

        1. 如果类中没有静态变量或静态代码块,那么clinit方法将不会被生成。

        2. 在执行clinit方法时,必须先执行父类的clinit方法。

        3. clinit方法只执行一次。

        3. static变量的赋值操作和静态代码块的合并顺序由源文件中出现的顺序决定。如下代码所示:

    public class TestClass {
        public static void main(String[] args) {
            ClassInit init=ClassInit.newInstance();
    
            System.out.println(init.x);
            System.out.println(init.y);
        }
    }
    
    class ClassInit{
        private static ClassInit init=new ClassInit();
        public static int x;
        public static int y=0;
        static{
            x=10;
            y=10;
        }
        private ClassInit(){
            x++;
            y++;
        }
        public static ClassInit newInstance(){
            return init;
        }
    }
    //在类加载到连接完成阶段,ClassInit类在内存中的状态为:init=null,x=0,y=0
    //初始化阶段时,需要执行clinit方法,该方法类似如下伪代码:
    clinit(){
    	//init=new ClassInit();调用构造方法
        x++;//x=1 因为此时x的值为连接的准备阶段赋的默认值0,然后++变成1
        y++;//y=1 因为此时y的值为连接的准备阶段赋的默认值0,然后++变成1
        //x=0;//为什么这里没有执行x=0,因为程序没有给x赋初值,因此在初始化阶段时,不会执行赋初值操作
        y=0;//因为类变量y在定义时,指定了初值,尽管初值为0,因此在初始化阶段的时候,需要执行赋初值操作
        x++;//第一个静态块的自增操作,结果为x=2;
        y++;//第一个静态块的自增操作,结果为y=1;
    }
    //所以最终结果为x=2,y=1
    //如果private static ClassInit init=new ClassInit(); 代码在public static int y=0;后面,那么clinit方法的伪代码如下:
    clinit(){
        //x=0;//这里虽然没有执行,但此时x的值为连接的准备阶段赋的默认值0
        y=0;//因为类变量y在定义时,指定了初值,尽管初值为0,因此在初始化阶段的时候,需要执行赋初值操作
    	//init=new ClassInit();调用构造方法
        x++;//x=1 因为此时x的值为连接的准备阶段赋的默认值0,然后++变成1
        y++;//y=1 因为此时y的值为初始化阶段赋的初值,只是这个初值刚好等于默认值0而已,然后++变成1
        x++;//第一个静态块的自增操作,结果为x=2;
        y++;//第一个静态块的自增操作,结果为y=2;
    }
    //最终结果为x=2,y=2

        5.2 init

        init指的是实例构造器,主要作用是在类实例化过程中执行,执行内容包括成员变量初始化和代码块的执行。

        注意事项:

        1. 如果类中没有成员变量和代码块,那么clinit方法将不会被生成。

        2. 在执行init方法时,必须先执行父类的init方法。

        3. init方法每实例化一次就会执行一次。

        3. init方法先为实例变量分配内存空间,再执行赋默认值,然后根据源码中的顺序执行赋初值或代码块。如下代码所示:

    public class TestClass {
        public static void main(String[] args) {
            ClassInit init=new ClassInit();
        }
    }
    
    class ClassInit{
        public int x;
        public int y=111;
        public ClassInit(){
            x=1;
            y=1;
        }
        {
            x=2;
            y=2;
        }
        {
            x=3;
            y=3;
        }
    }
    //实例化步骤为:先为属性分配空间,再执行赋默认值,然后按照顺序执行代码块或赋初始值,最后执行构造方法
    //根据上述代码,init方法的伪代码如下:
    init(){
    	x=0;//赋默认值
        y=0;//赋默认值
        y=111;//赋初值
        x=2;//从上到下执行第一个代码块
        y=2;//从上到下执行第一个代码块
        x=3;//从上到下执行第二个代码块
        y=3;//从上到下执行第二个代码块
        //ClassInit();执行构造方法
        x=1;//最后执行构造方法
        y=1;//最后执行构造方法
    }
    //如果上述代码的成员变量x,y的定义在类最后时,那么init方法的伪代码如下:
    init(){
    	x=0;//赋默认值
        y=0;//赋默认值
        x=2;//从上到下执行第一个代码块
        y=2;//从上到下执行第一个代码块
        x=3;//从上到下执行第二个代码块
        y=3;//从上到下执行第二个代码块
        y=111;//赋初值
        //ClassInit();执行构造方法
        x=1;//最后执行构造方法
        y=1;//最后执行构造方法
    }

    6. 卸载阶段

        执行了System.exit()方法

        程序正常执行结束

        程序在执行过程中遇到了异常或错误而异常终止

        由于操作系统出现错误而导致Java虚拟机进程终止
       

    展开全文
  • 一、为什么要使用类加载器? Java语言里,类加载都是在程序运行期间完成的,这种策略虽然会令类加载时稍微增加一些性能开销,但是会给java应用程序提供高度的灵活性。例如: 1.编写一个面向接口的应用程序,可能...

    一、为什么要使用类加载器?
    Java语言里,类加载都是在程序运行期间完成的,这种策略虽然会令类加载时稍微增加一些性能开销,但是会给java应用程序提供高度的灵活性。例如:
    1.编写一个面向接口的应用程序,可能等到运行时再指定其实现的子类;
    2.用户可以自定义一个类加载器,让程序在运行时从网络或其他地方加载一个二进制流作为程序代码的一部分;(这个是Android插件化,动态安装更新apk的基础)

     

    二、类加载的过程

    使用java编译器可以把java代码编译为存储字节码的Class文件,使用其他语言的编译器一样可以把程序代码翻译成Class文件,java虚拟机不关心Class的来源是何种语言。如图所示:

    在Class文件中描述的各种信息,最终都需要加载到虚拟机中才能运行和使用。那么虚拟机是如何加载这些Class文件的呢?
    JVM把描述类数据的字节码.Class文件加载到内存,并对数据进行校验、转换解析和初始化,最终形成可以被虚拟机直接使用的java类型,这就是虚拟机的类加载机制。

     

    类从被加载到虚拟机内存中开始,到卸载出内存为止,它的生命周期包括了:加载(Loading)、验证(Verification)、准备(Preparation)、解析(Resolution)、初始化(Initialization)、使用(Using)、卸载(Unloading)七个阶段,其中验证、准备、解析三个部分统称链接。


    加载(装载)、验证、准备、初始化和卸载这五个阶段顺序是固定的,类的加载过程必须按照这种顺序开始,而解析阶段不一定;它在某些情况下可以在初始化之后再开始,这是为了运行时动态绑定特性(JIT例如接口只在调用的时候才知道具体实现的是哪个子类)。值得注意的是:这些阶段通常都是互相交叉的混合式进行的,通常会在一个阶段执行的过程中调用或激活另外一个阶段。

     

    1.加载:(重点)
    加载阶段是“类加载机制”中的一个阶段,这个阶段通常也被称作“装载”,主要完成:
    1.通过“类全名”来获取定义此类的二进制字节流

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

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

    相对于类加载过程的其他阶段,加载阶段(准备地说,是加载阶段中获取类的二进制字节流的动作)是开发期可控性最强的阶段,因为加载阶段可以使用系统提供的类加载器(ClassLoader)来完成,也可以由用户自定义的类加载器完成,开发人员可以通过定义自己的类加载器去控制字节流的获取方式。

    加载阶段完成后,虚拟机外部的二进制字节流就按照虚拟机所需的格式存储在方法区之中,方法区中的数据存储格式有虚拟机实现自行定义,虚拟机并未规定此区域的具体数据结构。然后在java堆中实例化一个java.lang.Class类的对象,这个对象作为程序访问方法区中的这些类型数据的外部接口。

     

    2.验证:(了解)

    验证是链接阶段的第一步,这一步主要的目的是确保class文件的字节流中包含的信息符合当前虚拟机的要求,并且不会危害虚拟机自身安全。
    验证阶段主要包括四个检验过程:文件格式验证、元数据验证、字节码验证和符号引用验证。

    1.文件格式验证

     验证class文件格式规范,例如: class文件是否已魔术0xCAFEBABE开头 , 主、次版本号是否在当前虚拟机处理范围之内等

    2.元数据验证

    这个阶段是对字节码描述的信息进行语义分析,以保证起描述的信息符合java语言规范要求。验证点可能包括:这个类是否有父类(除了java.lang.Object之外,所有的类都应当有父类)、这个类是否继承了不允许被继承的类(被final修饰的)、如果这个类的父类是抽象类,是否实现了起父类或接口中要求实现的所有方法。

    3.字节码验证

     进行数据流和控制流分析,这个阶段对类的方法体进行校验分析,这个阶段的任务是保证被校验类的方法在运行时不会做出危害虚拟机安全的行为。如:保证访法体中的类型转换有效,例如可以把一个子类对象赋值给父类数据类型,这是安全的,但不能把一个父类对象赋值给子类数据类型、保证跳转命令不会跳转到方法体以外的字节码命令上。

    4.符号引用验证

    符号引用中通过字符串描述的全限定名是否能找到对应的类、符号引用类中的类,字段和方法的访问性(private、protected、public、default)是否可被当前类访问。

    3.准备:(了解)

    准备阶段是正式为类变量分配内存并设置类变量初始值的阶段,这些内存都将在方法区中进行分配。这个阶段中有两个容易产生混淆的知识点,首先是这时候进行内存分配的仅包括类变量(static 修饰的变量),而不包括实例变量,实例变量将会在对象实例化时随着对象一起分配在java堆中。其次是这里所说的初始值“通常情况”下是数据类型的零值,假设一个类变量定义为:

    public static int value  = 12;

    那么变量value在准备阶段过后的初始值为0而不是12,因为这时候尚未开始执行任何java方法,而把value赋值为123的putstatic指令是程序被编译后,存放于类构造器<clinit>()方法之中,所以把value赋值为12的动作将在初始化阶段才会被执行。

    上面所说的“通常情况”下初始值是零值,那相对于一些特殊的情况,如果类字段的字段属性表中存在ConstantValue属性,那在准备阶段变量value就会被初始化为ConstantValue属性所指定的值,建设上面类变量value定义为:

    public static final int value = 123;

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

     

    4.解析:(了解)
    解析阶段是虚拟机常量池内的符号引用替换为直接引用的过程。
    符号引用:符号引用是一组符号来描述所引用的目标对象,符号可以是任何形式的字面量,只要使用时能无歧义地定位到目标即可。符号引用与虚拟机实现的内存布局无关,引用的目标对象并不一定已经加载到内存中。

    直接引用:直接引用可以是直接指向目标对象的指针、相对偏移量或是一个能间接定位到目标的句柄。直接引用是与虚拟机内存布局实现相关的,同一个符号引用在不同虚拟机实例上翻译出来的直接引用一般不会相同,如果有了直接引用,那引用的目标必定已经在内存中存在。

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

    解析的动作主要针对类或接口、字段、类方法、接口方法四类符号引用进行。分别对应编译后常量池内的CONSTANT_Class_Info、CONSTANT_Fieldref_Info、CONSTANT_Methodef_Info、CONSTANT_InterfaceMethoder_Info四种常量类型。

    1.类、接口的解析

    2.字段解析

    3.类方法解析

    4.接口方法解析

     

    5.初始化:(了解)

    类的初始化阶段是类加载过程的最后一步,在准备阶段,类变量已赋过一次系统要求的初始值,而在初始化阶段,则是根据程序员通过程序制定的主观计划去初始化类变量和其他资源,或者可以从另外一个角度来表达:初始化阶段是执行类构造器<clinit>()方法的过程。在以下四种情况下初始化过程会被触发执行:

    1.遇到new、getstatic、putstatic或invokestatic这4条字节码指令时,如果类没有进行过初始化,则需先触发其初始化。生成这4条指令的最常见的java代码场景是:使用new关键字实例化对象、读取或设置一个类的静态字段(被final修饰、已在编译器把结果放入常量池的静态字段除外)的时候,以及调用类的静态方法的时候。

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

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

    4.jvm启动时,用户指定一个执行的主类(包含main方法的那个类),虚拟机会先初始化这个类

    在上面准备阶段 public static int value  = 12;  在准备阶段完成后 value的值为0,而在初始化阶调用了类构造器<clinit>()方法,这个阶段完成后value的值为12。

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

    *类构造器<clinit>()方法与类的构造函数(实例构造函数<init>()方法)不同,它不需要显式调用父类构造,虚拟机会保证在子类<clinit>()方法执行之前,父类的<clinit>()方法已经执行完毕。因此在虚拟机中的第一个执行的<clinit>()方法的类肯定是java.lang.Object。

    *由于父类的<clinit>()方法先执行,也就意味着父类中定义的静态语句快要优先于子类的变量赋值操作。

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

    *接口中不能使用静态语句块,但接口与类不太能够的是,执行接口的<clinit>()方法不需要先执行父接口的<clinit>()方法。只有当父接口中定义的变量被使用时,父接口才会被初始化。另外,接口的实现类在初始化时也一样不会执行接口的<clinit>()方法。

    *虚拟机会保证一个类的<clinit>()方法在多线程环境中被正确加锁和同步,如果多个线程同时去初始化一个类,那么只会有一个线程执行这个类的<clinit>()方法,其他线程都需要阻塞等待,直到活动线程执行<clinit>()方法完毕。如果一个类的<clinit>()方法中有耗时很长的操作,那就可能造成多个进程阻塞。

     

     

    三、类加载器

    JVM设计者把类加载阶段中的“通过'类全名'来获取定义此类的二进制字节流”这个动作放到Java虚拟机外部去实现,以便让应用程序自己决定如何去获取所需要的类。实现这个动作的代码模块称为“类加载器”。

     

    1.类与类加载器

    对于任何一个类,都需要由加载它的类加载器和这个类来确立其在JVM中的唯一性。也就是说,两个类来源于同一个Class文件,并且被同一个类加载器加载,这两个类才相等。

    2.双亲委派模型

    从虚拟机的角度来说,只存在两种不同的类加载器:一种是启动类加载器(Bootstrap ClassLoader),该类加载器使用C++语言实现,属于虚拟机自身的一部分。另外一种就是所有其它的类加载器,这些类加载器是由Java语言实现,独立于JVM外部,并且全部继承自抽象类java.lang.ClassLoader。

     

    从Java开发人员的角度来看,大部分Java程序一般会使用到以下三种系统提供的类加载器:
    1)启动类加载器(Bootstrap ClassLoader):负责加载JAVA_HOME\lib目录中并且能被虚拟机识别的类库到JVM内存中,如果名称不符合的类库即使放在lib目录中也不会被加载。该类加载器无法被Java程序直接引用。
    2)扩展类加载器(Extension ClassLoader):该加载器主要是负责加载JAVA_HOME\lib\,该加载器可以被开发者直接使用。
    3)应用程序类加载器(Application ClassLoader):该类加载器也称为系统类加载器,它负责加载用户类路径(Classpath)上所指定的类库,开发者可以直接使用该类加载器,如果应用程序中没有自定义过自己的类加载器,一般情况下这个就是程序中默认的类加载器。

    我们的应用程序都是由这三类加载器互相配合进行加载的,我们也可以加入自己定义的类加载器。这些类加载器之间的关系如下图所示:

    如上图所示的类加载器之间的这种层次关系,就称为类加载器的双亲委派模型(Parent Delegation Model)。该模型要求除了顶层的启动类加载器外,其余的类加载器都应当有自己的父类加载器。子类加载器和父类加载器不是以继承(Inheritance)的关系来实现,而是通过组合(Composition)关系来复用父加载器的代码。


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


    使用这种模型来组织类加载器之间的关系的好处是Java类随着它的类加载器一起具备了一种带有优先级的层次关系。例如java.lang.Object类,无论哪个类加载器去加载该类,最终都是由启动类加载器进行加载,因此Object类在程序的各种类加载器环境中都是同一个类。否则的话,如果不使用该模型的话,如果用户自定义一个java.lang.Object类且存放在classpath中,那么系统中将会出现多个Object类,应用程序也会变得很混乱。如果我们自定义一个rt.jar中已有类的同名Java类,会发现JVM可以正常编译,但该类永远无法被加载运行。
    在rt.jar包中的java.lang.ClassLoader类中,我们可以查看类加载实现过程的代码,具体源码如下:

    [java] view plain copy
    1. protected synchronized Class loadClass(String name, boolean resolve)  
    2.         throws ClassNotFoundException {  
    3.     // 首先检查该name指定的class是否有被加载  
    4.     Class c = findLoadedClass(name);  
    5.     if (c == null) {  
    6.         try {  
    7.             if (parent != null) {  
    8.                 // 如果parent不为null,则调用parent的loadClass进行加载  
    9.                 c = parent.loadClass(name, false);  
    10.             } else {  
    11.                 // parent为null,则调用BootstrapClassLoader进行加载  
    12.                 c = findBootstrapClass0(name);  
    13.             }  
    14.         } catch (ClassNotFoundException e) {  
    15.             // 如果仍然无法加载成功,则调用自身的findClass进行加载  
    16.             c = findClass(name);  
    17.         }  
    18.     }  
    19.     if (resolve) {  
    20.         resolveClass(c);  
    21.     }  
    22.     return c;  
    23. }  

    通过上面代码可以看出,双亲委派模型是通过loadClass()方法来实现的,根据代码以及代码中的注释可以很清楚地了解整个过程其实非常简单:先检查是否已经被加载过,如果没有则调用父加载器的loadClass()方法,如果父加载器为空则默认使用启动类加载器作为父加载器。如果父类加载器加载失败,则先抛出ClassNotFoundException,然后再调用自己的findClass()方法进行加载。

     

    3.自定义类加载器

    若要实现自定义类加载器,只需要继承java.lang.ClassLoader 类,并且重写其findClass()方法即可。java.lang.ClassLoader 类的基本职责就是根据一个指定的类的名称,找到或者生成其对应的字节代码,然后从这些字节代码中定义出一个 Java 类,即 java.lang.Class 类的一个实例。除此之外,ClassLoader 还负责加载 Java 应用所需的资源,如图像文件和配置文件等,ClassLoader 中与加载类相关的方法如下:

     
    方法                                 说明
    getParent()  返回该类加载器的父类加载器。

    loadClass(String name) 加载名称为 二进制名称为name 的类,返回的结果是 java.lang.Class 类的实例。

    findClass(String name) 查找名称为 name 的类,返回的结果是 java.lang.Class 类的实例。

    findLoadedClass(String name) 查找名称为 name 的已经被加载过的类,返回的结果是 java.lang.Class 类的实例。

    resolveClass(Class<?> c) 链接指定的 Java 类。


    注意:在JDK1.2之前,类加载尚未引入双亲委派模式,因此实现自定义类加载器时常常重写loadClass方法,提供双亲委派逻辑,从JDK1.2之后,双亲委派模式已经被引入到类加载体系中,自定义类加载器时不需要在自己写双亲委派的逻辑,因此不鼓励重写loadClass方法,而推荐重写findClass方法。

    在Java中,任意一个类都需要由加载它的类加载器和这个类本身一同确定其在java虚拟机中的唯一性,即比较两个类是否相等,只有在这两个类是由同一个类加载器加载的前提之下才有意义,否则,即使这两个类来源于同一个Class类文件,只要加载它的类加载器不相同,那么这两个类必定不相等(这里的相等包括代表类的Class对象的equals()方法、isAssignableFrom()方法、isInstance()方法和instanceof关键字的结果)。例子代码如下:

    [java] view plain copy
    1. /** 
    2.      * 一、ClassLoader加载类的顺序 
    3.      *  1.调用 findLoadedClass(String) 来检查是否已经加载类。 
    4.      *  2.在父类加载器上调用 loadClass 方法。如果父类加载器为 null,则使用虚拟机的内置类加载器。 
    5.      *  3.调用 findClass(String) 方法查找类。 
    6.      * 二、实现自己的类加载器 
    7.      *  1.获取类的class文件的字节数组 
    8.      *  2.将字节数组转换为Class类的实例 
    9.      * @author lei 2011-9-1 
    10.      */  
    11.     public class ClassLoaderTest {  
    12.         public static void main(String[] args) throws InstantiationException, IllegalAccessException, ClassNotFoundException {  
    13.             //新建一个类加载器  
    14.             MyClassLoader cl = new MyClassLoader("myClassLoader");  
    15.             //加载类,得到Class对象  
    16.             Class<?> clazz = cl.loadClass("classloader.Animal");  
    17.             //得到类的实例  
    18.             Animal animal=(Animal) clazz.newInstance();  
    19.             animal.say();  
    20.         }  
    21.     }  
    22.     class Animal{  
    23.         public void say(){  
    24.             System.out.println("hello world!");  
    25.         }  
    26.     }  
    27.     class MyClassLoader extends ClassLoader {  
    28.         //类加载器的名称  
    29.         private String name;  
    30.         //类存放的路径  
    31.         private String path = "E:\\workspace\\Algorithm\\src";  
    32.         MyClassLoader(String name) {  
    33.             this.name = name;  
    34.         }  
    35.         MyClassLoader(ClassLoader parent, String name) {  
    36.             super(parent);  
    37.             this.name = name;  
    38.         }  
    39.         /** 
    40.          * 重写findClass方法 
    41.          */  
    42.         @Override  
    43.         public Class<?> findClass(String name) {  
    44.             byte[] data = loadClassData(name);  
    45.             return this.defineClass(name, data, 0, data.length);  
    46.         }  
    47.         public byte[] loadClassData(String name) {  
    48.             try {  
    49.                 name = name.replace(".""//");  
    50.                 FileInputStream is = new FileInputStream(new File(path + name + ".class"));  
    51.                 ByteArrayOutputStream baos = new ByteArrayOutputStream();  
    52.                 int b = 0;  
    53.                 while ((b = is.read()) != -1) {  
    54.                     baos.write(b);  
    55.                 }  
    56.                 return baos.toByteArray();  
    57.             } catch (Exception e) {  
    58.                 e.printStackTrace();  
    59.             }  
    60.             return null;  
    61.         }  
    62.     }  

     

    类加载器双亲委派模型是从JDK1.2以后引入的,并且只是一种推荐的模型,不是强制要求的,因此有一些没有遵循双亲委派模型的特例:(了解)

    (1).在JDK1.2之前,自定义类加载器都要覆盖loadClass方法去实现加载类的功能,JDK1.2引入双亲委派模型之后,loadClass方法用于委派父类加载器进行类加载,只有父类加载器无法完成类加载请求时才调用自己的findClass方法进行类加载,因此在JDK1.2之前的类加载的loadClass方法没有遵循双亲委派模型,因此在JDK1.2之后,自定义类加载器不推荐覆盖loadClass方法,而只需要覆盖findClass方法即可。

    (2).双亲委派模式很好地解决了各个类加载器的基础类统一问题,越基础的类由越上层的类加载器进行加载,但是这个基础类统一有一个不足,当基础类想要调用回下层的用户代码时无法委派子类加载器进行类加载。为了解决这个问题JDK引入了ThreadContext线程上下文,通过线程上下文的setContextClassLoader方法可以设置线程上下文类加载器。

    JavaEE只是一个规范,sun公司只给出了接口规范,具体的实现由各个厂商进行实现,因此JNDI,JDBC,JAXB等这些第三方的实现库就可以被JDK的类库所调用。线程上下文类加载器也没有遵循双亲委派模型。

    (3).近年来的热码替换,模块热部署等应用要求不用重启java虚拟机就可以实现代码模块的即插即用,催生了OSGi技术,在OSGi中类加载器体系被发展为网状结构。OSGi也没有完全遵循双亲委派模型。

    4.动态加载Jar && ClassLoader 隔离问题

    动态加载Jar:

    Java 中动态加载 Jar 比较简单,如下:

    [java] view plain copy
    1. URL[] urls = new URL[] {new URL("file:libs/jar1.jar")};  
    2. URLClassLoader loader = new URLClassLoader(urls, parentLoader);  

    表示加载 libs 下面的 jar1.jar,其中 parentLoader 就是上面1中的 parent,可以为当前的 ClassLoader。


    ClassLoader 隔离问题:

    大家觉得一个运行程序中有没有可能同时存在两个包名和类名完全一致的类?
    JVM 及 Dalvik 对类唯一的识别是 ClassLoader id + PackageName + ClassName,所以一个运行程序中是有可能存在两个包名和类名完全一致的类的。并且如果这两个”类”不是由一个 ClassLoader 加载,是无法将一个类的示例强转为另外一个类的,这就是 ClassLoader 隔离。 如 Android 中碰到如下异常

    [java] view plain copy
    1. android.support.v4.view.ViewPager can not be cast to android.support.v4.view.ViewPager  

    当碰到这种问题时可以通过 instance.getClass().getClassLoader(); 得到 ClassLoader,看 ClassLoader 是否一样。

     

    加载不同 Jar 包中公共类:

    现在 Host 工程包含了 common.jar, jar1.jar, jar2.jar,并且 jar1.jar 和 jar2.jar 都包含了 common.jar,我们通过 ClassLoader 将 jar1, jar2 动态加载进来,这样在 Host 中实际是存在三份 common.jar,如下图:

    https://farm4.staticflickr.com/3872/14301963930_2f0f0fe8aa_o.png

    我们怎么保证 common.jar 只有一份而不会造成上面3中提到的 ClassLoader 隔离的问题呢,其实很简单,在生成 jar1 和 jar2 时把 common.jar 去掉,只保留 host 中一份,以 host ClassLoader 为 parentClassLoader 即可。

     

    最后:

    一道面试题

    能不能自己写个类叫java.lang.System?

    答案:通常不可以,但可以采取另类方法达到这个需求。 
    解释:为了不让我们写System类,类加载采用委托机制,这样可以保证爸爸们优先,爸爸们能找到的类,儿子就没有机会加载。而System类是Bootstrap加载器加载的,就算自己重写,也总是使用Java系统提供的System,自己写的System类根本没有机会得到加载。

    但是,我们可以自己定义一个类加载器来达到这个目的,为了避免双亲委托机制,这个类加载器也必须是特殊的。由于系统自带的三个类加载器都加载特定目录下的类,如果我们自己的类加载器放在一个特殊的目录,那么系统的加载器就无法加载,也就是最终还是由我们自己的加载器加载。



    展开全文
  • 一、Java语言的跨平台性的含义 Java语言之所以说它是跨平台的、可以在当前绝大部分的操作系统平台下运行,是因为Java语言的运行环境是在Java虚拟机中。 Java虚拟机消除了各个平台之间的差异,只要操作系统平台下...

    0、前言

    读完本文,你将了解到:

    一、为什么说Jabalpur语言是跨平台的

    二、Java虚拟机启动、加载类过程分析

    三、类加载器有哪些?其组织结构是怎样的?

    四、双亲加载模型的逻辑和底层代码实现是怎样的?

    五、类加载器与Class<T>  实例的关系

    六、线程上下文加载器

    一、为什么说Java语言是跨平台的?

    Java语言之所以说它是跨平台的、可以在当前绝大部分的操作系统平台下运行,是因为Java语言的运行环境是在Java虚拟机中。
    Java虚拟机消除了各个平台之间的差异,只要操作系统平台下安装了Java虚拟机,那么使用Java开发的东西都能在其上面运行。如下图所示:

    这里写图片描述

             Java虚拟机对各个平台而言,实质上是各个平台上的一个可执行程序。例如在windows平台下,java虚拟机对于windows而言,就是一个java.exe进程而已。

    二、Java虚拟机启动、加载类过程分析

    下面我将定义一个非常简单的java程序并运行它,来逐步分析java虚拟机启动的过程。

    package org.luanlouis.jvm.load;
    import sun.security.pkcs11.P11Util;
    
    /**
     * Created by louis on 2016/1/16.
     */
    public class Main{
    
        public static void main(String[] args) {
            System.out.println("Hello,World!");
    
            ClassLoader loader = P11Util.class.getClassLoader();
    
            System.out.println(loader);
        }
    }

    在windows命令行下输入:
    java    org.luanlouis.jvm.load.Main
    当输入上述的命令时:
    windows开始运行{JRE_HOME}/bin/java.exe程序,java.exe 程序将完成以下步骤:
    1.  根据JVM内存配置要求,为JVM申请特定大小的内存空间;

    2.  创建一个引导类加载器实例,初步加载系统类到内存方法区区域中;

    3.   创建JVM 启动器实例 Launcher,并取得类加载器ClassLoader

    4.  使用上述获取的ClassLoader实例加载我们定义的 org.luanlouis.jvm.load.Main类;

    5.  加载完成时候JVM会执行Main类的main方法入口,执行Main类的main方法;

    6.  结束,java程序运行结束,JVM销毁。

    Step 1.根据JVM内存配置要求,为JVM申请特定大小的内存空间


    为了不降低本文的理解难度,这里就不详细介绍JVM内存配置要求的话题,今概括地介绍一下内存的功能划分。

    JVM启动时,按功能划分,其内存应该由以下几部分组成:
    这里写图片描述
    如上图所示,JVM内存按照功能上的划分,可以粗略地划分为方法区(Method Area)堆(Heap),而所有的类的定义信息都会被加载到方法区中。

    关于具体方法区里有什么内容,读者可以参考我的另一篇博文:
    《Java虚拟机原理图解》3、JVM运行时数据区

    Step 2. 创建一个引导类加载器实例,初步加载系统类到内存方法区区域中;

    JVM申请好内存空间后,JVM会创建一个引导类加载器(Bootstrap Classloader)实例,引导类加载器是使用C++语言实现的,负责加载JVM虚拟机运行时所需的基本系统级别的类,如java.lang.String, java.lang.Object等等。

    引导类加载器(Bootstrap Classloader)会读取 {JRE_HOME}/lib 下的jar包和配置,然后将这些系统类加载到方法区内。

    本例中,引导类加载器是用 {JRE_HOME}/lib加载类的,不过,你也可以使用参数 -Xbootclasspath 或 系统变量sun.boot.class.path来指定的目录来加载类。

    一般而言,{JRE_HOME}/lib下存放着JVM正常工作所需要的系统类,如下表所示:

    文件名 描述
    rt.jar 运行环境包,rt即runtime,J2SE 的类定义都在这个包内
    charsets.jar 字符集支持包
    jce.jar 是一组包,它们提供用于加密、密钥生成和协商以及 Message Authentication Code(MAC)算法的框架和实现
    jsse.jar 安全套接字拓展包Java(TM) Secure Socket Extension
    classlist 该文件内表示是引导类加载器应该加载的类的清单
    net.properties JVM 网络配置信息

    引导类加载器(Bootstrap ClassLoader) 加载系统类后,JVM内存会呈现如下格局:
    这里写图片描述

    • 引导类加载器将类信息加载到方法区中,以特定方式组织,对于某一个特定的类而言,在方法区中它应该有 运行时常量池类型信息字段信息方法信息类加载器的引用对应class实例的引用等信息。
    • 类加载器的引用,由于这些类是由引导类加载器(Bootstrap Classloader)进行加载的,而 引导类加载器是有C++语言实现的,所以是无法访问的,故而该引用为NULL
    • 对应class实例的引用, 类加载器在加载类信息放到方法区中后,会创建一个对应的Class 类型的实例放到堆(Heap)中, 作为开发人员访问方法区中类定义的入口和切入点。
    小测试:
    当我们在代码中尝试获取系统类如java.lang.Object的类加载器时,你会始终得到NULL:
            System.out.println(String.class.getClassLoader());//null
            System.out.println(Object.class.getClassLoader());//null
            System.out.println(Math.class.getClassLoader());//null
            System.out.println(System.class.getClassLoader());//null


    Step 3. 创建JVM 启动器实例 Launcher,并取得类加载器ClassLoader

    上述步骤完成,JVM基本运行环境就准备就绪了。接着,我们要让JVM工作起来了:运行我们定义的程序 org.luanlouis,jvm.load.Main

    此时,JVM虚拟机调用已经加载在方法区的类sun.misc.Launcher 的静态方法getLauncher(),  获取sun.misc.Launcher 实例:

    sun.misc.Launcher launcher = sun.misc.Launcher.getLauncher(); //获取Java启动器
    ClassLoader classLoader = launcher.getClassLoader();          //获取类加载器ClassLoader用来加载class到内存来
    


    sun.misc.Launcher 使用了单例模式设计,保证一个JVM虚拟机内只有一个sun.misc.Launcher实例。
    在Launcher的内部,其定义了两个类加载器(ClassLoader),分别是sun.misc.Launcher.ExtClassLoadersun.misc.Launcher.AppClassLoader,这两个类加载器分别被称为拓展类加载器(Extension ClassLoader)应用类加载器(Application ClassLoader).如下图所示:

    图例注释:除了引导类加载器(Bootstrap Class Loader )的所有类加载器,都有一个能力,就是判断某一个类是否被引导类加载器加载过,如果加载过,可以直接返回对应的Class<T> instance,如果没有,则返回null.  图上的指向引导类加载器的虚线表示类加载器的这个有限的访问 引导类加载器的功能。

          此时的  launcher.getClassLoader() 方法将会返回 AppClassLoader 实例,AppClassLoaderExtClassLoader作为自己的父加载器。

    AppClassLoader加载类时,会首先尝试让父加载器ExtClassLoader进行加载,如果父加载器ExtClassLoader加载成功,则AppClassLoader直接返回父加载器ExtClassLoader加载的结果;如果父加载器ExtClassLoader加载失败,AppClassLoader则会判断该类是否是引导的系统类(即是否是通过Bootstrap类加载器加载,这会调用Native方法进行查找);若要加载的类不是系统引导类,那么ClassLoader将会尝试自己加载,加载失败将会抛出“ClassNotFoundException”。

    具体AppClassLoader的工作流程如下所示:



    双亲委派模型(parent-delegation model):
    上面讨论的应用类加载器AppClassLoader的加载类的模式就是我们常说的双亲委派模型(parent-delegation model).
    对于某个特定的类加载器而言,应该为其指定一个父类加载器,当用其进行加载类的时候:
    1. 委托父类加载器帮忙加载;
    2. 父类加载器加载不了,则查询引导类加载器有没有加载过该类;
    3. 如果引导类加载器没有加载过该类,则当前的类加载器应该自己加载该类;
    4. 若加载成功,返回 对应的Class<T> 对象;若失败,抛出异常“ClassNotFoundException”。
    请注意:
    双亲委派模型中的"双亲"并不是指它有两个父类加载器的意思,一个类加载器只应该有一个父加载器。上面的步骤中,有两个角色:
    1. 父类加载器(parent classloader):它可以替子加载器尝试加载类
    2. 引导类加载器(bootstrap classloader): 子类加载器只能判断某个类是否被引导类加载器加载过,而不能委托它加载某个类;换句话说,就是子类加载器不能接触到引导类加载器,引导类加载器对其他类加载器而言是透明的。


    一般情况下,双亲加载模型如下所示:




    Step 4. 使用类加载器ClassLoader加载Main类

    通过 launcher.getClassLoader()方法返回AppClassLoader实例,接着就是AppClassLoader加载 org.luanlouis.jvm.load.Main类的时候了。

    ClassLoader classloader = launcher.getClassLoader();//取得AppClassLoader类
    classLoader.loadClass("org.luanlouis.jvm.load.Main");//加载自定义类

    上述定义的org.luanlouis.jvm.load.Main类被编译成org.luanlouis.jvm.load.Main class二进制文件,这个class文件中有一个叫常量池(Constant Pool)的结构体来存储该class的常亮信息。常量池中有CONSTANT_CLASS_INFO类型的常量,表示该class中声明了要用到那些类:


    当AppClassLoader要加载 org.luanlouis.jvm.load.Main类时,会去查看该类的定义,发现它内部声明使用了其它的类: sun.security.pkcs11.P11Util、java.lang.Object、java.lang.System、java.io.PrintStream、java.lang.Class;org.luanlouis.jvm.load.Main类要想正常工作,首先要能够保证这些其内部声明的类加载成功。所以AppClassLoader要先将这些类加载到内存中。(注:为了理解方便,这里没有考虑懒加载的情况,事实上的JVM加载类过程比这复杂的多)

    加载顺序:

    1. 加载java.lang.Object、java.lang.System、java.io.PrintStream、java,lang.Class

         AppClassLoader尝试加载这些类的时候,会先委托ExtClassLoader进行加载;而ExtClassLoader发现不是其加载范围,其返回null;AppClassLoader发现父类加载器ExtClassLoader无法加载,则会查询这些类是否已经被BootstrapClassLoader加载过,结果表明这些类已经被BootstrapClassLoader加载过,则无需重复加载,直接返回对应的Class<T>实例;

    2. 加载sun.security.pkcs11.P11Util

        此在{JRE_HOME}/lib/ext/sunpkcs11.jar包内,属于ExtClassLoader负责加载的范畴。AppClassLoader尝试加载这些类的时候,会先委托ExtClassLoader进行加载;而ExtClassLoader发现其正好属于加载范围,故ExtClassLoader负责将其加载到内存中。ExtClassLoader在加载sun.security.pkcs11.P11Util时也分析这个类内都使用了哪些类,并将这些类先加载内存后,才开始加载sun.security.pkcs11.P11Util,加载成功后直接返回对应的Class<sun.security.pkcs11.P11Util>实例;

    3. 加载org.luanlouis.jvm.load.Main

      AppClassLoader尝试加载这些类的时候,会先委托ExtClassLoader进行加载;而ExtClassLoader发现不是其加载范围,其返回null;AppClassLoader发现父类加载器ExtClassLoader无法加载,则会查询这些类是否已经被BootstrapClassLoader加载过。而结果表明BootstrapClassLoader 没有加载过它,这时候AppClassLoader只能自己动手负责将其加载到内存中,然后返回对应的Class<org.luanlouis.jvm.load.Main>实例引用;

    以上三步骤都成功,才表示classLoader.loadClass("org.luanlouis.jvm.load.Main")完成,上述操作完成后,JVM内存方法区的格局会如下所示:


    如上图所示:

    • JVM方法区的类信息区是按照类加载器进行划分的,每个类加载器会维护自己加载类信息;
    • 某个类加载器在加载相应的类时,会相应地在JVM内存堆(Heap)中创建一个对应的Class<T>,用来表示访问该类信息的入口

    Step 5. 使用Main类的main方法作为程序入口运行程序

    Step 6. 方法执行完毕,JVM销毁,释放内存

    三、类加载器有哪些?其组织结构是怎样的?

                 类加载器(Class Loader):顾名思义,指的是可以加载类的工具。JVM自身定义了三个类加载器:引导类加载器(Bootstrap Class Loader)、拓展类加载器(Extension Class Loader )、应用加载器(Application Class Loader)。当然,我们有时候也会自己定义一些类加载器来满足自身的需要。

                引导类加载器(Bootstrap Class Loader): 该类加载器使JVM使用C/C++底层代码实现的加载器,用以加载JVM运行时所需要的系统类,这些系统类在{JRE_HOME}/lib目录下。由于类加载器是使用平台相关的底层C/C++语言实现的, 所以该加载器不能被Java代码访问到。但是,我们可以查询某个类是否被引导类加载器加载过。我们经常使用的系统类如:java.lang.String,java.lang.Object,java.lang*....... 这些都被放在 {JRE_HOME}/lib/rt.jar包内, 当JVM系统启动的时候,引导类加载器会将其加载到 JVM内存的方法区中。

               拓展类加载器(Extension Class Loader): 该加载器是用于加载 java 的拓展类 ,拓展类一般会放在 {JRE_HOME}/lib/ext/ 目录下,用来提供除了系统类之外的额外功能。拓展类加载器是是整个JVM加载器的Java代码可以访问到的类加载器的最顶端,即是超级父加载器,拓展类加载器是没有父类加载器的。

               应用类加载器(Applocatoin Class Loader): 该类加载器是用于加载用户代码,是用户代码的入口。我经常执行指令 java   xxx.x.xxx.x.x.XClass , 实际上,JVM就是使用的AppClassLoader加载 xxx.x.xxx.x.x.XClass 类的。应用类加载器将拓展类加载器当成自己的父类加载器,当其尝试加载类的时候,首先尝试让其父加载器-拓展类加载器加载;如果拓展类加载器加载成功,则直接返回加载结果Class<T> instance,加载失败,则会询问是否引导类加载器已经加载了该类;只有没有加载的时候,应用类加载器才会尝试自己加载。由于xxx.x.xxx.x.x.XClass是整个用户代码的入口,在Java虚拟机规范中,称其为 初始类(Initial Class).

       
               用户自定义类加载器(Customized Class Loader):用户可以自己定义类加载器来加载类。所有的类加载器都要继承java.lang.ClassLoader类。

              



    四、双亲加载模型的逻辑和底层代码实现是怎样的?

                上面已经不厌其烦地讲解什么是双亲加载模型,以及其机制是什么,这些东西都是可以通过底层代码查看到的。

                 我们也可以通过JDK源码看java.lang.ClassLoader的核心方法 loadClass()的实现:

        
        
        //提供class类的二进制名称表示,加载对应class,加载成功,则返回表示该类对应的Class<T> instance 实例
        public Class<?> loadClass(String name) throws ClassNotFoundException {
            return loadClass(name, false);
        }
     
        
        protected Class<?> loadClass(String name, boolean resolve)
            throws ClassNotFoundException
        {
            synchronized (getClassLoadingLock(name)) {
                // 首先,检查是否已经被当前的类加载器记载过了,如果已经被加载,直接返回对应的Class<T>实例
                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;
            }
        }

     相对应地,我们可以整理出双亲模型的工作流程图:


    相信读者看过这张图后会对双亲加载模型有了非常清晰的脉络。当然,这是JDK自身默认的加载类的行为,我们可以通过继承复写该方法,改变其行为。

    五、类加载器与Class<T>  实例的关系






    六、线程上下文加载器

                 Java 任何一段代码的执行,都有对应的线程上下文。如果我们在代码中,想看当前是哪一个线程在执行当前代码,我们经常是使用如下方法:

    Thread  thread = Thread.currentThread();//返回对当当前运行线程的引用


    相应地,我们可以为当前的线程指定类加载器。在上述的例子中, 当执行   java    org.luanlouis.jvm.load.Main  的时候,JVM会创建一个Main线程,而创建应用类加载器AppClassLoader的时候,会将AppClassLoader  设置成Main线程的上下文类加载器:

        public Launcher() {
            Launcher.ExtClassLoader var1;
            try {
                var1 = Launcher.ExtClassLoader.getExtClassLoader();
            } catch (IOException var10) {
                throw new InternalError("Could not create extension class loader", var10);
            }
    
            try {
                this.loader = Launcher.AppClassLoader.getAppClassLoader(var1);
            } catch (IOException var9) {
                throw new InternalError("Could not create application class loader", var9);
            }
    		//将AppClassLoader设置成当前线程的上下文加载器
            Thread.currentThread().setContextClassLoader(this.loader);
            //.......
    
        }

    线程上下文类加载器是从线程的角度来看待类的加载,为每一个线程绑定一个类加载器,可以将类的加载从单纯的 双亲加载模型解放出来,进而实现特定的加载需求。



    展开全文
  • java类加载过程

    千次阅读 2015-11-18 16:00:30
    类加载过程  类从被加载到虚拟机内存中开始,到卸载出内存为止,它的整个生命周期包括:加载、验证、准备、解析、初始化、使用和卸载七个阶段。它们开始的顺序如下图所示:  其中类加载的过程包括了...
  • 面试官:请你谈谈Java的类加载过程

    万次阅读 多人点赞 2018-02-01 00:08:28
    刚刚走出校门的应届毕业生,如果在去寻求一份Java开发的工作时,你的面试官很有可能一边看着你的简历,一边漫不经心地问你:了解过Java类的加载过程吗?...今天,小编就Java类加载过程这个问题,抛砖引玉,说一下...
  • 代码如下: package classloader; import java.io.BufferedInputStream; import java.io.ByteArrayOutputStream; import java.io.File; import java.io.FileInputStream;...import java.io.IOException;...
  • 一、为什么要使用类加载器? Java语言里,类加载都是在程序运行期间完成的,这种策略虽然会令类加载时稍微增加一些性能开销,但是会给java应用程序提供高度的灵活性。例如: 1.编写一个面向接口的应用程序,可能等到...
  • 类加载过程和类加载器

    千次阅读 2018-03-05 22:03:16
    类加载过程 和其他语言一样,java编译器同样能够将.java文件编译成.class,但是对于JVM来讲,它并不关心,是哪种语言经过编译形成的。 JVM类加载工作原理:就是把类的class文件加载到内存中,并对数据进行校验、...
  • JAVA类加载机制JAVA类加载类加载层次关系 类加载机制的特性JAVA类加载机制JAVA类加载器java类加载器负责把一个一个编译好的class文件装入内存中,并为其创建对应的java.lang.Class对象。java中有如下几种类加载器...
  • JVM的类加载过程

    千次阅读 2019-03-16 11:38:42
    创建类加载器,类加载器从类路径根据需要加载的类的全限定名找到类文件.class,加载类文件,读取类文件字节码流,然后根据类文件的标准格式解析类文件内容,如最开头是魔数,然后是主次版本号等,根据静态常量池创建...
  • 一、类加载子系统的作用 类加载器子系统负责从文件系统或者网络中加载class文件,class问价在文件开头有特定的文件标识。 ClassLoader只负责class文件的加载,...二、类的加载过程 step1:加载 通过一..
  • JVM之类加载过程

    2015-04-08 13:32:49
    java虚拟机与程序的生命周期在... 由于操作系统出现错误而导致java虚拟机进程终止加载、连接与初始化加载:查找并加载类的二进制数据 连接 * 验证:确保被加载的正确性 * 准备:为的静态变量分配内存

空空如也

1 2 3 4 5 ... 20
收藏数 18,407
精华内容 7,362
关键字:

类加载过程