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

与那些在编译时需要进行连接的语言不同,在Java语言里面,类型的加载、连接和初始化过程都是在程序运行期间完成

这种策略让Java语言进行提前编译会面临额外的困难,也会让类加载时稍微增加一些性能开销

但是却为Java应用提供了极高的扩展性和灵活性,Java天生可以动态扩展的语言特性就是依赖 运行期动态加载和动态连接 这个特点实现的。

例如,编写一个面向接口的应用程序,可以等到运行时再指定其实际的实现类,用户可以通过Java预置的或自定义类加载器,让某个本地的应用程序在运行时从网络 或其他地方上加载一个二进制流作为其程序代码的一部分。这种动态组装应用的方式目前已广泛应用 于Java程序之中,从最基础的Applet、JSP到相对复杂的OSGi技术,都依赖着Java语言运行期类加载才 得以诞生。

 

类加载的时机

一个类型从被加载到虚拟机内存中开始,到卸载出内存为止,它的整个生命周期将会经历下图这七个阶段。这七个阶段的发生顺序如图7-1所示。

图7-1中,加载、验证、准备、初始化和卸载这 五个阶段的顺序是确定的,类型的加载过程必须按 照这种顺序按部就班地开始,

而 解析阶段则不一定:它在某些情况下可以在初始化阶段之后再开始, 这是为了支持Java语言的运行时绑定特性(也称为动态绑定或晚期绑定)。

对于初始化阶段,《Java虚拟机规范》 则是严格规定了有且只有六种情况必须立即对类进行“初始化”(而加载、验证、准备自然需要在此之 前开始):

(1)遇到new、getstatic、putstatic或invokestatic这四条字节码指令时,如果类型没有进行过初始化,则需要先触发其初始化阶段。能够生成这四条指令的典型Java代码场景有:

  • 使用 new 关键字实例化对象的时候。
  • 读取或设置一个类型的 静态字段被final修饰、已在编译期把结果放入常量池的静态字段除外) 的时候。
  • 调用一个类型的 静态方法 的时候。

(2)使用java.lang.reflect包的方法 对类型进行反射调用 的时候,如果类型没有进行过初始化,则需 要先触发其初始化。

(3)当初始化类的时候,如果发现其父类还没有进行过初始化,则需要先触发其父类的初始化。

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

(5)当使用JDK 7新加入的动态语言支持时,如果一个java.lang.invoke.MethodHandle实例最后的解 析结果为 REF_getStatic、REF_putStatic、REF_invokeStatic、REF_newInvokeSpecial 四种类型的方法句柄,并且这个方法句柄对应的类没有进行过初始化,则需要先触发其初始化。

(6)当一个接口中定义了JDK 8新加入的默认方法(被default关键字修饰的接口方法)时,如果有 这个接口的实现类发生了初始化,那该接口要在其之前被初始化。

对于这六种会触发类型进行初始化的场景,《Java虚拟机规范》中使用了一个非常强烈的限定语 ——“有且只有”,这六种场景中的行为称为对一个类型进行主动引用。除此之外,所有引用类型的方式都不会触发初始化,称为被动引用。

被动引用的例子之一

上述代码运行之后,只会输出“SuperClass init!”,而不会输出“SubClass init!”。

对于静态字段, 只有直接定义这个字段的类才会被初始化,因此通过其 子类来引用父类中定义的静态字段,只会触发父类的初始化 而不会触发子类的初始化。

复制代码
package org.fenixsoft.classloading;
/**
* 被动使用类字段演示一:
* 通过子类引用父类的静态字段,不会导致子类初始化
**/
public class SuperClass {
  static {
    System.out.println("SuperClass init!");
  }
  public static int value = 123;
}


public class SubClass extends SuperClass {   static {     System.out.println("SubClass init!");   } }

/** * 非主动使用类字段演示 **/ public class NotInitialization {   public static void main(String[] args) {     System.out.println(SubClass.value);   } }
复制代码

 

 

被动引用的例子之二

这段代码复用了例子1中的SuperClass,运行之后发现没有输出“SuperClass init!”

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

