随州网站推广哪家权威,杭州p2p网站开发商,沈阳网络平台推广公司,wordpress的登录页面模板【0】README0.1#xff09;本文转自“深入理解jvm”#xff0c;旨在学习 虚拟机类加载机制 的基础知识#xff1b;【1】概述1#xff09;类加载机制#xff1a;虚拟机把描述类的数据从Class 文件加载到内存#xff0c;并对数据进行校验#xff0c;转换解析和初始化本文转自“深入理解jvm”旨在学习 虚拟机类加载机制 的基础知识【1】概述1类加载机制虚拟机把描述类的数据从Class 文件加载到内存并对数据进行校验转换解析和初始化最终形成可以被虚拟机直接使用的java类型这就是虚拟机的类加载机制2在java中 类型的加载链接和初始化过程都是在程序运行期间完成的java里天生可以动态扩展的语言特性就是依赖运行期动态加载和动态链接这个特点实现的3看个荔枝编写一个面向接口的应用程序可以等到运行时再指定具体的实现类用户可以通过java预定义的和自定义类加载器让一个本地的应用程序可以在运行时从网络或其他地方加载一个二进制流作为程序代码的一部分这种组装应用程序的方式目前已广泛应用与 java 程序中了【2】类加载的时机1类的生命周期类从被加载到虚拟机内存中开始到卸载出内存位置他的整个生命周期包括 加载 验证准备解析初始化使用和卸载7个阶段。其中验证准备解析3个部分统称为 链接这7个阶段的发生顺序如下图所示干货——类的生命周期共7个阶段对上图的分析AnalysisA1加载验证准备初始化卸载这5个阶段的顺序是确定的A2解析阶段则不一定它在某些情况下可以在初始化阶段之后再开始这是为了支持java的运行时绑定也称动态绑定或晚期绑定 2对于初始化阶段虚拟机规范则是严格规定了有且只有5种情况必须立即对类进行初始化casescase1遇到new getstatic putstatic, 或 invokestatic 这4条字节码指令时如果类没有进行过初始化则需要先触发其初始化生成这4条指令的最常见的java代码场景是使用new关键字实例化对象的时候读取或设置一个类的静态字段被final修饰、已在编译器把结果放入常量池的静态字段除外的时候以及调用一个类的静态方法的时候case2使用 java.lang.reflect 包的方法对类进行反射调用的时候如果类没有进行初始化则需要先触发其初始化case3当初始化一个类的时候如果发现其父类还没有进行过初始化则需要先触发其父类的初始化case4当虚拟机启动时用户需要制定一个要执行的主类包含main方法的那个类虚拟机会先初始化这个主类case5当使用jdk1.7 的动态语言支持时如果一个 java.lang.invoke.MethodHandle 实例最后的解析结果 REF_getStatic, REF_putStatic, REF_invokeStatic 的方法句柄并且这个方法句柄所对应的类没有进行过初始化则需要先触发其初始化 3主动引用被动引用3.1主动引用对于这5种会触发类进行初始化的场景虚拟机规范中使用了一个很强烈的限定语有且只有 这5种场景中的行为称为对一个类进行主动引用3.2被动引用除此之外 所有引用类的方式都不会触发初始化称为被动引用3.3看个荔枝ex1通过子类引用父类的静态字段不会导致子类初始化 public class SuperClass {//父类public static int value 123;static {System.out.println(SuperClass init!);}
}
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);}/*** output: * SuperClass init!* 123* 通过子类引用父类的静态字段不会导致子类初始化*/
} 对于Sun HotSpot虚拟机来说可通过 -XX:TraceClassLoading 参数观察到此操作会导致子类的加载 ex2无输出 运行之后发现并没有输出SuperClass init说明并没有触发com.jvm.chapter7.Super Class的类的初始化而触发了 Lcom.jvm.chapter7.SuperClass的类的初始化对于用户代码来说这并不是一个合法的类名称它是由一个虚拟机自动生成的继承自Object的子类创建动作由字节码指令newarray 触发 public class NotInitalization2 {public static void main(String[] args) {SuperClass[] sc_array new SuperClass[10];}/*** output: nothing* 运行之后发现并没有输出SuperClass init说明并没有触发com.jvm.chapter7.Super* Class的类的初始化而触发了 Lcom.jvm.chapter7.SuperClass的类的初始化对于用户* 代码来说这并不是一个合法的类名称它是由一个虚拟机自动生成的继承自Object的子类创建动作由* 字节码指令newarray 触发*/
} Lcom.jvm.chapter7.SuperClass 代表了类型为 com.jvm.chapter7.SuperClass 的一维数组。数组中应用的属性和方法都实现在这个类里。java中对数组的访问要比C或C 相对安全是因为这个类封装了数组元素的访问方法而C或C 直接翻译为对数组指针的移动 ex3无输出public class ConstClass {public static final String HELLOWORD hello world;static {System.out.println(ConstClass init);}
}strong
/strongpublic class NotInitalization3 {public static void main(String[] args) {System.out.println(ConstClass.HELLOWORD);}/*** output: hello world*/
} 对上图的分析Analysis A1没有输出“ConstClass init”的原因虽然在java源码中引用了 ConstClass类中的常量HELLOWORLD 但其实在编译阶段通过常量传播优化已经将此常量的值“hello world”存储到了NotInitialization3 的常量池中以后 NotInitialization3 对常量 ConstClass.HELLOWORLD 的引用实际都被转化为 NotInitialization 类对自身常量池的引用了。也就是说实际上 NotInitialization3 的Class 文件中并没有 ConstClass类的符号引用入口这两个类在编译成Class 之后就不存在任何联系了 4接口的加载与类加载的不同4.1接口也有初始化过程类中用静态语句块staitc 来输出初始化信息的而接口中不能使用“static”语句块但编译器仍然会为接口生成 “clinit()” 类构造器用于初始化接口中定义的成员变量4.2接口与类的真正区别是当一个类在初始化时要求其父类全部都已经初始化过了但是在一个接口初始化时并不要求其父接口全部不完成初始化只有在真正使用到父接口的时候才会初始化【3】类加载过程加载到验证到准备到解析到初始化【3.1】加载1加载是类加载过程的一个阶段不要混淆加载和类加载的概念2在加载阶段虚拟机需要完成以下3件事情step1通过一个类的全限定名来获取定义此类的二进制字节流step2将这个字节流所代表的静态存储接口转化为 方法区的运行时数据结构step3在内存中生成一个代表这个类的java.lang.Class 对象作为方法区这个类的各种数据的访问入口 3一个非数组类的加载阶段是开发人员可控性最强的因为加载阶段3.1既可以使用系统提供的引导类加载器来完成3.2也可以由用户自定义的类加载器去完成开发人员可以通过定义自己的类加载器去控制字节流的获取方式即重写一个类加载器的loadClass这个方法 4对于数组类而言情况有所不同数组类本身不通过类加载器创建它是由java虚拟机直接创建的 。数组类的创建规则遵循以下规则rulesrule1如果数组的组件类型Component Type 指的是数组去掉一个维度的类型是引用类型那就递归采用本节中定义的加载过程去加载这个组件类型数组C 将在加载该组件类型的类加载器的类名称空间上被标识rule2如果数组的组件类型不是引用类型如int[] 数组java虚拟机将会把数组C 标记为与引导类加载器关联rule3数组类的可见性与它的组件类型的可见性一致如果组件类型不是引用类型那数组类的可见性将默认为 public 5加载阶段完成后虚拟机外部的二进制字节流就按照虚拟机所需的格式存储在方法区之中方法区中的数据存储格式由虚拟机实现自行定义虚拟机规范未规定此区域的具体数据结构 然后在内存中实例化一个 java.lang.Class 类的对象这个对象将作为程序访问方法区中的这些类型数据的外部接口6加载阶段和连接阶段如一部分字节码文件格式验证动作的部分内容是交叉进行的连接阶段包括验证准备解析【3.2】验证连接第一步1目的为了确保Class 文件的字节流中包含的信息符合当前虚拟机的要求并且不会危害虚拟机自身的安全 2要知道Class文件 并不一定要求用java源码编译而来可以使用任何途径产生甚至包括用16进制编辑器直接编写来产生Class 文件3验证阶段非常重要它直接决定了java虚拟机是否能够承受恶意代码的攻击从执行性能的角度上讲验证阶段的工作量在虚拟机的类加载子系统中又占了相当大的一部分4验证阶段大致上会完成下面4个阶段的检验动作文件格式验证、元数据验证、字节码验证、符号引用验证4.1文件格式验证包括魔数主次版本等信息目的是保证输入的字节流能正确地解析并存储于方法区之内格式上符合描述一个 java类型信息的要求所以后面的3个验证阶段全部是基于方法区的存储结构进行的不会再直接操作字节流4.2元数据验证是否有父类是否继承了不该继承的类是否抽象类子类中的字段和方法是否与父类产生矛盾等信息4.3字节码验证目的是通过数据流和控制流分析确定程序语义是合法的符合逻辑的这个阶段将对类的方法体进行校验分析保证被校验类的方法在运行时不会做出危害虚拟机安全的事件 4.3.1若方法体内的字节码没有通过字节码验证则肯定有问题但若通过了也不一定证明其一定是安全的。这里涉及到离散数学中的一个很著名的问题“halting problem” 通过程序去校验程序逻辑无法做到绝对正确的——不能通过程序准确地检查出程序是否能在有限的时间内结束运行干货——离散数学中的一个很著名的问题“halting problem”4.3.2在jdk1.6 之后的javac编译器和java虚拟机中进行了优化给方法体的Code属性的属性表中增加了一项名为 “StackMapTable”的属性这项属性描述了方法体中所有的基本块开始时本地变量表和操作栈应用的状态在字节码验证期间就不需要根据程序推导这些状态的合法性只需要检查 StackMapTable 属性中的记录是否合法即可从而节省时间4.3.3problemsolutionproblem理论上 StackMapTable 属性也存在错误或被篡改的可能所以是否有可能在恶意篡改了Code属性的同时也生成相应的StackMapTable 属性来骗过虚拟机的类型校验则是虚拟机设计者值得思考的问题solutionjdk1.6 的HotSpot虚拟机提供了 -XX: -UseSplitVerifier 选项来关闭这项优化或者使用参数 -XX: FailOverToOldVerifier 要求在类型校验失败时再退回到旧的类型推导方式进行校验 4.4符号引用验证 该验证发生在虚拟机将符号引用转化为 直接引用的时候这个转化动作将在连接的第三阶段——解析阶段中发生。符号引用验证看做是对类自身以外的信息进行匹配性校验校验内容如引用的全限定名是否能找到对应的类符号引用中的类字段方法的访问性是否合法等信息 4.4.1目的是确保解析动作能正常进行如果无法通过验证将抛出 java.lang.IncompatibleClassChangeError 异常的子类4.4.2如果所运行的全部代码都已经被反复使用和验证过那么在实施阶段就可以考虑使用 -Xverify:none 参数来关闭大部分的类验证措施以缩短虚拟机类加载的时间 【3.3】准备1准备阶段所做的工作是正式为类变量分配内存并设置其初始值 这些变量所使用的内存都将在方法区中进行分配AttentionA1准备阶段进行内存分配的仅包括类变量被static修饰的变量而不包括实例变量实例变量将会在对象实例化的时候随着对象一起分配在 java堆中A2通常情况下这里所说的初始值“通常情况”下是数据类型的零值假设一个类变量的定义为public static int value123那变量value 在准备阶段过后的初始化为0而不是123因为这时候尚未开始执行任何 java方法而把value赋值为 123 的putstatic 指令是程序被编译后存放于类构造器clinit方法之中所以把 value赋值为 123的动作将在初始化阶段才会执行A3特殊情况下如果类字段的字段属性表中存在 ConstantValue 属性那在准备阶段变量 value 就会被初始化为 ConstantValue属性所指定的值假设上面类变量的value的定义变为 public static final int value 123编译时javac 将会为value生成 ConstantValue属性在准备阶段虚拟机就根据 ConstantValue 的设置将 value赋值为 123干货——被final修饰的字段就是特殊情况 2java中所有基本数据类型的零值如下所示【3.4】解析1解析阶段的工作内容将虚拟机将常量池内的符号引用替换为 直接引用的过程符号引用在Class文件中以 CONTANT_Class_info, CONSTNAT_Fieldref_info CONSTNAT_Methodref_info 等类型的常量出现2符号引用与直接引用的关联2.1符号引用符号引用以一组符号来描述所引用的目标符号可以是任何形式的字面量只要使用时能无歧义地定位到目标即可2.2直接引用直接引用可以是 直接指向目标的指针相对偏移量或是一个能间接定位到目标的句柄。2.3符号引用和直接引用的区别同一个符号引用在不同虚拟机实例上翻译出来的直接引用一般不会相同如果有了直接引用那引用的目标必定已经在内存中存在了 3虚拟机规范中要求了在执行 anewarray, checkcast, getfield, getstatic, instanceof, invokebynamic, invokeinterface, invokespecial, invokestatic, invokevirtual, ldc, ldc_w, multinaewarray, new, putfield, putstatic 这16个用于操作 符号引用的字节码指令前先对他们所使用的符号引用进行解析4除开 invokeddynamic指令对同一个符号引用进行多次解析请求是很常见的事情虚拟机实现可以对第一次解析的结果进行缓存从而避免解析动作重复进行。虚拟机需要保证在同一个实体中 如果一个符号引用前已经被成功解析过那么后续的引用解析请求就应当一直成功5对于 invokeddynamic指令该指令的目的就是用于动态语言支持它所对应的引用称为“动态调用点限定符”这里动态的含义就是必须等到程序实际运行到这条指令的时候解析动作才能进行相对的其余可触发解析的指令都是静态的可以在刚刚完成完成加载阶段还没有开始执行代码时就进行解析6解析动作主要针对类接口类方法接口方法方法类型方法句柄调用点限定符7类符号引用进行分别对应于常量池的CONSTANT_Class_info, CONSTANT_Fieldref_info, CONSTANT_Methodref_info, CONSTANT_InterfaceMethodref_info, CONSTANT_MethodType_info, CONSTANT_MethodHandle_info, CONSTANT_InvokeDynamic_info 7 种常量类型。下面讲解前4种引用的解析过程6.1类或接口的解析假设当前代码所处的类为D若要把一个从未解析过的符号引用N解析为一个类或接口C的直接引用那虚拟机完成解析的过程需要以下3个steps step1如果C 不是一个数组类型那虚拟机将会把代表N 的全限定名传递给D的类加载器去加载这个类Cstep2如果C是一个数组类型并且数组的元素类型为对象也就是N 的描述符会是类似 “[Ljava/lang/Integer” 的形式那将会按照第1点的规则加载数组元素类型step3若上面的步骤没有出现任何异常那么C 在虚拟机中实际上已经成为一个有效的类或接口了但在解析完成前还要进行符号引用验证确认D是否具备对C 的访问权限 6.2字段解析1要解析一个未被解析过的字段符号引用首先将会对字段表内 class_index 项中索引的 CONSANT_Class_info 符号引用进行解析也就是字段所属的类或接口的符号引用 2若解析成功那将这个字段所属的类或接口用C表示虚拟机规范要求按照如下steps 对C 进行后续字段的搜索 step1如果C 本身就包含了简单名称和字段描述符都与目标相匹配的字段则返回这个字段的直接引用查找结束step2否则如果在C中实现了接口将会按照继承关系从下往上递归搜索各个接口和它的父接口如果接口中包含了简单名称和字段描述符都与目标相匹配的字段则返回这个字段的直接引用查找结束step3否则如果C不是 java.lang.Object 的话将会按照继承关系从下往上递归搜索其父类如果在父类中包含了简单名称和字段描述符都与目标相匹配的字段则返回这个字段的直接引用查找结束step4否则查找失败抛出 java.lang.NoSuchFieldError 异常 3如果查找过程中返回了引用将会对这个字段进行权限验证如果发现不具备对这个字段的访问权限将抛出 java.lang.IllegalAccessError 异常 4对于同名字段编译器拒绝编译 public class FieldResolution {interface Interface0 {int A 0;}interface Interface1 extends Interface0 {int A 1;}interface Interface2 {int A 2;}static class Parent implements Interface1 {public static int A 3;}static class Sub extends Parent implements Interface2 {public static int A 4;/*** 如果注释了Sub类中的 public static int A 4; 接口与父类同时存在字段A那编译器* 将提示 “the field Sub.A is ambiguous”并且拒绝编译 */}public static void main(String[] args) {System.out.println(Sub.A); // output: 4}
} 6.3类方法解析6.3.1类方法解析的第一个步骤与字段解析一样也需要先解析出类方法表的class_index 项中索引的方法所属的类或接口的符号引用如果解析成功我们依然用C表示这个 类接下来虚拟机将会按照如下steps 进行后续的类方法搜索step1类方法和接口方法符号引用的常量类型定义是分开的如果在类方法表中发现 class_index 索引的C 是个接口那就直接抛出 java.lang.IncompatibleClassChangeError 异常step2如果通过了第1步在类C中查找是否有简单名称和描述符都与目标相匹配的方法如果有则返回这个方法的直接引用查找结束step3否则在其父类中查找是否有简单名称和描述符都与目标相匹配的方法如果有则返回这个方法的直接引用查找结束step4否则在类C实现的接口列表以及它们的父接口中查找是否有简单名称和描述符都与目标相匹配的方法如果存在匹配的方法说明类C 是一个抽象类这是查找结束抛出 AbstractMethodError异常step5否则宣告方法查找失败抛出 java.lang.NoSuchMethodError最后查找成功后还要进行权限验证如果权限不匹配将抛出 java.lang.IllegalAccessError 异常 6.4接口方法解析6.4.1接口方法也需要先解析class_index 项中索引的方法所属的类或接口的符号引用如果解析成功我们依然用C表示这个 类接下来虚拟机将会按照如下steps 进行后续的类方法搜索step1如果在接口方法表中发现class_index 中的索引C是个类而不是接口抛出 java.lang.IncompatibleClassChangeError 异常step2否则在接口C中查找是否有简单名称和描述符都与目标相匹配的方法如果有则返回这个方法的直接引用查找结束step3否则在接口C的父接口中递归查找直到 java.lang.Object类为止看是否有简单名称和描述符都与目标相匹配的方法如果有则返回这个方法的直接引用查找结束step4否则查找失败抛出 java.lang.NoSuchMethodError 异常 2由于接口方法默认都是 public所以不存在访问权限问题【3.5】初始化类加载过程的最后一步0前面的类加载过程中除了在加载阶段用户应用程序可以通过自定义类加载器参与之外其余动作完全由虚拟机主导和控制。到了初始化阶段才真正开始执行类中定义的java程序代码或字节码1类构造器clinit方法执行过程 1.1类构造器方法clinit方法是由 编译器自动收集类中的所有类变量的赋值动作和静态语句块static块中的语句合并产生的编译器收集顺序是由语句在源文件中出现的顺序决定的静态语句块中只能访问到定义在静态语句块之前的变量定义在它之后的变量在前面的静态语句块可以赋值但是不能访问public class Test {static {i 0;// System.out.println(i);// 编译器报错}static int i 1;// 静态语句块中只能访问到定义在静态语句块之前的变量// 定义在它之后的变量在前面的静态语句块可以赋值但是不能访问
} 1.2类构造器clinit方法与类的构造函数不同它不需要显式地调用父类构造器虚拟机会保证在子类的clinit方法执行之前父类的 clinit方法已经执行完毕。因此在虚拟机中第一个被执行的clinit方法的类肯定是 java.lang.Object1.3由于父类的clinit 方法先执行也就意味着父类中定义的静态语句块要优先于子类的变量赋值操作如下荔枝中字段B的值会是2而不是1public class ExecuteOrderTest {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);// output:2}
} 1.4clinit方法对于类或接口来说并不是必须的如果一个类中没有静态语句块也没有对变量的赋值操作那么编译器可以不为这个类生成 clinit 方法1.5接口中不能使用静态语句块但仍然有变量初始化的赋值操作因此接口与类一样都会生成 clinit() 方法。但接口与类不同的是执行接口的clinit 方法不需要先执行父接口的clinit 方法。只有当父接口中定义的变量使用时父接口才会初始化。另外接口的实现类在初始化时也不会执行接口的 clinit接口1.6虚拟机会保证一个类的 clinit() 方法在多线程环境中被正确地加锁同步如果多个线程同时去初始化一个类那么只会有一个线程去执行这个类的 clinit 方法其他线程都需要阻塞等待直到活动线程执行clinit() 方法执行完毕看个荔枝如果在一个类的clinit 方法中有耗时很长的操作就可能造成多个进程阻塞在实际应用中这种阻塞往往是很隐蔽的public class DeadLoopClass {static {if(true) {System.out.println(Thread.currentThread() init DeadLoopClass);while(true) {}}}public static void main(String[] args) {Runnable runnable new Runnable() {Overridepublic void run() {System.out.println(Thread.currentThread() start);DeadLoopClass dlc new DeadLoopClass();System.out.println(Thread.currentThread() run over);}};Thread thread1 new Thread(runnable);Thread thread2 new Thread(runnable);thread1.start();thread2.start();}
}【4】 类加载器1类加载器定义虚拟机设计团队把类加载阶段中的“通过一个类的全限定名来获取描述此类的二进制字节流”这个动作放到java虚拟机外部去实现以便让应用程序自己决定如何取获取所需要的类。实现这个动作的代码模块称为 类加载器【4.1】 类与类加载器1每一个类加载器都拥有一个独立的类名称空间。即比较两个类是否相等只有在这两个类是由同一个类加载器加载的前提下才有意义否则即使这两个类来源于同一个Class文件被同一个虚拟机加载只要加载它们的类加载器不同那这两个类就必定不相等干货——这里所说的相等包括代表类的Class对象的equals方法 isAssignableFrom()方法 isInstance()方法的返回结果也包括使用instanceof关键字做对象所属关系判定等情况。看个荔枝演示了不同类加载器对instanceof 关键字运算的结果的影响public class ClassLoaderTest {public static void main(String[] args) throws Exception {ClassLoader loader new ClassLoader() { // 自定义类加载器Overridepublic 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 (Exception e) {throw new ClassNotFoundException(name);} } };Object obj loader.loadClass(com.jvm.chapter7.ClassLoaderTest).newInstance();System.out.println(obj.getClass());System.out.println(obj instanceof com.jvm.chapter7.ClassLoaderTest);/*** outpub:* class com.jvm.chapter7.ClassLoaderTest* false*/}
} 对输出结果false的分析AnalysisA1因为虚拟机中存在两个ClassLoaderTest类一个是由系统应用程序类加载器加载的另外一个是由我们自定义的类加载器加载的虽然都来自同一个Class文件但依然是 两个独立的类做对象所属类型检查时结果自然为 false 【4.2】双亲委派模型1java虚拟机的角度讲只存在两种不同的类加载器1.1一种是启动类加载器Bootstrap ClassLoader这个类加载器使用C 语言实现1.2一种是所有其他的类加载器这些类加载器都由 java语言实现独立于虚拟机外部并且都继承自抽象类 java.lang.ClassLoader2从java开放人员角度看绝大部分java程序都会使用到以下3种系统提供的类加载器2.1启动类加载器这个类加载器将存放在 java_home/lib 目录中的或者被 -Xbootclasspath 参数所指定的路径中的并且使虚拟机识别的类库加载到虚拟机内存中启动类加载器无法被java 程序直接引用用户在编写自定义类加载器时如果需要把加载请求委派给引导类加载器那直接使用 null代替即可看个荔枝 展示了 java.lang.ClassLoader.getClassLoder() 方法的代码片段2.2扩展类加载器这个加载器由 sun.misc.Launcher$ExtClassLoader 实现它负责加载 java_home/lib/ext 目录中的或者被 java.ext.dirs 系统变量所指定的路径中的所有类库开发者可以直接使用扩展类加载器2.3应用程序类加载器系统类加载器这个类加载器由sun.misc.Launcher$AppClassLoader 实现。由于这个类加载器是ClassLoader 中的getSystemClassLoader() 方法的返回值所以一般也称它为系统类加载器。它负责加载用户类路径上所指定的类库开发者可以直接使用这个类加载器如果应用程序中没有自定义过自己的类加载器一般case下 这个就是程序中默认的类加载器3我们的应用程序都是由这3种类加载器相互配合进行加载的如果有必要还可以加入自定义的类加载器。类加载器间的关系如下所示对上图的分析AnalysisA1上图中的类加载器间的层次关系称为类加载器的双亲委派模型干货——双亲委派模式定义A2双亲委派模式要求除了顶层的启动类加载器外其余的类加载器都应当有自己的父类加载器。这里类加载器间的父子关系一般不会以继承的关系来实现而是使用 组合关系来复用父加载器的代码 4双亲委派模型的工作过程是 如果一个类加载器收到了类加载的请求它首先不会自己去尝试加载这个类而是把这个请求委派给父类加载器去完成每个层次的类加载器都是如此因此所有的加载请求最终都应该传送带到顶层的启动类加载器中只有当父加载器反馈自己无法完成这个加载请求时子加载器才会尝试自己去加载5双亲委派模式来组织类加载器的关系有一个好处 java 随着它的类加载器一起具备了一种带有优先级的层次关系。干货——双亲委派模式来组织类加载器的关系有一个好处5.1看个荔枝如java.lang.Object 它存放在 rt.jar中无论哪一个类加载器要加载这个类最终都是委派给处于模型最顶端的启动类加载器进行加载因此Object类在程序的各种类加载器环境中都是同一个类。相反如果没有使用双亲委派模型由各个类加载器自行去加载的话如果用户自己编写了一个java.lang.Object 的类并放在程序的ClassPath中那系统中将会出现多个不同的Object类java类型体系中最基础的行为也就无法保证了应用程序也将会变得一片混乱5.2 双亲委派模型的代码实现 实现双亲委派模型的代码都集中在 java.lang.ClassLoader 的 loadClass() 方法中如下面代码所示 先检查是否已经被加载过了 若没有加载则调用父加载器的 loadClass方法若父加载器为空则默认使用启动类加载器作为父加载器。如果父类加载失败抛出 ClassNotFoundException 异常后再调用自己的 findClass() 方法进行加载【4.3】破坏双亲委派模型1双亲委派模型主要出现过3次较大规模的被破坏情况case1第一次被破坏发生在双亲委派模型出现之前——即jdk1.2 发布之前。jdk1.2之后不提倡用户再去覆盖 loadClass() 方法 而应当把自己的类加载逻辑写到findClass方法中在loadClass方法的逻辑如果父类加载失败则会调用自己的findClass 方法来完成加载这样就可以保证新写出来的类加载器是符合双亲委派规则的case2第二次被破坏这次破坏是由这个模型自身的缺陷所导致的双亲委派很好地解决了各个类加载器的基础类的统一问题。problemsolutionproblem看个荔枝问题JNDI现在已经是java 的标准服务它的代码由启动类加载器去加载在jdk1.3中放进去的rt.jar但JNDI的目的就是对资源进行集中管理和查找它需要调用由独立厂商实现并部署在应用程序的 ClassPath 下的JNDI 接口提供者SPIservice provider interface的代码但启动类加载器不可能“认识”这些代码啊那该怎么办solution为了解决这个问题 java设计团队引入了线程上下文类加载器。线程上下文类加载器可以通过 java.lang.Thread 类的setContextClassLoader() 方法进行设置如果创建线程时还未设置它将会从父线程中继承一个如果在应用程序的全局范围内都没有设置过的话那这个类加载器默认就是 应用程序类加载器JNDI范围使用这个线程上下文类加载器 去加载所需要的SPI代码也就是父类加载器请求子类加载器去完成类加载的动作。干货——引入了线程上下文类加载器case3第三次被破坏是由于对程序动态性的追求而导致的这里所说的动态性指的是当前一些非常热门的名词代码热替换模块热部署等说白了就是希望应用程序能像我们的计算机外设那样接上鼠标不用重启机器就可以立即使用干货——引入程序动态性补充干货——引入OSGi1Sun 公司提出的JSR-294 JSR-277规范在于 JCP 组织的模块化规范之争中落败给 JSR-291即OSGI R4.2虽然Sun 不甘失去 java模块化的主导权独立在发展Jigsaw项目但目前 OSGi 已经成为 业界事实上的java 模块化标准而OSGi 实现模块化热部署的关键则是它自定义的类加载器机制的实现。每个程序模块化OSGI中称为 Bundle都有一个自己的类加载器当需要更换一个 Bundle时就把 Bundle连同类加载器一起换掉以实现代码的热替换2在OSGi 环境下类加载器不再是双亲委派模型中的树状结构而是进一步发展为更加复杂的网状结构当收到类加载请求时OSGi 将按照下面的顺序进行类搜索searchs1将以java.* 开头的类委派给父类加载器加载s2否则将委派列表名单内的类 委派给父类加载器加载s3否则将import 列表中的类委派给 Export这个类的 Bundle的类加载器加载s4否则查找当前Bundle的ClassPath使用自己的类加载器加载s5否则查找类是否在自己的 Fragment Bundle中如果在则委派给 Fragment Bundle的类加载器加载s6否则查找Dynamic Import 列表的Bundle委派给对应Bundle 的类加载器加载s7否则类查找失败 3consensus在java程序员中有一个共识OSGi 中对类加载器的使用是很值得学习的弄懂了OSGi 的实现就可以算是掌握了 类加载器的精髓干货——java程序员的共识
4intro to OSGi来自百度百科 :OSGi(Open Service Gateway Initiative)技术是Java动态化模块化系统的一系列规范。OSGi一方面指维护OSGi规范的OSGI官方联盟另一方面指的是该组织维护的基于Java语言的服务业务规范。简单来说OSGi可以认为是Java平台的模块层。OSGi服务平台向Java提供服务这些服务使Java成为软件集成和软件开发的首选环境。Java提供在多个平台支持产品的可移植性。OSGi技术提供允许应用程序使用精炼、可重用和可协作的组件构建的标准化原语。这些组件能够组装进一个应用和部署中。
