网站视频下载,网络营销的理论基础有哪些,wordpress mysql 设置,个人信用信息服务平台1、类的加载过程#xff08;生命周期#xff09; 1.1、过程一#xff1a;装载#xff08;Loading#xff09;阶段
1、过程一都做了什么事#xff1f; 类的装载#xff0c;简而言之就是将Java类的字节码文件加载到机器内存中#xff0c;并在内存中构建出Java类的原型生命周期 1.1、过程一装载Loading阶段
1、过程一都做了什么事 类的装载简而言之就是将Java类的字节码文件加载到机器内存中并在内存中构建出Java类的原型类模板对象。在加载类时Java虚拟机必须完成以下3件事情
通过类的全名获取类的二进制数据流。解析类的二进制数据流为方法区内的数据结构Java类模型创建 java.lang.Class 类的实例表示该类型。作为方法区这个类的各种数据的访问入口 装载阶段简言之查找并加载类的二进制数据生成Class的实例。 2、什么是类模板对象 所谓类模板对象其实就是Java类在JVM内存中的一个快照JVM将从字节码文件中解析出的常量池、类字段、类方法等信息存储到类模板中这样JVM在运行期便能通过类模板而获取Java类中的任意信息能够对Java类的成员变量进行遍历也能进行Java方法的调用。 反射的机制即基于这一基础。如果JVM没有将Java类的声明信息存储起来则JVM在运行期也无法反射。 加载的类在JVM中创建相应的类结构类结构会存储在方法区(JDK1.8之前永久代JDK1.8及之后元空间)。而这个也叫做类模型的位置。
3、二进制流有哪些获取方式 对于类的二进制数据流虚拟机可以通过多种途径产生或获得。只要所读取的字节码符合JVM规范即可主要有以下几种
虚拟机可能通过文件系统读入一个class后缀的文件最常见读入jar、zip等归档数据包提取类文件。事先存放在数据库中的类的二进制数据用类似于HTTP之类的协议通过网络进行加载在运行时生成一段Class的二进制信息等 在获取到类的二进制信息后Java虚拟机就会处理这些数据并最终转为一个java.lang.Class的实例。如果输入数据不是ClassFile的结构则会抛出ClassFormatError。
4、Class 实例的位置在哪 类将.class文件加载至元空间后会在堆中创建一个Java.lang.Class对象用来封装类位于方法区内的数据结构该Class对象是在加载类的过程中创建的每个类都对应有一个Class类型的对象。(instanceClass -- mirror :Class的实例) 外部可以通过访问代表Order类的Class对象来获取Order的类数据结构。其次因为Class类的构造方法是私有的只有JVM能够创建。 java.lang.Class实例是访问类型元数据的接口也是实现反射的关键数据、入口。通过Class类提供的接口可以获得目标类所关联的.class文件中具体的数据结构方法、字段等信息。
5、数组类的加载有什么不同 创建数组类的情况稍微有些特殊因为数组类本身并不是由类加载器负责创建而是由JVM在运行时根据需要而直接创建的但数组的元素类型仍然需要依靠类加载器去创建。创建数组类下述简称A的过程
如果数组的元素类型是引用类型那么就遵循定义的加载过程递归加载和创建数组A的元素类型JVM使用指定的元素类型和数组维度来创建新的数组类。如果数组的元素类型是引用类型数组类的可访问性就由元素类型的可访问性决定。否则数组类的可访问性将被缺省定义为public。
1.2、过程二链接Linking阶段
1、环节一验证Verification 当类加载到系统后就开始链接操作验证是链接操作的第一步。它的目的是保证加载的字节码是合法、合理并符合规范的。而验证的步骤比较复杂实际要验证的项目也很繁多大体上Java虚拟机需要做以下检査如图所示 验证的内容则涵盖了类数据信息的格式验证、语义检查、字节码验证以及符号引用验证等。其中格式验证会和装载阶段一起执行。验证通过之后类加载器才会成功将类的二进制数据信息加载到方法区中。格式验证之外的验证操作将会在方法区中进行。 格式验证 是否以魔数 OxCAFEBABE开头主版本和副版本号是否在当前Java虚拟机的支持范围内数据中每一个项是否都拥有正确的长度等。 语义检查 Java虚拟机会进行字节码的语义检查但凡在语义上不符合规范的虚拟机也不会给予验证通过。比如
是否所有的类都有父类的存在(在Java里除了Object外其他类都应该有父类)是否一些被定义为final的方法或者类被重写或继承了非抽象类是否实现了所有抽象方法或者接口方法是否存在不兼容的方法(比如方法的签名除了返回值不同其他都一样这种方法会让虚拟机无从下手调度abstract情况下的方法就不能是final的了) 字节码验证 Java虚拟机还会进行字节码验证字节码验证也是验证过程中最为复杂的一个过程。它试图通过对字节码流的分析判断字节码是否可以被正确地执行。比如
在字节码的执行过程中是否会跳转到一条不存在的指令函数的调用是否传递了正确类型的参数变量的赋值是不是给了正确的数据类型等 栈映射帧(StackMapTable)就是在这个阶段用于检测在特定的字节码处其局部变量表和操作数栈是否有着正确的数据类型。但遗憾的是100%准确地判断一段字节码是否可以被安全执行是无法实现的因此该过程只是尽可能地检査出可以预知的明显的问题。如果在这个阶段无法通过检查虚拟机也不会正确装载这个类。但是如果通过了这个阶段的检查也不能说明这个类是完全没有问题的。 在前面3次检查中已经排除了文件格式错误、语义错误以及字节码的不正确性。但是依然不能确保类是没有问题的。为此还需要在进行下一步的验证 符号引用的验证 校验器还将进行符号引用的验证。Class文件在其常量池会通过字符串记录自己将要使用的其他类或者方法。因此在验证阶段虚拟机就会检查这些类或者方法确实是存在的并且当前类有权限访问这些数据如果一个需要使用类无法在系统中找到则会抛出NoClassDefFoundError,如果一个方法无法被找到则会抛出NoSuchMethodError。此阶段在解析环节才会执行
2、环节二准备Preparation 在这个阶段虚拟机就会为这个类分配相应的内存空间并设置默认初始值。Java虚拟机为各类型变量默认的初始值如表所示。
类型默认初始值byte(byte)0short(short)0int0long0Lfloat0.0fdouble0.0char\u0000booleanfalsereferencenull
注意Java并不支持boolean类型对于boolean类型内部实现是int,由于int的默认值是0,故对应的boolean的默认值就是false。 特别说明 这里不包含基本数据类型的字段用static final修饰的情况因为final在编译的时候就会分配了准备阶段会显式赋值。此外这里不会为实例变量分配初始化实例变量是会随着对象一起分配到Java堆中。在这个阶段并不会像初始化阶段中那样会有初始化或者代码被执行。 3、环节三解析Resolution
3.1、什么是符号引用 符号引用就是一些字面量的引用和虚拟机的内部数据结构和和内存布局无关。比较容易理解的就是在Class类文件中通过常量池进行了大量的符号引用。但是在程序实际运行时只有符号引用是不够的比如当如下println()方法被调用时系统需要明确知道该方法的位置。 举例输出操作System.out.println()对应的字节码 invokevirtual #24 java/io/PrintStream.println 以方法为例Java虚拟机为每个类都准备了一张方法表将其所有的方法都列在表中当需要调用一个类的方法的时候只要知道这个方法在方法表中的偏移量就可以直接调用该方法。通过解析操作符号引用就可以转变为目标方法在类中方法表中的位置从而使得方法被成功调用。 所谓解析就是将符号引用转为直接引用也就是得到类、字段、方法在内存中的指针或者偏移量。因此可以说如果直接引用存在那么可以肯定系统中存在该类、方法或者字段。但只存在符号引用不能确定系统中一定存在该结构。 不过Java虚拟机规范并没有明确要求解析阶段一定要按照顺序执行。在HotSpot VM中加载、验证、准备和初始化会按照顺序有条不紊地执行但链接阶段中的解析操作往往会伴随着JVM在执行完初始化之后再执行。
3.2、什么是字符串 最后再来看一下CONSTANT_String的解析。由于字符串在程序开发中有着重要的作用因此读者有必要了解一下String在Java虚拟机中的处理。当在Java代码中直接使用字符串常量时就会在类中出现CONSTANT_String,它表示字符串常量并且会引用一个CONSTANT_UTF8的常量项。在Java虚拟机内部运行中的常量池中会维护一张字符串拘留表(intern)它会保存所有出现过的字符串常量并且没有重复项。只要以CONSTANT_String形式出现的字符串也都会在这张表中。使用String.intern()方法可以得到一个字符串在拘留表中的引用因为该表中没有重复项所以任何字面相同的字符串的String.intern()方法返回总是相等的。
4、小结
简单说来就是三句话
验证目的是保证加载的字节码是合法、合理并符合规范的准备目的是为类的静态变量分配内存并将其初始化为默认值解析将类、接口、字段和方法的符号引用转为直接引用
1.3、过程三初始化Initialization阶段 类的初始化是类装载的最后一个阶段。如果前面的步骤都没有问题那么表示类可以顺利装载到系统中。此时类才会开始执行Java字节码。即到了初始化阶段才真正开始执行类中定义的 Java 程序代码初始化阶段的重要工作是执行类的初始化方法:clinit()方法。
该方法仅能由Java编译器生成并由JVM调用程序开发者无法自定义一个同名的方法更无法直接在Java程序中调用该方法虽然该方法也是由字节码指令所组成。它是由类静态成员的赋值语句以及static语句块合并产生的。 clinit()只有在给类的中的static的变量显式赋值或在静态代码块中赋值了。才会生成此方法。 init() 一定会出现在Class的method表中。 1、为什么子类加载前先加载父类 在加载一个类之前虚拟机总是会试图加载该类的父类因此父类的clinit总是在子类clinit之前被调用。也就是说父类的static块优先级高于子类。
口诀由父及子静态先行。
2、哪些类不会生成 clinit 方法 Java编译器并不会为所有的类都产生clinit()初始化方法。哪些类在编译为字节码后字节码文件中将不会包含clinit()方法
一个类中并没有声明任何的类变量也没有静态代码块时一个类中声明类变量但是没有明确使用类变量的初始化语句以及静态代码块来执行初始化操作时一个类中包含static final修饰的基本数据类型的字段这些类字段初始化语句采用编译时常量表达式
/*** author lyb* 哪些场景下java编译器就不会生成clinit()方法*/
public class InitializationTest1 {//场景1对于非静态的字段不管是否进行了显式赋值都不会生成clinit()方法public int num 1;//场景2静态的字段没有显式的赋值不会生成clinit()方法public static int num1;//场景3比如对于声明为static final的基本数据类型的字段不管是否进行了显式赋值都不会生成clinit()方法public static final int num2 1;
}
3、static 与 final 的搭配使用
/*** author lyb** 测试静态字段的显式赋值哪些是解析阶段哪些是初始化阶段赋值的。*/
public class InitilizationTest1 {public static int a 1;public static final int INT_CONSTANT 10;public static final Integer INTEGER_CONSTANT1 Integer.valueOf(100);public static Integer INTEGER_CONSTANT2 Integer.valueOf(1000);public static final String s new String(helloworld);
}
反编译取得字节码如下 0 iconst_11 putstatic #2 com/blnp/cn/InitilizationTest1.a4 bipush 1006 invokestatic #3 java/lang/Integer.valueOf9 putstatic #4 com/blnp/cn/InitilizationTest1.INTEGER_CONSTANT1
12 sipush 1000
15 invokestatic #3 java/lang/Integer.valueOf
18 putstatic #5 com/blnp/cn/InitilizationTest1.INTEGER_CONSTANT2
21 new #6 java/lang/String
24 dup
25 ldc #7 helloworld
27 invokespecial #8 java/lang/String.init
30 putstatic #9 com/blnp/cn/InitilizationTest1.s
33 return
结论普通基本数据类型和引用类型即使是常量的静态变量是需要额外调用putstatic等JVM指令的这些是在显式初始化阶段执行而不是准备阶段调用而基本数据类型常量(非调用方法的显式赋值)、String类型字面量的定义方式的常量则不需要这样的步骤是在准备阶段完成的。
4、 clinit() 调用会死锁吗 对于clinit()方法的调用也就是类的初始化虚拟机会在内部确保其多线程环境中的安全性。虚拟机会保证一个类的clinit()方法在多线程环境中被正确地加锁、同步如果多个线程同时去初始化一个类那么只会有一个线程去执行这个类的clinit()方法其他线程都需要阻塞等待直到活动线程执行clinit()方法完毕。 正是因为函数clinit()带锁线程安全的因此如果在一个类的clinit()方法中有耗时很长的操作就可能造成多个线程阻塞引发死锁。并且这种死锁是很难发现的因为看起来它们并没有可用的锁信息。 如果之前的线程成功加载了类则等在队列中的线程就没有机会再执行clinit()方法了。那么当需要使用这个类时虚拟机会直接返回给它已经准备好的信息。
5、关于 init() 与 clinit() 方法
class X {static Log log LogFactory.getLog(); // clinitprivate int x 1; // initX(){// init} { // init }static {// clinit}}
6、什么是静态代码块、构造代码块、普通代码块以及构造函数
6.1、静态代码块
①、格式 在java类中方法中不能存在静态代码块使用static关键字和{}声明的代码块
public class CodeBlock {static{System.out.println(静态代码块);}
}
②、执行时机 静态代码块在类被加载的时候就运行了而且只运行一次并且优先于各种代码块以及构造函数。如果一个类中有多个静态代码块会按照书写顺序依次执行。后面在比较的时候会通过具体实例来证明。
③、静态代码块的作用 一般情况下如果有些代码需要在项目启动的时候就执行这时候就需要静态代码块。比如一个项目启动需要加载的很多配置文件等资源我们就可以都放入静态代码块中。
④、静态代码块不能存在任何方法体中 这个应该很好理解首先我们要明确静态代码块是在类加载的时候就要运行了。我们分情况讨论
对于普通方法由于普通方法是通过加载类然后new出实例化对象通过对象才能运行这个方法而静态代码块只需要加载类之后就能运行了。对于静态方法在类加载的时候静态方法也已经加载了但是我们必须要通过类名或者对象名才能访问也就是说相比于静态代码块静态代码块是主动运行的而静态方法是被动运行的。 不管是哪种方法我们需要明确静态代码块的存在在类加载的时候就自动运行了而放在不管是普通方法还是静态方法中都是不能自动运行的。
⑤、静态代码块不能访问普通变量 这个理解思维同上普通变量只能通过对象来调用是不能放在静态代码块中的。
6.2、构造代码块
①、格式 在java类中使用{}声明的代码块和静态代码块的区别是少了static关键字:
public class CodeBlock {static{System.out.println(静态代码块);}{System.out.println(构造代码块);}
}
②、执行时机 构造代码块在创建对象时被调用每次创建对象都会调用一次但是优先于构造函数执行。需要注意的是听名字我们就知道构造代码块不是优先于构造函数执行而是依托于构造函数也就是说如果你不实例化对象构造代码块是不会执行的。怎么理解呢我们看看下面这段代码
public class CodeBlock {{System.out.println(构造代码块);}public CodeBlock(){System.out.println(无参构造函数);}public CodeBlock(String str){System.out.println(有参构造函数);}
}
③、构造代码块的作用 和构造函数的作用类似都能对对象进行初始化并且只要创建一个对象构造代码块都会执行一次。但是反过来构造函数则不一定每个对象建立时都执行多个构造函数情况下建立对象时传入的参数不同则初始化使用对应的构造函数。 利用每次创建对象的时候都会提前调用一次构造代码块特性我们可以做诸如统计创建对象的次数等功能。
6.3、构造函数
构造函数的命名必须和类名完全相同。在java中普通函数可以和构造函数同名但是必须带有返回值构造函数的功能主要用于在类的对象创建时定义初始化的状态。它没有返回值也不能用void来修饰。这就保证了它不仅什么也不用自动返回而且根本不能有任何选择。而其他方法都有返回值即使是void返回值。尽管方法体本身不会自动返回什么但仍然可以让它返回一些东西而这些东西可能是不安全的构造函数不能被直接调用必须通过new运算符在创建对象时才会自动调用而一般的方法是在程序执行到它的时候被调用的当定义一个类的时候通常情况下都会显示该类的构造函数并在函数中指定初始化的工作也可省略不过Java编译器会提供一个默认的构造函数.此默认构造函数是不带参数的。而一般的方法不存在这一特点
6.4、普通代码块 普通代码块和构造代码块的区别是构造代码块是在类中定义的而普通代码块是在方法体中定义的。且普通代码块的执行顺序和书写顺序一致。
public void sayHello(){{System.out.println(普通代码块);}
}
6.5、执行顺序
静态代码块构造代码块构造函数普通代码块
public class CodeBlock {static{System.out.println(静态代码块);}{System.out.println(构造代码块);}public CodeBlock(){System.out.println(无参构造函数);}public void sayHello(){{System.out.println(普通代码块);}}public static void main(String[] args) {System.out.println(执行了main方法);new CodeBlock().sayHello();;System.out.println(---------------);new CodeBlock().sayHello();;}
}
执行结果
静态代码块
执行了main方法
构造代码块
无参构造函数
普通代码块
---------------
构造代码块
无参构造函数
普通代码块
7、类的使用情况
7.1、主动使用 Class只有在必须要首次使用的时候才会被装载Java虚拟机不会无条件地装载Class类型。Java虚拟机规定一个类或接口在初次使用前必须要进行初始化。这里指的“使用”是指主动使用。 主动使用只有下列几种情况即如果出现如下的情况则会对类进行初始化操作。而初始化操作之前的加载、验证、准备已经完成。
当创建一个类的实例时比如使用new关键字或者通过反射、克隆、反序列化。当调用类的静态方法时即当使用了字节码invokestatic指令。当使用类、接口的静态字段时(final修饰特殊考虑)比如使用getstatic或者putstatic指令。当使用java.lang.reflect包中的方法反射类的方法时。比如Class.forName(com.blnp.net.Test)当初始化子类时如果发现其父类还没有进行过初始化则需要先触发其父类的初始化。如果一个接口定义了default方法那么直接实现或者间接实现该接口的类的初始化该接口要在其之前被初始化。当虚拟机启动时用户需要指定一个要执行的主类包含main()方法的那个类虚拟机会先初始化这个主类。当初次调用 MethodHandle 实例时初始化该 MethodHandle 指向的方法所在的类。涉及解析REF_getStatic、REF_putStatic、REF_invokeStatic方法句柄对应的类 对于第五点进行补充说明 当Java虚拟机初始化一个类时要求它的所有父类都已经被初始化但是这条规则并不适用于接口。
在初始化一个类时并不会先初始化它所实现的接口在初始化一个接口时并不会先初始化它的父接口 因此一个父接口并不会因为它的子接口或者实现类的初始化而初始化。只有当程序首次使用特定接口的静态字段时才会导致该接口的初始化。 对第七点进行补充说明 JVM启动的时候通过引导类加载器加载一个初始类。这个类在调用public static void main(String[])方法之前被链接和初始化。这个方法的执行将依次导致所需的类的加载链接和初始化。
7.2、被动使用 除了以上的情况属于主动使用其他的情况均属于被动使用。被动使用不会引起类的初始化。也就是说并不是在代码中出现的类就一定会被加载或者初始化。如果不符合主动使用的条件类就不会初始化。
当访问一个静态字段时只有真正声明这个字段的类才会被初始化。 当通过子类引用父类的静态变量不会导致子类初始化通过数组定义类引用不会触发此类的初始化引用常量不会触发此类或接口的初始化。因为常量在链接阶段就已经被显式赋值了。调用ClassLoader类的loadClass()方法加载一个类并不是对类的主动使用不会导致类的初始化。 被动的使用意味着不需要执行初始化环节意味着没有clinit()的调用。 1.4、过程四类的使用Using 任何一个类型在使用之前都必须经历过完整的加载、链接和初始化3个类加载步骤。一旦一个类型成功经历过这3个步骤之后便“万事俱备只欠东风”就等着开发者使用了。 开发人员可以在程序中访问和调用它的静态类成员信息比如静态字段、静态方法或者使用new关键字为其创建对象实例。
1.5、过程五类的卸载Unloading
1、类、类的加载器、类的实例之间的引用关系 在类加载器的内部实现中用一个Java集合来存放所加载类的引用。另一方面一个Class对象总是会引用它的类加载器调用Class对象的getClassLoader()方法就能获得它的类加载器。由此可见代表某个类的Class实例与其类的加载器之间为双向关联关系。 一个类的实例总是引用代表这个类的Class对象。在Object类中定义了getClass()方法这个方法返回代表对象所属类的Class对象的引用。此外所有的Java类都有一个静态属性class它引用代表这个类的Class对象。
2、什么情况下类会被卸载 一个类何时结束生命周期取决于代表它的Class对象何时结束生命周期。 当Sample类被加载、链接和初始化后它的生命周期就开始了。当代表Sample类的Class对象不再被引用即不可触及时Class对象就会结束生命周期Sample类在方法区内的数据也会被卸载从而结束Sample类的生命周期。 loader1变量和obj变量间接引用代表Sample类的Class对象而objClass变量则直接引用它。如果程序运行过程中将上图左侧三个引用变量都置为null此时Sample对象结束生命周期MyClassLoader对象结束生命周期代表Sample类的Class对象也结束生命周期Sample类在方法区内的二进制数据被卸载。 当再次有需要时会检查Sample类的Class对象是否存在如果存在会直接使用不再重新加载如果不存在Sample类会被重新加载在Java虚拟机的堆区会生成一个新的代表Sample类的Class实例(可以通过哈希码查看是否是同一个实例)。
3、类卸载在实际生产的使用
启动类加载器加载的类型在整个运行期间是不可能被卸载的(jvm和jls规范)被系统类加载器和扩展类加载器加载的类型在运行期间不太可能被卸载因为系统类加载器实例或者扩展类的实例基本上在整个运行期间总能直接或者间接的访问的到其达到unreachable的可能性极小。被开发者自定义的类加载器实例加载的类型只有在很简单的上下文环境中才能被卸载而且一般还要借助于强制调用虚拟机的垃圾收集功能才可以做到。可以预想稍微复杂点的应用场景中(比如很多时候用户在开发自定义类加载器实例的时候采用缓存的策略以提高系统性能)被加载的类型在运行期间也是几乎不太可能被卸载的(至少卸载的时间是不确定的)。 综合以上三点一个已经加载的类型被卸载的几率很小至少被卸载的时间是不确定的。同时我们可以看的出来开发者在开发代码时候不应该对虚拟机的类型卸载做任何假设的前提下来实现系统中的特定功能。
4、方法区的垃圾回收 方法区的垃圾收集主要回收两部分内容常量池中废弃的常量和不再使用的类型。HotSpot虚拟机对常量池的回收策略是很明确的只要常量池中的常量没有被任何地方引用就可以被回收。 判定一个常量是否“废弃”还是相对简单而要判定一个类型是否属于“不再被使用的类”的条件就比较苛刻了。需要同时满足下面三个条件
该类所有的实例都已经被回收。也就是Java堆中不存在该类及其任何派生子类的实例。加载该类的类加载器已经被回收。这个条件除非是经过精心设计的可替换类加载器的场景如OSGi、JSP的重加载等否则通常是很难达成的。 该类对应的java.lang.Class对象没有在任何地方被引用无法在任何地方通过反射访问该类的方法。 Java虚拟机被允许对满足上述三个条件的无用类进行回收这里说的仅仅是“被允许”而并不是和对象一样没有引用了就必然会回收。
2、类的加载器
2.1、作用 ClassLoader的作用 ClassLoader是Java的核心组件所有的Class都是由ClassLoader进行加载的ClassLoader负责通过各种方式将Class信息的二进制数据流读入JVM内部转换为一个与目标类对应的java.lang.Class对象实例。然后交给Java虚拟机进行链接、初始化等操作。 因此ClassLoader在整个装载阶段只能影响到类的加载而无法通过ClassLoader去改变类的链接和初始化行为。至于它是否可以运行则由Execution Engine执行引擎决定。 类加载器最早出现在Java1.0版本中那个时候只是单纯地为了满足Java Applet应用而被研发出来。但如今类加载器却在OSGi、字节码加解密领域大放异彩。这主要归功于Java虚拟机的设计者们当初在设计类加载器的时候并没有考虑将它绑定在JVM内部这样做的好处就是能够更加灵活和动态地执行类加载操作。
2.2、类加载的显式加载与隐式加载 class文件的显式加载与隐式加载的方式是指JVM加载class文件到内存的方式。
显式加载指的是在代码中通过调用ClassLoader加载class对象如直接使用Class.forName(name)或this.getClass().getClassLoader().loadClass()加载class对象。隐式加载则是不直接在代码中调用ClassLoader的方法加载class对象而是通过虚拟机自动加载到内存中如在加载某个类的class文件时该类的class文件中引用了另外一个类的对象此时额外引用的类将通过JVM自动加载到内存中。
2.3、类加载机制的必要性 一般情况下Java开发人员并不需要在程序中显式地使用类加载器但是了解类加载器的加载机制却显得至关重要。从以下几个方面说
避免在开发中遇到 java.lang.ClassNotFoundException异常或java.lang.NoClassDefFoundError异常时手足无措。只有了解类加载器的加载机制才能够在出现异常的时候快速地根据错误异常日志定位问题和解决问题需要支持类的动态加载或需要对编译后的字节码文件进行加解密操作时就需要与类加载器打交道了。开发人员可以在程序中编写自定义类加载器来重新定义类的加载规则以便实现一些自定义的处理逻辑。
2.4、加载的类是唯一的吗
1、什么是类的唯一性 对于任意一个类都需要由加载它的类加载器和这个类本身一同确认其在Java虚拟机中的唯一性。每一个类加载器都拥有一个独立的类名称空间比较两个类是否相等只有在这两个类是由同一个类加载器加载的前提下才有意义。否则即使这两个类源自同一个Class文件被同一个虚拟机加载只要加载他们的类加载器不同那这两个类就必定不相等。
2、命名空间
每个类加载器都有自己的命名空间命名空间由该加载器及所有的父加载器所加载的类组成在同一命名空间中不会出现类的完整名字包括类的包名相同的两个类在不同的命名空间中有可能会出现类的完整名字包括类的包名相同的两个类 在大型应用中我们往往借助这一特性来运行同一个类的不同版本。
2.5、类加载机制的基本特征 通常类加载机制有三个基本特征
双亲委派模型。但不是所有类加载都遵守这个模型有的时候启动类加载器所加载的类型是可能要加载用户代码的比如JDK内部的ServiceProvider/ServiceLoader机制用户可以在标准API框架上提供自己的实现JDK也需要提供些默认的参考实现。例如Java 中JNDI、JDBC、文件系统、Cipher等很多方面都是利用的这种机制这种情况就不会用双亲委派模型去加载而是利用所谓的上下文加载器。可见性。子类加载器可以访问父加载器加载的类型但是反过来是不允许的。不然因为缺少必要的隔离我们就没有办法利用类加载器去实现容器的逻辑。单一性。由于父加载器的类型对于子加载器是可见的所以父加载器中加载过的类型就不会在子加载器中重复加载。但是注意类加载器“邻居”间同一类型仍然可以被加载多次因为互相并不可见。 2.6、类加载器的分类 JVM支持两种类型的类加载器分别为引导类加载器Bootstrap ClassLoader和自定义类加载器User-Defined ClassLoader。 从概念上来讲自定义类加载器一般指的是程序中由开发人员自定义的一类类加载器但是Java虚拟机规范却没有这么定义而是将所有派生于抽象类ClassLoader的类加载器都划分为自定义类加载器。无论类加载器的类型如何划分在程序中我们最常见的类加载器结构主要是如下情况 2.7、子父类加载器的关系 除了顶层的启动类加载器外其余的类加载器都应当有自己的“父类”加载器。 不同类加载器看似是继承Inheritance关系实际上是包含关系。在下层加载器中包含着上层加载器的引用。
class ClassLoader{ClassLoader parent; //父类加载器public ClassLoader(ClassLoader parent){ this.parent parent;}
}class ParentClassLoader extends ClassLoader{public ParentClassLoader(ClassLoader parent){super(parent);}
}class ChildClassLoader extends ClassLoader{public ChildClassLoader(ClassLoader parent){ //parent new ParentClassLoader();super(parent);}
}
2.8、类加载器说明
1、引导类加载器 启动类加载器也就是引导类加载器Bootstrap ClassLoader具备以下几个特点
这个类加载使用C/C语言实现的嵌套在JVM内部。它用来加载Java的核心库JAVA_HOME/jre/lib/rt.jar 或 sun.boot.class.path路径下的内容。用于提供JVM自身需要的类。并不继承自java.lang.ClassLoader没有父加载器。出于安全考虑Bootstrap启动类加载器只加载包名为java、javax、sun等开头的类加载扩展类和应用程序类加载器并指定为他们的父类加载器。 2、扩展类加载器 扩展类加载器Extension ClassLoader
Java语言编写由sun.misc.Launcher$ExtClassLoader实现。继承于ClassLoader类父类加载器为启动类加载器从java.ext.dirs系统属性所指定的目录中加载类库或从JDK的安装目录的jre/lib/ext子目录下加载类库。如果用户创建的JAR放在此目录下也会自动由扩展类加载器加载。 3、系统类加载器 应用程序类加载器系统类加载器AppClassLoader
java语言编写由sun.misc.Launcher$AppClassLoader实现继承于ClassLoader类父类加载器为扩展类加载器它负责加载环境变量classpath或系统属性 java.class.path 指定路径下的类库应用程序中的类加载器默认是系统类加载器。它是用户自定义类加载器的默认父加载器通过ClassLoader的getSystemClassLoader()方法可以获取到该类加载器
2.9、用户自定义类加载器 在Java的日常应用程序开发中类的加载几乎是由上述3种类加载器相互配合执行的。在必要时我们还可以自定义类加载器来定制类的加载方式。Java开发者可以自定义类加载器来实现类库的动态加载加载源可以是本地的JAR包也可以是网络上的远程资源。 通过类加载器可以实现非常绝妙的插件机制这方面的实际应用案例举不胜举。例如著名的OSGI组件框架再如Eclipse的插件机制。类加载器为应用程序提供了一种动态增加新功能的机制这种机制无须重新打包发布应用程序就能实现。 同时自定义加载器能够实现应用隔离例如 TomcatSpring等中间件和组件框架都在内部实现了自定义的加载器并通过自定义加载器隔离不同的组件模块。这种机制比C/C程序要好太多想不修改C/C程序就能为其新增功能几乎是不可能的仅仅一个兼容性便能阻挡住所有美好的设想。所有用户自定义类加载器通常需要继承于抽象类java.lang.ClassLoader。
2.10、类加载器测试 每个Class对象都会包含一个定义它的ClassLoader的一个引用。而获取ClassLoader的途径有
//获得当前类的ClassLoader
clazz.getClassLoader()//获得当前线程上下文的ClassLoader
Thread.currentThread().getContextClassLoader()//获得系统的ClassLoader
ClassLoader.getSystemClassLoader() 站在程序的角度看引导类加载器与另外两种类加载器系统类加载器和扩展类加载器并不是同一个层次意义上的加载器引导类加载器是使用C语言编写而成的而另外两种类加载器则是使用Java语言编写而成的。由于引导类加载器压根儿就不是一个Java类因此在Java程序中只能打印出空值。 数组类的Class对象不是由类加载器去创建的而是在Java运行期JVM根据需要自动创建的。对于数组类的类加载器来说是通过Class.getClassLoader()返回的与数组当中元素类型的类加载器是一样的如果数组当中的元素类型是基本数据类型数组类是没有类加载器的。
String[] strArr new String[6];
System.out.println(strArr.getClass().getClassLoader());
// 运行结果nullClassLoaderTest[] test new ClassLoaderTest[1];
System.out.println(test.getClass().getClassLoader());
// 运行结果sun.misc.Launcher$AppClassLoader18b4aac2int[] ints new int[2];
System.out.println(ints.getClass().getClassLoader());
// 运行结果null
3、ClassLoader 源码解读
3.1、ClassLoader 与类加载器的关系 ClassLoader是一个抽象类。如果我们给定了一个类的二进制名称类加载器应尝试去定位或生成构成定义类的数据。一种典型的策略是将给定的二进制名称转换为文件名然后去文件系统中读取这个文件名所对应的class文件。
3.2、ClassLoader 的主要方法
1、getParent
//返回该类加载器的超类加载器
public final ClassLoader getParent()
2、loadClass
//加载名称为name的类返回结果为java.lang.Class类的实例。如果找不到类
//则返回 ClassNotFoundException 异常。该方法中的逻辑就是双亲委派模式的实现。
public Class? loadClass(String name) throws ClassNotFoundException
3、findClass
//查找二进制名称为name的类返回结果为java.lang.Class类的实例。
protected Class? findClass(String name) throws ClassNotFoundException 这是一个受保护的方法JVM鼓励我们重写此方法需要自定义加载器遵循双亲委托机制该方法会在检查完父类加载器之后被loadClass()方法调用。 在JDK1.2之前在自定义类加载时总会去继承ClassLoader类并重写loadClass方法从而实现自定义的类加载类。但是在JDK1.2之后已不再建议用户去覆盖loadClass()方法而是建议把自定义的类加载逻辑写在findClass()方法中从前面的分析可知findClass()方法是在loadClass()方法中被调用的当loadClass()方法中父加载器加载失败后则会调用自己的findClass()方法来完成类加载这样就可以保证自定义的类加载器也符合双亲委托模式。 需要注意的是ClassLoader类中并没有实现findClass()方法的具体代码逻辑取而代之的是抛出ClassNotFoundException异常同时应该知道的是findClass方法通常是和defineClass方法一起使用的。一般情况下在自定义类加载器时会直接覆盖ClassLoader的findClass()方法并编写加载规则取得要加载类的字节码后转换成流然后调用defineClass()方法生成类的Class对象。
4、defineClass
//根据给定的字节数组b转换为Class的实例off和len参数表示实际Class信息
//在byte数组中的位置和长度其中byte数组b是ClassLoader从外部获取的。
protected final Class? defineClass(String name, byte[] b, int off, int len) 这是受保护的方法只有在自定义ClassLoader子类中可以使用。defineClass()方法是用来将byte字节流解析成JVM能够识别的Class对象(ClassLoader中已实现该方法逻辑)通过这个方法不仅能够通过class文件实例化class对象也可以通过其他方式实例化class对象如通过网络接收一个类的字节码然后转换为byte字节流创建对应的Class对象。简单举例
protected Class? findClass(String name) throws ClassNotFoundException {// 获取类的字节数组byte[] classData getClassData(name);if (classData null) {throw new ClassNotFoundException();} else {//使用defineClass生成class对象return defineClass(name, classData, 0, classData.length);}
}
5、resolveClass
//链接指定的一个Java类。使用该方法可以使用类的Class对象创建完成的同时也被解析。
protected final void resolveClass(Class? c) 前面我们说链接阶段主要是对字节码进行验证为类变量分配内存并设置初始值同时将字节码文件中的符号引用转换为直接引用。
6、findLoadedClass
//查找名称为name的已经被加载过的类返回结果为java.lang.Class类的实例。
//这个方法是final方法无法被修改。
protected final Class? findLoadedClass(String name)
7、ClassLoader 实例
private final ClassLoader parent; 它也是一个ClassLoader的实例这个字段所表示的ClassLoader也称为这个ClassLoader的双亲。在类加载的过程中,ClassLoader可能会将某些请求交予自己的双亲处理。
3.3、loadClass 剖析 执行以下方法的调用测试
ClassLoader.getSystemClassLoader().loadClass(cn.blnp.net.User); 实际调用的执行步骤如下所示
protected Class? loadClass(String name, boolean resolve) //resolve:true-加载class的同时进行解析操作。throws ClassNotFoundException{synchronized (getClassLoadingLock(name)) { //同步操作保证只能加载一次。//首先在缓存中判断是否已经加载同名的类。Class? c findLoadedClass(name);if (c null) {long t0 System.nanoTime();try {//获取当前类加载器的父类加载器。if (parent ! null) {//如果存在父类加载器则调用父类加载器进行类的加载c parent.loadClass(name, false);} else { //parent为null:父类加载器是引导类加载器c findBootstrapClassOrNull(name);}} catch (ClassNotFoundException e) {// ClassNotFoundException thrown if class not found// from the non-null parent class loader}if (c null) { //当前类的加载器的父类加载器未加载此类 or 当前类的加载器未加载此类// 调用当前ClassLoader的findClass()long t1 System.nanoTime();c findClass(name);// this is the defining class loader; record the statssun.misc.PerfCounter.getParentDelegationTime().addTime(t1 - t0);sun.misc.PerfCounter.getFindClassTime().addElapsedTimeFrom(t1);sun.misc.PerfCounter.getFindClasses().increment();}}if (resolve) {//是否进行解析操作resolveClass(c);}return c;}
}3.4、SecureClassLoader 与 URLClassLoader 接着SecureClassLoader扩展了 ClassLoader新增了几个与使用相关的代码源(对代码源的位置及其证书的验证)和权限定义类验证(主要指对class源码的访问权限)的方法一般我们不会直接跟这个类打交道更多是与它的子类URLClassLoader有所关联。 前面说过ClassLoader是一个抽象类很多方法是空的没有实现比如 findClass()、findResource()等。而URLClassLoader这个实现类为这些方法提供了具体的实现。并新增了URLClassPath类协助取得Class字节码流等功能。在编写自定义类加载器时如果没有太过于复杂的需求可以直接继承URLClassLoader类这样就可以避免自己去编写findClass()方法及其获取字节码流的方式使自定义类加载器编写更加简洁。 3.5、ExtClassLoader 与 AppClassLoader 了解完URLClassLoader后接着看看剩余的两个类加载器即拓展类加载器ExtClassLoader和系统类加载器AppClassLoader这两个类都继承自URLClassLoader是sun.misc.Launcher的静态内部类。sun.misc.Launcher主要被系统用于启动主应用程序ExtClassLoader和AppClassLoader都是由sun.misc.Launcher创建的其类主要类结构如下 我们发现ExtClassLoader并没有重写loadClass()方法这足矣说明其遵循双亲委派模式而AppClassLoader重载了loadClass()方法但最终调用的还是父类loadClass()方法因此依然遵守双亲委派模式。
3.6、Class.forName() 与 ClassLoader.loadClass() Class.forName() 是一个静态方法,最常用的是Class.forName(String className);根据传入的类的全限定名返回一个 Class 对象。该方法在将 Class 文件加载到内存的同时,会执行类的初始化。如: Class.forName(cn.blnp.net.HelloWorld); ClassLoader.loadClass() 这是一个实例方法,需要一个 ClassLoader 对象来调用该方法。该方法将 Class 文件加载到内存时,并不会执行类的初始化,直到这个类第一次使用时才进行初始化。该方法因为需要得到一个 ClassLoader 对象,所以可以根据需要指定使用哪个类加载器。如
ClassLoader cl.......;
cl.loadClass(com.atguigu.java.HelloWorld);4、自定义类的加载器
4.1、为什么要自定义类加载器 目的是隔离加载类、修改类加载的方式、扩展加载源以及防止源码泄漏。
隔离加载类在某些框架内进行中间件与应用的模块隔离把类加载到不同的环境。比如阿里内某容器框架通过自定义类加载器确保应用中依赖的jar包不会影响到中间件运行时使用的jar包。再比如Tomcat这类Web应用服务器内部自定义了好几种类加载器用于隔离同一个Web应用服务器上的不同应用程序。 类的仲裁--类冲突修改类加载的方式类的加载模型并非强制除Bootstrap外其他的加载并非一定要引入或者根据实际情况在某个时间点进行按需进行动态加载扩展加载源比如从数据库、网络、甚至是电视机机顶盒进行加载防止源码泄漏Java代码容易被编译和篡改可以进行编译加密。那么类加载也需要自定义还原加密的字节码。
4.2、有哪些应用场景 实现类似进程内隔离类加载器实际上用作不同的命名空间以提供类似容器、模块化的效果。例如两个模块依赖于某个类库的不同版本如果分别被不同的容器加载就可以互不干扰。这个方面的集大成者是Java EE和OSGI、JPMS等框架。 应用需要从不同的数据源获取类定义信息例如网络数据源而不是本地文件系统。或者是需要自己操纵字节码动态修改或者生成类型。 在一般情况下使用不同的类加载器去加载不同的功能模块会提高应用程序的安全性。但是如果涉及Java类型转换则加载器反而容易产生不美好的事情。在做Java类型转换时只有两个类型都是由同一个加载器所加载才能进行类型转换否则转换时会发生异常。
4.3、实现方式 Java提供了抽象类java.lang.ClassLoader所有用户自定义的类加载器都应该继承ClassLoader类。在自定义 ClassLoader 的子类时候我们常见的会有两种做法
方式一重写loadClass()方法方式二重写findClass()方法 --推荐 对比 这两种方法本质上差不多毕竟loadClass()也会调用findClass()但是从逻辑上讲我们最好不要直接修改loadClass()的内部逻辑。建议的做法是只在findClass()里重写自定义类的加载方法根据参数指定类的名字返回对应的Class对象的引用。 loadClass()这个方法是实现双亲委派模型逻辑的地方擅自修改这个方法会导致模型被破坏容易造成问题。因此我们最好是在双亲委派模型框架内进行小范围的改动不破坏原有的稳定结构。同时也避免了自己重写 loadClass()方法的过程中必须写双亲委托的重复代码从代码的复用性来看不直接修改这个方法始终是比较好的选择。当编写好自定义类加载器后便可以在程序中调用loadClass() 方法来实现类加载操作。 其父类加载器是系统类加载器JVM中的所有类加载都会使用java.lang.ClassLoader.loadClass(String)接口(自定义类加载器并重写java.lang.ClassLoader.loadClass(String)接口的除外)连JDK的核心类库也不能例外。
5、类的相关机制
5.1、双亲委派机制
1、本质与定义 类加载器用来把类加载到Java虚拟机中。从JDK1.2版本开始类的加载过程采用双亲委派机制这种机制能更好地保证Java平台的安全。 定义 如果一个类加载器在接到加载类的请求时它首先不会自己尝试去加载这个类而是把这个请求任务委托给父类加载器去完成依次递归如果父类加载器可以完成类加载任务就成功返回。只有父类加载器无法完成此加载任务时才自己去加载。 本质 规定了类加载的顺序是引导类加载器先加载若加载不到由扩展类加载器加载若还加载不到才会由系统类加载器或自定义的类加载器进行加载。 完整的委派过程如下 文字化流程步骤由蓝线开始先向上委派如果顶层无法处理则从顶层红线开始向下委派处理 2、源码分析 双亲委派机制在java.lang.ClassLoader.loadClass(String,boolean)接口中有完整体现。该接口的逻辑如下
(1)、先在当前加载器的缓存中查找有无目标类如果有直接返回。
(2)、判断当前加载器的父加载器是否为空如果不为空则调用parent.loadClass(name, false)接口进行加载。
(3)、反之如果当前加载器的父类加载器为空则调用findBootstrapClassOrNull(name)接口让引导类加载器进行加载。
(4)、如果通过以上3条路径都没能成功加载则调用findClass(name)接口进行加载。该接口最终会调用java.lang.ClassLoader接口的defineClass系列的native接口加载目标Java类。 举例说明 假设当前加载的是 java.lang.Object 这个类很显然该类属于JDK中核心得不能再核心的一个类因此一定只能由引导类加载器进行加载。当JVM准备加载 java.Jang.Object 时JVM默认会使用系统类加载器去加载按照上面4步加载的逻辑在第1步从系统类的缓存中肯定查找不到该类于是进入第2步。由于从系统类加载器的父加载器是扩展类加载器于是扩展类加载器继续从第1步开始重复。由于扩展类加载器的缓存中也一定査找不到该类因此进入第2步。扩展类的父加载器是null,因此系统调用findClass(String), 最终通过引导类加载器进行加载。 思考问题 如果在自定义的类加载器中重写java.lang.ClassLoader.loadClass(String)或 java.lang.ClassLoader.loadClass(String, boolean)方法,抹去其中的双亲委派机制,仅保留上面这4步中的第1步与第4步那么是不是就能够加载核心类库了呢 答不行 因为JDK还为核心类库提供了一层保护机制。不管是自定义的类加载器还是系统类加载器抑或扩展类加载器最终都必须调用 java.lang.ClassLoader.defineClass(String, byte[], int, int, ProtectionDomain)方法而该方法会执行 preDefineClass() 接口该接口中提供了对JDK核心类库的保护。
3、双亲委派机制的优劣势
3.1、优势 避免类的重复加载确保一个类的全局唯一性。Java类随着它的类加载器一起具备了一种带有优先级的层次关系通过这种层级关系可以避免类的重复加载当父亲已经加载了该类时就没有必要子ClassLoader再加载一次。其次是保护程序安全防止核心API被随意篡改。
3.2、弊端 检查类是否加载的委托过程是单向的这个方式虽然从结构上说比较清晰使各个ClassLoader的职责非常明确但是同时会带来一个问题即顶层的ClassLoader无法访问底层的ClassLoader所加载的类。 通常情况下启动类加载器中的类为系统核心类包括一些重要的系统接口而在应用类加载器中为应用类。按照这种模式应用类访问系统类自然是没有问题但是系统类访问应用类就会出现问题。比如在系统类中提供了一个接口该接口需要在应用类中得以实现该接口还绑定一个工厂方法用于创建该接口的实例而接口和工厂方法都在启动类加载器中。这时就会出现该工厂方法无法创建由应用类加载器加载的应用实例的问题。
3.3、小结 由于Java虚拟机规范并没有明确要求类加载器的加载机制一定要使用双亲委派模型只是建议采用这种方式而已。 比如在Tomcat中类加载器所采用的加载机制就和传统的双亲委派模型有一定区别当缺省的类加载器接收到一个类的加载任务时首先会由它自行加载当它加载失败时才会将类的加载任务委派给它的超类加载器去执行这同时也是Servlet规范推荐的一种做法。
4、双亲委派机制破坏示例
4.1、示例1 双亲委派模型并不是一个具有强制性约束的模型而是Java设计者推荐给开发者们的类加载器实现方式。在Java的世界中大部分的类加载器都遵循这个模型但也有例外的情况直到Java模块化出现为止双亲委派模型主要出现过3次较大规模“被破坏”的情况。
第一次破坏双亲委派机制 双亲委派模型的第一次“被破坏”其实发生在双亲委派模型出现之前——即JDK 1.2面世以前的“远古”时代。 由于双亲委派模型在JDK 1.2之后才被引入但是类加载器的概念和抽象类java.lang.ClassLoader则在Java的第一个版本中就已经存在面对已经存在的用户自定义类加载器的代码Java设计者们引入双亲委派模型时不得不做出一些妥协为了兼容这些已有代码无法再以技术手段避免loadClass()被子类覆盖的可能性只能在JDK1.2之后的java.lang.ClassLoader中添加一个新的protected方法findClass()并引导用户编写的类加载逻辑时尽可能去重写这个方法而不是在loadClass()中编写代码。上节我们已经分析过loadClass()方法双亲委派的具体逻辑就实现在这里面按照loadClass()方法的逻辑如果父类加载失败会自动调用自己的findClass()方法来完成加载这样既不影响用户按照自己的意愿去加载类又可以保证新写出来的类加载器是符合双亲委派规则的。
4.2、示例2
第二次破坏双亲委派机制线程上下文类加载器 双亲委派模型的第二次“被破坏”是由这个模型自身的缺陷导致的双亲委派很好地解决了各个类加载器协作时基础类型的一致性问题越基础的类由越上层的加载器进行加载基础类型之所以被称为“基础”是因为它们总是作为被用户代码继承、调用的API存在但程序设计往往没有绝对不变的完美规则如果有基础类型又要调用回用户的代码那该怎么办呢 这并非是不可能出现的事情一个典型的例子便是JNDI服务JNDI现在已经是Java的标准服务它的代码由启动类加载器来完成加载在JDK 1.3时加入到rt.jar的肯定属于Java中很基础的类型了。但JNDI存在的目的就是对资源进行查找和集中管理它需要调用由其他厂商实现并部署在应用程序的ClassPath下的JNDI服务提供者接口Service Provider InterfaceSPI的代码现在问题来了启动类加载器是绝不可能认识、加载这些代码的那该怎么办SPI:在Java平台中通常把核心类rt.jar中提供外部服务、可由应用层自行实现的接口称为SPI 为了解决这个困境Java的设计团队只好引入了一个不太优雅的设计线程上下文类加载器Thread Context ClassLoader。这个类加载器可以通过java.lang.Thread类的setContextClassLoader()方法进行设置如果创建线程时还未设置它将会从父线程中继承一个如果在应用程序的全局范围内都没有设置过的话那这个类加载器默认就是应用程序类加载器。 有了线程上下文类加载器程序就可以做一些“舞弊”的事情了。JNDI服务使用这个线程上下文类加载器去加载所需的SPI服务代码这是一种父类加载器去请求子类加载器完成类加载的行为这种行为实际上是打通了双亲委派模型的层次结构来逆向使用类加载器已经违背了双亲委派模型的一般性原则但也是无可奈何的事情。Java中涉及SPI的加载基本上都采用这种方式来完成例如JNDI、JDBC、JCE、JAXB和JBI等。不过当SPI的服务提供者多于一个的时候代码就只能根据具体提供者的类型来硬编码判断为了消除这种极不优雅的实现方式在JDK 6时JDK提供了java.util.ServiceLoader类以META-INF/services中的配置信息辅以责任链模式这才算是给SPI的加载提供了一种相对合理的解决方案。 默认上下文加载器就是应用类加载器这样以上下文加载器为中介使得启动类加载器中的代码也可以访问应用类加载器中的类。
4.3、示例3
第三次破坏双亲委派机制 双亲委派模型的第三次“被破坏”是由于用户对程序动态性的追求而导致的。如代码热替换Hot Swap、模块热部署Hot Deployment等 IBM公司主导的JSR-291即OSGi R4.2实现模块化热部署的关键是它自定义的类加载器机制的实现每一个程序模块OSGi中称为Bundle都有一个自己的类加载器当需要更换一个Bundle时就把Bundle连同类加载器一起换掉以实现代码的热替换。在OSGi环境下类加载器不再双亲委派模型推荐的树状结构而是进一步发展为更加复杂的网状结构。当收到类加载请求时OSGi将按照下面的顺序进行类搜索
1将以java.*开头的类委派给父类加载器加载。
2否则将委派列表名单内的类委派给父类加载器加载。
3否则将Import列表中的类委派给Export这个类的Bundle的类加载器加载。
4否则查找当前Bundle的ClassPath使用自己的类加载器加载。
5否则查找类是否在自己的Fragment Bundle中如果在则委派给Fragment Bundle的类加载器加载。
6否则查找Dynamic Import列表的Bundle委派给对应Bundle的类加载器加载。
7否则类查找失败。
说明只有开头两点仍然符合双亲委派模型的原则其余的类查找都是在平级的类加载器中进行的
5、热替换的实现 热替换是指在程序的运行过程中不停止服务只通过替换程序文件来修改程序的行为。热替换的关键需求在于服务不能中断修改必须立即表现正在运行的系统之中。基本上大部分脚本语言都是天生支持热替换的比如PHP只要替换了PHP源文件这种改动就会立即生效而无需重启Web服务器。 但对Java来说热替换并非天生就支持如果一个类已经加载到系统中通过修改类文件并无法让系统再来加载并重定义这个类。因此在Java中实现这一功能的一个可行的方法就是灵活运用ClassLoader。 注意由不同ClassLoader加载的同名类属于不同的类型不能相互转换和兼容。即两个不同的ClassLoader加载同一个类在虚拟机内部会认为这2个类是完全不同的。 根据这个特点可以用来模拟热替换的实现基本思路如下图所示 5.2、沙箱安全机制 Java安全模型的核心就是Java沙箱sandbox。什么是沙箱沙箱是一个限制程序运行的环境。沙箱机制就是将Java代码限定在虚拟机JVM特定的运行范围中并且严格限制代码对本地系统资源访问。通过这样的措施来保证对代码的有限隔离防止对本地系统造成破坏。 沙箱主要限制系统资源访问那系统资源包括什么CPU、内存、文件系统、网络。不同级别的沙箱对这些资源访问的限制也可以不一样。所有的Java程序运行都可以指定沙箱可以定制安全策略。
1、JDK 1.0 时期 在Java中将执行程序分成本地代码和远程代码两种本地代码默认视为可信任的而远程代码则被看作是不受信的。对于授信的本地代码可以访问一切本地资源。而对于非授信的远程代码在早期的Java实现中安全依赖于沙箱Sandbox机制。如下图所示JDK1.0安全模型。 2、JDK 1.1 时期 JDK1.0中如此严格的安全机制也给程序的功能扩展带来障碍比如当用户希望远程代码访问本地系统的文件时候就无法实现。 因此在后续的Java1.1版本中针对安全机制做了改进增加了安全策略。允许用户指定代码对本地资源的访问权限。如下图所示JDK1.1安全模型 3、JDK 1.2 时期 在Java1.2版本中再次改进了安全机制增加了代码签名。不论本地代码或是远程代码都会按照用户的安全策略设定由类加载器加载到虚拟机中权限不同的运行空间来实现差异化的代码执行权限控制。如下图所示JDK1.2安全模型 4、JDK 1.6 时期 当前最新的安全机制实现则引入了域Domain的概念。 虚拟机会把所有代码加载到不同的系统域和应用域。系统域部分专门负责与关键资源进行交互而各个应用域部分则通过系统域的部分代理来对各种需要的资源进行访问。虚拟机中不同的受保护域Protected Domain对应不一样的权限Permission。存在于不同域中的类文件就具有了当前域的全部权限如下图所示最新的安全模型jdk1.6) 6、jdk9 中类加载结构的变化 为了保证兼容性JDK 9没有从根本上改变三层类加载器架构和双亲委派模型但为了模块化系统的顺利运行仍然发生了一些值得被注意的变动。
1、扩展机制被移除扩展类加载器由于向后兼容性的原因被保留不过被重命名为平台类加载器platform class loader。可以通过ClassLoader的新方法getPlatformClassLoader()来获取。 JDK 9 时基于模块化进行构建原来的 rt.jar 和 tools.jar 被拆分成数十个 JMOD 文件其中的 Java 类库就已天然地满足了可扩展的需求那自然无须再保留 JAVA_HOME\lib\ext 目录此前使用这个目录或者 java.ext.dirs 系统变量来扩展 JDK 功能的机制已经没有继续存在的价值了。
2、平台类加载器和应用程序类加载器都不再继承自 java.net.URLClassLoader。现在启动类加载器、平台类加载器、应用程序类加载器全都继承于 jdk.internal.loader.BuiltinClassLoader。 如果有程序直接依赖了这种继承关系或者依赖了 URLClassLoader 类的特定方法那代码很可能会在 JDK 9 及更高版本的 JDK 中崩溃。
3、在Java 9中类加载器有了名称。该名称在构造方法中指定可以通过getName()方法来获取。平台类加载器的名称是platform应用类加载器的名称是app。类加载器的名称在调试与类加载器相关的问题时会非常有用。
4、启动类加载器现在是在jvm内部和java类库共同协作实现的类加载器以前是 C实现但为了与之前代码兼容在获取启动类加载器的场景中仍然会返回null而不会得到BootClassLoader实例。
5、类加载的委派关系也发生了变动。 当平台及应用程序类加载器收到类加载请求在委派给父加载器加载前要先判断该类是否能够归属到某一个系统模块中如果可以找到这样的归属关系就要优先委派给负责那个模块的加载器完成加载。 拓展 在 Java 模块化系统明确规定了三个类加载器负责各自加载的模块 启动类加载器负责加载的模块 java.base java.security.sasl
java.datatransfer java.xml
java.desktop jdk.httpserver
java.instrument jdk.internal.vm.ci
java.logging jdk.management
java.management jdk.management.agent
java.management.rmi jdk.naming.rmi
java.naming jdk.net
java.prefs jdk.sctp
java.rmi jdk.unsupported 平台类加载器负责加载的模块 java.activation* jdk.accessibility
java.compiler* jdk.charsets
java.corba* jdk.crypto.cryptoki
java.scripting jdk.crypto.ec
java.se jdk.dynalink
java.se.ee jdk.incubator.httpclient
java.security.jgss jdk.internal.vm.compiler*
java.smartcardio jdk.jsobject
java.sql jdk.localedata
java.sql.rowset jdk.naming.dns
java.transaction* jdk.scripting.nashorn
java.xml.bind* jdk.security.auth
java.xml.crypto jdk.security.jgss
java.xml.ws* jdk.xml.dom
java.xml.ws.annotation* jdk.zipfs 应用程序类加载器负责加载的模块 jdk.aot jdk.jdeps
jdk.attach jdk.jdi
jdk.compiler jdk.jdwp.agent
jdk.editpad jdk.jlink
jdk.hotspot.agent jdk.jshell
jdk.internal.ed jdk.jstatd
jdk.internal.jvmstat jdk.pack
jdk.internal.le jdk.policytool
jdk.internal.opt jdk.rmic
jdk.jartool jdk.scripting.nashorn.shell
jdk.javadoc jdk.xml.bind*
jdk.jcmd jdk.xml.ws*
jdk.jconsole
7、相关面试题
7.1、说说类加载分几步都有谁需要加载 按照Java虚拟机规范从class文件到加载到内存中的类到类卸载出内存为止它的整个生命周期包括如下7个阶段 其中第一过程的加载Loading也称为装载验证、准备、解析三个部分统称为链接Linking。如果从程序中类的使用过程看大致如下流程 因为在Java中数据类型分为基本数据类型和引用数据类型。基本数据类型由虚拟机预先定义引用数据类型则需要进行类的加载。
7.2、可以打破双亲委派吗怎么打破 可以破坏打破方式详见上述章节《双亲委派机制破坏示例》
7.3、Tomcat8 和 Tomcat6比较大的区别是 Tomcat8可以通过配置 Loader delegatetrue/ 表示遵循双亲委派机制。
7.4、什么是Tomcat的类加载机制 Tomcat的类加载机制是违反了双亲委托原则的对于一些未加载的非基础类各个web应用自己的类加载器(WebAppClassLoader)会优先查看自己的仓库加载加载不到时再交给commonClassLoader走双亲委托。 Tomcat 如何实现自己独特的类加载机制 当tomcat启动时会创建几种类加载器
1. Bootstrap 引导类加载器 加载JVM启动所需的类以及标准扩展类位于jre/lib/ext下
2. System 系统类加载器 加载tomcat启动的类比如bootstrap.jar通常在catalina.bat或者catalina.sh中指定。位于CATALINA_HOME/bin下。 3. CommonClassLoader、CatalinaClassLoader、SharedClassLoader和WebappClassLoader 这些是Tomcat自己定义的类加载器它们分别加载/common/*、/server/*、/shared/*在tomcat 6之后已经合并到根目录下的lib目录下和/WebApp/WEB-INF/*中的Java类库。其中WebApp类加载器和Jsp类加载器通常会存在多个实例每一个Web应用程序对应一个WebApp类加载器每一个JSP文件对应一个Jsp类加载器。
commonLoaderTomcat最基本的类加载器加载路径中的class可以被Tomcat容器本身以及各个Webapp访问加载CATALINA_HOME/lib下的结构比如servlet-api.jarcatalinaLoaderTomcat容器私有的类加载器加载路径中的class对于Webapp不可见sharedLoader各个Webapp共享的类加载器加载路径中的class对于所有Webapp可见但是对于Tomcat容器不可见WebappClassLoader单个Tomcat实例中各个Web应用程序私有的类加载器加载路径中的class只对当前Webapp可见(加载WEB-INF/lib和WEB-INF/classes下的结构 从图中的委派关系中可以看出CommonClassLoader能加载的类都可以被Catalina ClassLoader和SharedClassLoader使用从而实现了公有类库的共用而CatalinaClassLoader和Shared ClassLoader自己能加载的类则与对方相互隔离。 WebAppClassLoader可以使用SharedClassLoader加载到的类但各个WebAppClassLoader实例之间相互隔离。而JasperLoader的加载范围仅仅是这个JSP文件所编译出来的那一个.class文件它出现的目的就是为了被丢弃当Web容器检测到JSP文件被修改时会替换掉目前的JasperLoader的实例并通过再建立一个新的Jsp类加载器来实现JSP文件的HotSwap功能。 当应用需要到某个类时则会按照下面的顺序进行类加载
使用bootstrap引导类加载器加载使用system系统类加载器加载使用应用类加载器在WEB-INF/classes中加载使用应用类加载器在WEB-INF/lib中加载使用common类加载器在CATALINA_HOME/lib中加载 至此我们已经知道了tomcat为什么要这么设计以及是如何设计的那么tomcat 违背了java 推荐的双亲委派模型了吗答案是违背了。 我们前面说过双亲委派模型要求除了顶层的启动类加载器之外其余的类加载器都应当由自己的父类加载器加载。 很显然tomcat 不是这样实现tomcat 为了实现隔离性没有遵守这个约定每个webappClassLoader加载自己的目录下的class文件不会传递给父类加载器。
7.5、了解 Tomcat 中 WebappClassLoader 类加载器吗
1 public Class loadClass(String name, boolean resolve)2 throws ClassNotFoundException {3 Class clazz null;4 // (0) 先从自己的缓存中查找有则返回无则继续5 clazz findLoadedClass0(name);6 if (clazz ! null) {7 if (resolve) resolveClass(clazz); 8 return (clazz);9 }
10 // (0.1) 再从parent的缓存中查找
11 clazz findLoadedClass(name);
12 if (clazz ! null) {
13 if (resolve) resolveClass(clazz);
14 return (clazz);
15 }
16 // (0.2) 缓存中没有则首先使用system类加载器来加载
17 clazz system.loadClass(name);
18 if (clazz ! null) {
19 if (resolve) resolveClass(clazz);
20 return (clazz);
21 }
22 //判断是否需要先让parent代理
23 boolean delegateLoad delegate || filter(name);
24 // (1) 先让parent加载通常delegateLoad false即这一步不会执行
25
26 if (delegateLoad) {
27 ClassLoader loader parent;
28 if (loader null)
29 loader system;
30 clazz loader.loadClass(name);
31 if (clazz ! null) {
32 if (resolve) resolveClass(clazz);
33 return (clazz);
34 }
35 }
36 // (2) delegateLoad false 或者 parent加载失败调用自身的加载机制
37 clazz findClass(name);
38 if (clazz ! null) {
39 if (resolve) resolveClass(clazz);
40 return (clazz);
41 }
42 // (3) 自己加载失败则请求parent代理加载
43
44 if (!delegateLoad) {
45 ClassLoader loader parent;
46 if (loader null)
47 loader system;
48 clazz loader.loadClass(name);
49 if (clazz ! null) {
50 return (clazz);
51 }
52 }
53 throw new ClassNotFoundException(name);
54 }根据源码可知首先 findLoadedClass0() 和 findLoadedClass() 分别从本地和父类加载器的缓存中查找当前要加载的类是否已经加载过了。之后为了避免上面提到的安全问题Tomcat类加载器会将加载请求委派给系统类加载器。接下来根据delegate变量的设置决定是先由自己加载还是先由父类加载器去加载。
7.6、既然 Tomcat 不遵循双亲委派机制那么如果我自己定义一个恶意的HashMap会不会有风险呢(阿里面试问题)
答 显然不会有风险如果有Tomcat都运行这么多年了那能不改进吗 tomcat不遵循双亲委派机制只是自定义的classLoader顺序不同但顶层还是相同的还是要去顶层请求classloader。
7.7、我们思考一下Tomcat是个web容器 那么它要解决什么问题
1. 一个web容器可能需要部署两个应用程序不同的应用程序可能会依赖同一个第三方类库的不同版本不能要求同一个类库在同一个服务器只有一份因此要保证每个应用程序的类库都是独立的保证相互隔离。 2. 部署在同一个web容器中相同的类库相同的版本可以共享。否则如果服务器有10个应用程序那么要有10份相同的类库加载进虚拟机这是扯淡的。 3. web容器也有自己依赖的类库不能于应用程序的类库混淆。基于安全考虑应该让容器的类库和程序的类库隔离开来。 4. web容器要支持jsp的修改我们知道jsp 文件最终也是要编译成class文件才能在虚拟机中运行但程序运行后修改jsp已经是司空见惯的事情否则要你何用 所以web容器需要支持 jsp 修改后不用重启。
7.8、Tomcat 如果使用默认的类加载机制行不行
答案是不行的。为什么我们看:第一个问题如果使用默认的类加载器机制那么是无法加载两个相同类库的不同版本的默认的类加器是不管你是什么版本的只在乎你的全限定类名并且只有一份。第二个问题默认的类加载器是能够实现的因为他的职责就是保证唯一性。第三个问题和第一个问题一样。 我们再看第四个问题我们想我们要怎么实现jsp文件的热替换jsp 文件其实也就是class文件那么如果修改了但类名还是一样类加载器会直接取方法区中已经存在的修改后的jsp是不会重新加载的。那么怎么办呢我们可以直接卸载掉这jsp文件的类加载器所以你应该想到了每个jsp文件对应一个唯一的类加载器当一个jsp文件修改了就直接卸载这个jsp类加载器。重新创建类加载器重新加载jsp文件。
7.9、如果tomcat 的 Common ClassLoader 想加载 WebApp ClassLoader 中的类该怎么办 看了前面的关于破坏双亲委派模型的内容我们心里有数了我们可以使用线程上下文类加载器实现使用线程上下文加载器可以让父类加载器请求子类加载器去完成类加载的动作。
7.10、为什么java文件放在Eclipse/IDEA中的src文件夹下会优先jar包中的class? tomcat类加载机制的理解就不难明白。因为Eclipse/IDEA中的src文件夹中的文件java以及webContent中的JSP都会在tomcat启动时被编译成class文件放在 WEB-INF/class 中。而Eclipse/IDEA外部引用的jar包则相当于放在 WEB-INF/lib 中。因此肯定是 java文件或者JSP文件编译出的class优先加载。