触发了 另一个名为“[Lorg.fenixsoft.classloading.SuperClass”的类的初始化阶段,对于用户代码来说,这并不是 一个合法的类型名称,它是一个由虚拟机自动生成的、直接继承于java.lang.Object的子类,创建动作由 字节码指令newarray触发。 这个类代表了一个元素类型为org.fenixsoft.classloading.SuperClass的一维数组,数组中应有的属性和方法(用户可直接使用的只有被修饰为public的length属性和clone()方法)都实现在这个类里。Java语 言中对数组的访问要比C/C++相对安全,很大程度上就是因为这个类包装了数组元素的访问,而 C/C++中则是直接翻译为对数组指针的移动。在Java语言里,当检查到发生数组越界时会抛出 java.lang.ArrayIndexOutOfBoundsException异常,避免了直接造成非法内存访问

复制代码
package org.fenixsoft.classloading;
/**
* 被动使用类字段演示二:
* 通过数组定义来引用类,不会触发此类的初始化
**/
public class NotInitialization {
  public static void main(String[] args) {
    SuperClass[] sca = new SuperClass[10];
  }
}
复制代码

 

被动引用的例子之三

上述代码运行之后,也没有输出“ConstClass init!”

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

这是因为虽然在Java源码中确实引用了 ConstClass类的常量HELLOWORLD,但其实在编译阶段通过常量传播优化,已经将此常量的值“hello world”直接存储在NotInitialization类的常量池中,以后NotInitialization对常量 ConstClass.HELLOWORLD的引用,实际都被转化为NotInitialization类对自身常量池的引用了。也就是 说,实际上NotInitialization的Class文件之中并没有ConstClass类的符号引用入口,这两个类在编译成 Class文件后就已不存在任何联系了。

复制代码
package org.fenixsoft.classloading;
/**
* 被动使用类字段演示三:
* 常量在编译阶段会存入调用类的常量池中,本质上没有直接引用到定义常量的类,因此不会触发定义常量的
类的初始化
**/
public class ConstClass {
  static {
    System.out.println("ConstClass init!");
  }
  public static final String HELLOWORLD = "hello world";
}
/**
* 非主动使用类字段演示
**/
public class NotInitialization {
  public static void main(String[] args) {
    System.out.println(ConstClass.HELLOWORLD);
  }
}
复制代码

复习:

static
static是静态的意思,也是全局的意思。static定义的东西,属于全局,与类相关,不与具体实例相关,是类实例之间共享的。

1. 被static修饰的变量属于类变量,可以通过类名.变量名直接引用,而不需要new出一个对象来

2. 被static修饰的方法属于类方法,可以通过类名.方法名直接引用,而不需要new出一个对象来

static与非static的区别:

在内存中存放的位置不同:所有static修饰的属性和方法都放在内存的方法区(内存的方法区相当于常驻内存,如果一个方法或者变量声明为static,可以节约内存,不必要为每个对象实例化的时候分配内存)里,而非静态的都堆放在堆内存中

生命周期不同:静态在类消失后被销毁,非静态在对象销毁后销毁

final
final关键字有三个东西可以修饰,修饰非抽象类,修饰非抽象方法,修饰引用。

在类的声明中使用final:

使用了final的类不能再派生子类,就是不可以被继承,简称为断子绝孙类。类中的所有方法都不能被重写。

有一些java的面试题问,String可不可以被继承,答案是不可以。因为java.lang.String是一个final类。这可以保证String对象方法的调用确实运行的是String类的方法,而不是经其子类重写后的方法。

在方法的声明中使用final:

被定义为final的方法不能被重写,这个方法成为最终方法,但是该方法仍然可以被继承。final不能修饰构造方法。

在修饰引用中使用final:

如果引用为基本数据类型,这样变量就是常量了,在程序中这样的变量不可以被修改,修改编译器会报错,而且执行效率比普通的变量要高。

final的变量如果没有赋予初值的话,其他方法就必须给他赋值,但只能赋值一次。

如果引用为引用数据类型,比如对象,数组,则该对象、数组本身可以修改,但是指向该对象或数组的地址的引用不能修改。

如果引用的是类的成员变量,则必须当场赋值,否则编译会报错。

static和final一起用:

final与static final的区别是:final在一个对象类唯一,static final在多个对象中都唯一;一个既是static又是final的域只占据一段不能改变的存储空间,只有一份。

 

类加载的过程

1、加载

“加载”(Loading)阶段是整个“类加载”(Class Loading)过程中的一个阶段,希望读者没有混淆这两个看起来很相似的名词。

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

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

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

3)在内存中生成一个代表这个类的java.lang.Class对象作为方法区这个类的各种数据的访问入口。

“通过一个类的全限定名来获取定义此类的二进制字节流”这条规则,它并没有指明二进制字节流必须得从某个Class文件中获取,确切地说是根本没有指明要从哪里获取、如何获取。

仅仅这一点空隙,Java虚拟机的使用者们就可以在加载阶段搭构建出一个相当开放广阔的舞台,Java发展历 程中,充满创造力的开发人员则在这个舞台上玩出了各种花样,许多举足轻重的Java技术都建立在这 一基础之上,例如:

    • ZIP压缩包中读取,这很常见,最终成为日后JAR、EAR、WAR格式的基础。
    • 网络中获取,这种场景最典型的应用就是Web Applet。
    • 运行时计算生成,这种场景使用得最多的就是动态代理技术,在java.lang.reflect.Proxy中,就是用 了ProxyGenerator.generateProxyClass()来为特定接口生成形式为“*$Proxy”的代理类的二进制字节流。
    • 由其他文件生成,典型场景是JSP应用,由JSP文件生成对应的Class文件。
    • 从数据库中读取,这种场景相对少见些,例如有些中间件服务器(如SAP Netweaver)可以选择 把程序安装到数据库中来完成程序代码在集群间的分发。
    • 可以从加密文件中获取,这是典型的防Class文件被反编译的保护措施,通过加载时解密Class文件来保障程序运行逻辑不被窥探。

加载阶段既可以使用Java虚拟机里内置的引导类加载器来完成,也可以由用户自定义的类加载器去完成,开发人员通过定义自己的类加载器去控制字节流的获取方式(重写一个类加载器的findClass()或loadClass()方法),实现根据自己的想法来赋予应用 程序获取运行代码的动态性。

对于数组类而言,情况就有所不同,数组类本身不通过类加载器创建,它是由Java虚拟机直接在内存中动态构造出来的。但数组类与类加载器仍然有很密切的关系,因为数组类的元素类型(Element Type,指的是数组去掉所有维度的类型)最终还是要靠类加载器来完成加载。

2、验证

验证是连接阶段的第一步,这一阶段的目的是 确保Class文件的字节流中包含的信息符合《Java虚 拟机规范》的全部约束要求,保证这些信息被当作代码运行后不会危害虚拟机自身的安全。

验证阶段是非常重要的,这个阶段是否严谨,直接决定了Java虚拟机是否能承受恶意代码的攻击,从代码量和耗费的执行性能的角度上讲,验证阶段的工作量在虚拟机的类加载过程中占了相当大 的比重。

1.文件格式验证

主要目的是保证输入的字节流能正确地解析并存储于方法区之内,格式上符 合描述一个Java类型信息的要求。这阶段的验证是基于二进制字节流进行的,只有通过了这个阶段的 验证之后,这段字节流才被允许进入Java虚拟机内存的方法区中进行存储,所以后面的三个验证阶段全部是基于方法区的存储结构上进行的,不会再直接读取、操作字节流了。

    • 是否以魔数0xCAFEBABE开头。
    • 主、次版本号是否在当前Java虚拟机接受范围之内。
    • 常量池的常量中是否有不被支持的常量类型(检查常量tag标志)。
    • ......

2.元数据验证

第二阶段的主要目的是对类的元数据信息进行语义校验,保证不存在与《Java语言规范》定义相悖的元数据信息。

    • 这个类是否有父类(除了java.lang.Object之外,所有的类都应当有父类)。 
    • 这个类的父类是否继承了不允许被继承的类(被final修饰的类)。
    • 如果这个类不是抽象类,是否实现了其父类或接口之中要求实现的所有方法。
    • ......

3.字节码验证

是整个验证过程中最复杂的一个阶段,主要目的是通过数据流分析控制流分析,确定 程序语义是合法的、符合逻辑的。在第二阶段对元数据信息中的数据类型校验完毕以后,这阶段就要对类的方法体(Class文件中的Code属性)进行校验分析,保证被校验类的方法在运行时不会做出危害 虚拟机安全的行为。

    • 保证任意时刻操作数栈的数据类型与指令代码序列都能配合工作,例如不会出现类似于“在操作 栈放置了一个int类型的数据,使用时却按long类型来加载入本地变量表中”这样的情况。
    • 保证任何跳转指令都不会跳转到方法体以外的字节码指令上。
    • 保证方法体中的类型转换总是有效的,例如可以把一个子类对象赋值给父类数据类型,这是安全的,但是把父类对象赋值给子类数据类型,甚至把对象赋值给与它毫无继承关系、完全不相干的一个 数据类型,则是危险和不合法的。
    • ……

如果一个类型中有方法体的字节码没有通过字节码验证,那它肯定是有问题的;

但如果一个方法 体通过了字节码验证,也仍然不能保证它一定就是安全的。即使字节码验证阶段中进行了再大量、再 严密的检查,也依然不能保证这一点。这里涉及了离散数学中一个很著名的问题——“停机问 题”(Halting Problem),即不能通过程序准确地检查出程序是否能在有限的时间之内结束运行在 我们讨论字节码校验的上下文语境里,通俗一点的解释是通过程序去校验程序逻辑是无法做到绝对准 确的,不可能用程序来准确判定一段程序是否存在Bug。

3.符号引用验证

发生在虚拟机将符号引用转化为直接引用的时候,这个转化动作将在 连接的第三阶段——解析阶段中发生。

可以看作是对类自身以外(常量池中的各种符号引用)的各类信息进行匹配性校验,通俗来说就是,该类是否缺少或者被禁止访问它依赖的某些外部 类、方法、字段等资源。本阶段通常需要校验下列内容:

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

如果无法通过符号引用验证,Java虚拟机 将会抛出一个java.lang.IncompatibleClassChangeError的子类异常,典型的如: java.lang.IllegalAccessError、java.lang.NoSuchFieldError、java.lang.NoSuchMethodError等。

3、准备

正式为类中定义的变量(即静态变量,被static修饰的变量是类共享的而不是实例共享的分配内存并设置类变量初始值(数据类型的0值)的阶段。

从概念上讲,这些变量所使用的内存都应当在方法区中进行分配

但必须注意到方法区 本身是一个逻辑上的区域,在JDK 7及之前,HotSpot使用永久代来实现方法区时,实现是完全符合这种逻辑概念的;而在JDK 8及之后类变量则会随着Class对象一起存放在Java堆中,这时候“类变量在方法区”就完全是一种对逻辑概念的表述了,

这时候进行内存分配的仅包括类变量,而不包括实例变量,实例变量将会在对象实例化时随着对象一起分配在Java堆中。

这里所说的初始值“通常情况”下是数据类型的零值,假设一个类变量的定义为:

public static int value = 123;

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

“特殊情况”:如果类字段 的字段属性表中存在ConstantValue属性,那在准备阶段变量值就会被初始化为ConstantValue属性所指定 的初始值,假设上面类变量value的定义修改为:

public static final int value = 123;

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

4、解析

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

复习

符号引用 则属于编译 原理方面的概念,主要包括下面几类常量:

    • 被模块导出或者开放的包(Package) 
    • 类和接口的全限定名(Fully Qualified Name)-- CONSTANT_Class_info
    • 字段的名称和描述符(Descriptor) -- CON-STANT_Fieldref_info
    • 方法的名称和描述符 -- 类方法 CONSTANT_Methodref_info / 接口方法 CONSTANT_InterfaceMethodref_info
    • 方法句柄和方法类型(Method Handle、Method Type、Invoke Dynamic)-- CONSTANT_MethodType_info 和 CONSTANT_MethodHandle_info
    • 动态调用点和动态常量(Dynamically-Computed Call Site、Dynamically-Computed Constant)-- CONSTANT_Dyna-mic_info 和 CONSTANT_InvokeDynamic_info

常量池中每一项常量都是一个表,最初常量表中共有11种结构各不相同的表结构数据,后来为了 更好地支持动态语言调用,额外增加了4种动态语言相关的常量。

package org.fenixsoft.clazz;
public class TestClass {
  private int m;
  public int inc() {
    return m + 1;
  }
}

上面那段代码的常量池符号引用

复制代码
C:\>javap -verbose TestClass
Compiled from "TestClass.java"
public class org.fenixsoft.clazz.TestClass extends java.lang.Object
SourceFile: "TestClass.java"
minor version: 0
major version: 50
Constant pool:
const #1 = class #2; // org/fenixsoft/clazz/TestClass
const #2 = Asciz org/fenixsoft/clazz/TestClass;
const #3 = class #4; // java/lang/Object
const #4 = Asciz java/lang/Object;
const #5 = Asciz m;
const #6 = Asciz I;
const #7 = Asciz <init>;
const #8 = Asciz ()V;
const #9 = Asciz Code;
const #10 = Method #3.#11; // java/lang/Object."<init>":()V
const #11 = NameAndType #7:#8;// "<init>":()V
const #12 = Asciz LineNumberTable;
const #13 = Asciz LocalVariableTable;
const #14 = Asciz this;
const #15 = Asciz Lorg/fenixsoft/clazz/TestClass;;
const #16 = Asciz inc;
const #17 = Asciz ()I;
const #18 = Field #1.#19; // org/fenixsoft/clazz/TestClass.m:I
const #19 = NameAndType #5:#6; // m:I
const #20 = Asciz SourceFile;
const #21 = Asciz TestClass.java;
复制代码
  • 符号引用(Symbolic References):符号引用以一组符号来描述所引用的目标,符号可以是任何形式的字面量,只要使用时能无歧义地定位到目标即可。符号引用与虚拟机实现的内存布局无关,引用的目标并不一定是已经加载到虚拟机内存当中的内容。各种虚拟机实现的内存布局可以各不相同, 但是它们能接受的符号引用必须都是一致的,因为符号引用的字面量形式明确定义在《Java虚拟机规 范》的Class文件格式中: 如Class文件中的 CONSTANT_Class_info、 CONSTANT_Fieldref_info、CONSTANT_Methodref_info 等类型的常量。
  • 直接引用(Direct References):直接引用是可以直接指向目标的指针、相对偏移量或者是一个能 间接定位到目标的句柄。直接引用是和虚拟机实现的内存布局直接相关的,同一个符号引用在不同虚拟机实例上翻译出来的直接引用一般不会相同。如果有了直接引用,那引用的目标必定已经在虚拟机的内存中存在。

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

5、初始化

直到初始化阶段,Java虚拟机才真正开始执行类中编写的Java程序代码,将主导权移交给应用程序。

进行准备阶段时,类变量已经赋过一次系统要求的初始零值,而在初始化阶段,则会根据程序员通过程序编码制定的主观计划去初始化类变量和其他资源。我们也可以从另外一种更直接的形式来表达:初始化阶段就是执行类构造器 <clinit>() 方法的过程。 <clinit>() 并不是程序员在Java代码中直接编写的方法,它是Javac编译器的自动生成物。

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

public class Test {
 static {
   i = 0; // 给变量复制可以正常编译通过
   System.out.print(i); // 这句编译器会提示“非法向前引用”
 }
 static int i = 1;
}

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

由于父类的()方法先执行,也就意味着父类中定义的静态语句块要优先于子类的变量赋值操作,如代码清单7-6中,字段B的值将会是2而不是1。

复制代码
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); }
复制代码

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

 

类加载器

Java虚拟机设计团队有意把类加载阶段中的“通过一个类的全限定名来获取描述该类的二进制字节流这个动作放到Java虚拟机外部去实现,以便让应用程序自己决定如何去获取所需的类。实现这个动作的代码被称为“类加载器”(Class Loader)。

类加载器可以说是Java语言的一项创新,它是早期Java语言能够快速流行的重要原因之一。类加载器最初是为了满足Java Applet的需求而设计出来的,在今天用在浏览器上的Java Applet技术基本上已经被淘汰,但类加载器却在类层次划分、OSGi、程序热部署、代码加密等领域大放异彩,成为Java 技术体系中一块重要的基石,可谓是失之桑榆,收之东隅。

 1、类与类加载器

对于任意一个类,都必须由 加载它的类加载器 和 这个类本身一起共同确立其在Java虚拟机中的唯一性,每 一个类加载器,都拥有一个独立的类名称空间。这句话可以表达得更通俗一些:比较两个类是否“相 等”,只有在这两个类是由同一个类加载器加载的前提下才有意义,否则,即使这两个类来源于同一个 Class文件,被同一个Java虚拟机加载,只要加载它们的类加载器不同,那这两个类就必定不相等。

这里所指的“相等”,包括代表类的Class对象的equals()方法、isAssignableFrom()方法、isInstance() 方法的返回结果,也包括了使用 instanceof 关键字做对象所属关系判定等各种情况。

复制代码
/**
 * 类加载器与instanceof关键字演示
 *
 * @author zzm
 */
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("org.fenixsoft.classloading.ClassLoaderTest").newInstance();   System.out.println(obj.getClass());   System.out.println(obj instanceof org.fenixsoft.classloading.ClassLoaderTest); } }
复制代码

  运行结果

class org.fenixsoft.classloading.ClassLoaderTest
false

Java虚拟机中同时存在了两个ClassLoaderTest类,一个是由虚拟机的应用程序类加载器所加载的,另外一个是由我们自定义的类加载器加载的,虽然它们都来自同一 个Class文件,但在Java虚拟机中仍然是两个互相独立的类,做对象所属类型检查时的结果自然为 false。

 

 2、双亲委派模型

站在Java虚拟机的角度来看,只存在两种不同的类加载器:

    • 启动类加载器(Bootstrap ClassLoader),这个类加载器使用C++语言实现,是虚拟机自身的一部分
    • 其他所有的类加载器,这些类加载器都由Java语言实现独立存在于虚拟机外部,并且全都继承自抽象类 java.lang.ClassLoader。

自JDK 1.2以来,Java一直保 持着三层类加载器、双亲委派的类加载架构。

 (1)启动类加载器

负责加载存放在 <java_home>\lib目录,或者被-Xbootclasspath参数所指定的路径中存放的,而且是Java虚拟机能够识别的(按照文件名识别,如rt.jar、tools.jar,名字不符合的类库即使放在lib目录中也不会被加载)类库加载到虚拟机的内存中。

启动类加载器无法被Java程序直接引用,用户在编写自定义类加载器时, 如果需要把加载请求委派给引导类加载器去处理。

 (2)扩展类加载器

在类sun.misc.Launcher$ExtClassLoader 中以Java代码的形式实现的。它负责加载<java_home>\lib\ext目录中,或者被java.ext.dirs系统变量所指定的路径中所有的类库。

这是一种Java系统类库的扩 展机制,JDK的开发团队允许用户将具有通用性的类库放置在ext目录里以扩展Java SE的功能

(3)应用程序类加载器

由 sun.misc.Launcher$AppClassLoader来实现。由于应用程序类加载器 是ClassLoader类中的getSystemClassLoader()方法的返回值,所以有些场合中也称它为“系统类加载器”。它负责加载用户类路径 (ClassPath)上所有的类库,开发者同样可以直接在代码中使用这个类加载器

图中展示的各种类加载器之间的层次关系被称为类加载器的“双亲委派模型(Parents Delegation Model)”。双亲委派模型要求除了顶层的启动类加载器外其余的类加载器都应有自己的父类加载器。不过这里类加载器之间的父子关系一般不是以继承(Inheritance)的关系来实现的,而是通常使用组合(Composition)关系来复用父加载器的代码。

双亲委派模型的工作过程是:

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

好处

很好地解决了各个类加载器协作时基础类型的一致性问题(越基础的类由越上层的加载器进行加载

Java中的类随着它的类加载器一起具备了一种带有优先级的层次关系。

例如类java.lang.Object,它存放在rt.jar之中,无论哪一个类加载器要加载这个类,最终都是委派给处于模型最顶端的启动类加载器进行加载,因此Object类在程序的各种类加载器环境中都能够保证是同一个类

反之

如果没有使用双亲委派模型,都由各个类加载器自行去加载的话,如果用户自己也编写了一个名为java.lang.Object的类,并放在程序的 ClassPath中,那系统中就会出现多个不同的Object类,Java类型体系中最基础的行为也就无从保证,应 用程序将会变得一片混乱。

双亲委派模型对于保证Java程序的稳定运作极为重要,但它的实现却异常简单,用以实现双亲委 派的代码只有短短十余行,全部集中在java.lang.ClassLoader的loadClass()方法之中,如代码清单所示。

复制代码
protected synchronized Class<?> loadClass(String name, boolean resolve) throws ClassNotFoundException
{
   // 首先,检查请求的类是否已经被加载过了
   Class c = findLoadedClass(name);
   if (c == null) {
     try {
       if (parent != null) {
         c = parent.loadClass(name, false);
       } else {
         c = findBootstrapClassOrNull(name);
       }
     } catch (ClassNotFoundException e) {
       // 如果父类加载器抛出ClassNotFoundException
       // 说明父类加载器无法完成加载请求
     }
     if (c == null) {
       // 在父类加载器无法加载时
       // 再调用本身的findClass方法来进行类加载
       c = findClass(name);
     }
   }
  
if (resolve) {      resolveClass(c);   }
  
return c; }
复制代码

这段代码的逻辑清晰易懂:先检查请求加载的类型是否已经被加载过,若没有则调用父加载器的 loadClass()方法,若父加载器为空则默认使用启动类加载器作为父加载器。假如父类加载器加载失败, 抛出ClassNotFoundException异常的话,才调用自己的findClass()方法尝试进行加载。

 

 3、破坏双亲委派模型

上文提到过双亲委派模型并不是一个具有强制性约束的模型,而是Java设计者推荐给开发者们的类加载器实现方式。在Java的世界中大部分的类加载器都遵循这个模型,但也有例外的情况,直到Java 模块化出现为止,双亲委派模型主要出现过3次较大规模“被破坏”的情况。

 (1)在双亲委派模型出现之前-----即JDK1.2发布之前。

(2)由启动类加载器的加载的 基础 JNDI 服务 需要调用应用程序 ClassPath 下的JNDI服务提供者接口

双亲委派——越基础的类由越上层的加载器进行加载,基础类型之所以被 称为“基础”,是因为它们总是作为被用户代码继承、调用的API存在。

但如果有基础类型又要调用回用户的代码怎么办?

一个典型的例子便是JNDI服务,JNDI现在已经是Java的标准服务,属于Java中很基础的类型,在 rt.jar 中它的代码由启动类加载器来完成加载。

JNDI存在的目的就是对资源进行查找和集中管理,它需要调用由其他厂商实现并部署在应用程序的ClassPath下的JNDI服务提供者接口(Service Provider Interface,SPI)的代码,而启动类加载器是绝不可能认识、加载这些代码的,那该怎么办?。

为了解决这个困境,Java的设计团队只好引入了一个不太优雅的设计:线程上下文类加载器 (Thread Context ClassLoader)。这个类加载器可以通过java.lang.Thread类的setContext-ClassLoader()方法进行设置,如果创建线程时还未设置,它将会从父线程中继承一个,如果在应用程序的全局范围内都没有设置过的话,那这个类加载器默认就是应用程序类加载器。

JNDI服务 使用这个线程上下文类加载器去加载所需的SPI服务代码,这是一种父类加载器(JDNI类)去请求子类加载器(线程上下文)完成类加载的行为,这种行为实际上是打通了双亲委派模型的层次结构来逆向使用类加载器,已经违背了双亲委派模型的一般性原则但也是无可奈何的事情。Java中涉及SPI的加载基本上都采用这种方式来完成,例如JNDI、 JDBC、JCE、JAXB和JBI等。

 

(3)用户对程序动态性的追求

代码热替换(Hot Swap)、模块热部署(Hot Deployment)等。

OSGi实现模块化热部署的关键是它自定义的类加载器机制的实现,每一个程序模块(OSGi中称为 Bundle)都有一个自己的类加载器,当需要更换一个Bundle时,就把Bundle连同类加载器一起换掉以实 现代码的热替换。在OSGi环境下,类加载器不再双亲委派模型推荐的树状结构,而是进一步发展为更 加复杂的网状结构。