本文深入探讨了Java虚拟机的类加载机制，包括加载、验证、准备、解析和初始化五个阶段，以及类加载器的工作原理。重点介绍了双亲委派模型、符号引用到直接引用的解析过程，以及如何通过自定义类加载器打破双亲委派模型。此外，还讨论了类加载过程中的安全性和动态性需求。
学习导图:
类加载机制概述
定义： 虚拟机 把描述类的数据从Class文件加载到内存，并对数据进行校验、转换解析和初始化，最终形成可以被虚拟机直接使用的Java类型，这个过程被称作虚拟机的类加载机制特性： 运行期类加载。即Java语言里面，类型的加载、连接和初始化过程都是在程序运行期间完成的，从而通过牺牲一些性能开销来换取Java应用极高的的扩展性和灵活性。
什么是运行期，什么是编译期？
编译期是指编译器将源代码翻译为机器能识别的代码，Java被编译为Jvm认识的字节码文件，而运行期则是指Java代码的运行过程。
类加载机制时机
一个类型从被加载到虚拟机内存中开始，到卸载出内存为止，它的整个生命周期将会经历 加载（Loading） 、 验证（Verification）、准备（ Preparation）、解析（Resolution）、初始化（Initialization）、使用（Using）和卸载（Unloading）七个阶段，其中验证、准备、解析三个部分统称为连接（Linking）。
类的生命周期
加载、验证、准备、初始化和卸载 这五个阶段的 顺序是确定的，类型的加载过程必须按照这种顺序按部就班地开始 ，而解析阶段则不一定：它在某些情况下可以在初始化阶段之后再开始，这是为了支持Java语言的 运行时绑定特性 （也称为 动态绑定或晚期绑定 ）。注意： 按部就班地“开始”，而不是按部就班地“进行”或按部就班地“完成”，强调这点是因为这些阶段通常都是互相交叉地混合进行的，会在一个阶段执行的过程中调用、激活另一个阶段。
类加载过程中的第一个阶段："加载"，Java虚拟机并没有进行强制约束，而是交给虚拟机的具体实现来自由把握。但是对于初始化阶段，虚拟机则是严格规定了有且只有六种情况必须立即对类进行“初始化”（而加载、验证、准备自然需要在此之前开始):
需要特别指出的是，类的实例化和类的初始化是两个完全不同的概念：
- 类的实例化是指创建一个类的实例(对象)的过程；
- 类的初始化是指为类各个成员赋初始值的过程，是类生命周期中的一个阶段。
被动引用常见示例：
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);}}
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) {SuperClass[] sca = new SuperClass[10];}}
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{}” 语句块，但编译器仍然会为接口生成 “<clinit>()”类构造器 ，用于初始化接口中所定义的成员变量。接口与类真正有所区别的是前面讲述的六种“ 有且仅有 ” 需要触发初始化场景中的第三种： 当一个类在初始化时，要求其父类全部都已经初始化过了，但是一个接口在初始化时，并不要求其父接口全部都完成了初始化，只有在真正使用到父接口的时候（如引用接口中定义的常量）才会初始化。
类加载的过程
在类的加载时机中，我们已经通过图看到了类的生命周期，也即类的加载过程。接下来主要了解一下JVM在加载、验证、准备、解析和初始化五个阶段所执行的具体动作。
加载
“加载”（Loading）阶段是整个“类加载”（Class Loading）过程中的一个阶段，在加载阶段，Java虚拟机需要完成以下三件事情：
- 通过一个类的全限定名来获取定义此类的二进制字节流。
- 将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构。
- 在内存中生成一个代表这个类的java.lang.Class对象，作为方法区这个类的各种数据的访问入口。
- 从ZIP压缩包中读取，这很常见，最终成为日后JAR、EAR、WAR格式的基础。
- 从网络中获取，这种场景最典型的应用就是Web Applet。
- 运行时计算生成，这种场景使用得最多的就是动态代理技术，在java.lang.reflect.Proxy中，就是用了ProxyGenerator.generateProxyClass()来为特定接口生成形式为“*$Proxy”的代理类的二进制字节流。
- 由其他文件生成，典型场景是JSP应用，由JSP文件生成对应的Class文件。
- 从数据库中读取，这种场景相对少见些，例如有些中间件服务器（如SAP Netweaver）可以选择把程序安装到数据库中来完成程序代码在集群间的分发。
- 可以从加密文件中获取，这是典型的防Class文件被反编译的保护措施，通过加载时解密Class文件来保障程序运行逻辑不被窥探。
- ...........等等方式获取
- 如果数组的组件类型是引用类型，那就递归采用本节中定义的加载过程去加载这个组件类型，数组C将被标识在加载该组件类型的类加载器的类名称空间上。
- 如果数组的组件类型不是引用类型（例如int[]数组的组件类型为int），Java虚拟机将会把数组C标记为与引导类加载器关联。
- 数组类的可访问性与它的组件类型的可访问性一致，如果组件类型不是引用类型，它的数组类的 可访问性将默认为public，可被所有的类和接口访问到。
验证
验证阶段大致上会完成下面四个阶段的检验动作：文件格式验证、元数据验证、字节码验证和符号引用验证。
文件格式验证
- 是否以魔数0xCAFEBABE开头。
- 主、次版本号是否在当前Java虚拟机接受范围之内。
- 常量池的常量中是否有不被支持的常量类型（检查常量tag标志）。
- 指向常量的各种索引值中是否有指向不存在的常量或不符合类型的常量。
- CONSTANT_Utf8_info型的常量中是否有不符合UTF-8编码的数据。
- Class文件中各个部分及文件本身是否有被删除的或附加的其他信息。
- ……等等规则
元数据验证
- 这个类是否有父类（除了java.lang.Object之外，所有的类都应当有父类）。
- 这个类的父类是否继承了不允许被继承的类（被final修饰的类）。
- 如果这个类不是抽象类，是否实现了其父类或接口之中要求实现的所有方法。
- 类中的字段、方法是否与父类产生矛盾（例如覆盖了父类的final字段，或者出现不符合规则的方法重载，例如方法参数都一致，但返回值类型却不同等）。
- ……等等规则
字节码验证
- 保证任意时刻操作数栈的数据类型与指令代码序列都能配合工作，例如不会出现类似于“在操作栈放置了一个int类型的数据，使用时却按long类型来加载入本地变量表中”这样的情况。
- 保证任何跳转指令都不会跳转到方法体以外的字节码指令上。
- 保证方法体中的类型转换总是有效的，例如可以把一个子类对象赋值给父类数据类型，这是安全的，但是把父类对象赋值给子类数据类型，甚至把对象赋值给与它毫无继承关系、完全不相干的一个数据类型，则是危险和不合法的。
- ……等等
符号引用验证
- 符号引用中通过字符串描述的全限定名是否能找到对应的类。
- 在指定类中是否存在符合方法的字段描述符及简单名称所描述的方法和字段。
- 符号引用中的类、字段、方法的可访问性（private、protected、public、<package>）是否可被当前类访问。
- ……等等
准备
public static int value = 123;
上述基本数据类型在“通常情况”下初始值是零值，那言外之意是相对的会有某些“特殊情况”：如果类字段的字段属性表中存在ConstantValue属性，那在准备阶段变量值就会被初始化为ConstantValue属性所指定的初始值，假设上面类变量value的定义修改为：
public static final int value = 123;
ConstantValue属性在类加载过程的准备阶段做的事情是什么？
在编译时Javac将会为被static和final修改的常量生成ConstantValue属性(此时ConstantValue属性的值是多少，暂时不知道，)，在类加载的准备阶段虚拟机便会根据ConstantValue为常量设置相应的值（这个值是什么意思呢，比如我们在程序中定义final static int a = 100，那么这个a就是ConstantValue属性，然后在准备阶段中a的值就会变成100），这就是ConstantValue属性在类加载过程的准备阶段做的事
解析
- 符号引用（Symbolic References）：符号引用以一组符号来描述所引用的目标，符号可以是任何形式的字面量，只要使用时能无歧义地定位到目标即可。符号引用与虚拟机实现的内存布局无关，引用的目标并不一定是已经加载到虚拟机内存当中的内容。各种虚拟机实现的内存布局可以各不相同，但是它们能接受的符号引用必须都是一致的，因为符号引用的字面量形式明确定义在《Java虚拟机规范》的Class文件格式中。
- 直接引用（Direct References）：直接引用是可以直接指向目标的指针、相对偏移量或者是一个能间接定位到目标的句柄。直接引用是和虚拟机实现的内存布局直接相关的，同一个符号引用在不同虚拟机实例上翻译出来的直接引用一般不会相同。如果有了直接引用，那引用的目标必定已经在虚拟机的内存中存在。
对同一个符号进行多次解析请求是很常见的，除了invokedynamic指令以外，虚拟机基本都会对第一次解析的结果进行缓存，后面再遇到时，直接引用，从而避免解析动作重复。
对于invokedynamic指令，上面规则不成立。当遇到前面已经由invokedynamic指令触发过解析的符号引用时，并不意味着这个解析结果对于其他invokedynamic指令同样生效。这是由invokedynamic指令的语义决定的，它本来就是用于动态语言支持的，也就是必须等到程序实际运行这条指令的时候，解析动作才会执行。其它的命令都是“静态”的，可以再刚刚完成记载阶段，还没有开始执行代码时就解析。
- 如果C不是一个数组类型，那虚拟机将会把代表N的全限定名传递给D的类加载器去加载这个类C。在加载过程中，由于元数据验证、字节码验证的需要，又可能触发其他相关类的加载动作，例如加载这个类的父类或实现的接口。一旦这个加载过程出现了任何异常，解析过程就将宣告失败。
- 如果C是一个数组类型，并且数组的元素类型为对象，也就是N的描述符会是类似“[Ljava/lang/Integer”的形式，那将会按照第一点的规则加载数组元素类型。如果N的描述符如前面所假设的形式，需要加载的元素类型就是“java.lang.Integer”，接着由虚拟机生成一个代表该数组维度和元素的数组对象。
- 如果上面两步没有出现任何异常，那么C在虚拟机中实际上已经成为一个有效的类或接口了，但在解析完成前还要进行符号引用验证，确认D是否具备对C的访问权限。如果发现不具备访问权限，将抛出java.lang.IllegalAccessError异常。
- 被访问类C是public的，并且与访问类D处于同一个模块。
- 被访问类C是public的，不与访问类D处于同一个模块，但是被访问类C的模块允许被访问类D的模块进行访问。
- 被访问类C不是public的，但是它与访问类D处于同一个包中
- 如果C本身就包含了简单名称和字段描述符都与目标相匹配的字段，则返回这个字段的直接引用，查找结束。
- 否则，如果在C中实现了接口，将会按照继承关系从下往上递归搜索各个接口和它的父接口， 如果接口中包含了简单名称和字段描述符都与目标相匹配的字段，则返回这个字段的直接引用，查找结束。
- 否则，如果C不是java.lang.Object的话，将会按照继承关系从下往上递归搜索其父类，如果在父类中包含了简单名称和字段描述符都与目标相匹配的字段，则返回这个字段的直接引用，查找结束。
- 否则，查找失败，抛出java.lang.NoSuchFieldError异常。
//字段解析package org.fenixsoft.classloading;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;}public static void main(String[] args) {System.out.println(Sub.A);}}
- 由于Class文件格式中类的方法和接口的方法符号引用的常量类型定义是分开的，如果在类的方法表中发现class_index中索引的C是个接口的话，那就直接抛出java.lang.IncompatibleClassChangeError异常。
- 如果通过了第一步，在类C中查找是否有简单名称和描述符都与目标相匹配的方法，如果有则返回这个方法的直接引用，查找结束。
- 否则，在类C的父类中递归查找是否有简单名称和描述符都与目标相匹配的方法，如果有则返回这个方法的直接引用，查找结束。
- 否则，在类C实现的接口列表及它们的父接口之中递归查找是否有简单名称和描述符都与目标相匹配的方法，如果存在匹配的方法，说明类C是一个抽象类，这时候查找结束，抛出java.lang.AbstractMethodError异常。
- 否则，宣告方法查找失败，抛出java.lang.NoSuchMethodError
- 与类的方法解析相反，如果在接口方法表中发现class_index中的索引C是个类而不是接口，那么就直接抛出java.lang.IncompatibleClassChangeError异常。
- 否则，在接口C中查找是否有简单名称和描述符都与目标相匹配的方法，如果有则返回这个方法的直接引用，查找结束。
- 否则，在接口C的父接口中递归查找，直到java.lang.Object类（接口方法的查找范围也会包括Object类中的方法）为止，看是否有简单名称和描述符都与目标相匹配的方法，如果有则返回这个方法的直接引用，查找结束。
- 对于规则3，由于Java的接口允许多重继承，如果C的不同父接口中存有多个简单名称和描述符都与目标相匹配的方法，那将会从这多个方法中返回其中一个并结束查找，《Java虚拟机规范》中并没有进一步规则约束应该返回哪一个接口方法。但与之前字段查找类似地，不同发行商实现的Javac编译器有可能会按照更严格的约束拒绝编译这种代码来避免不确定性。
- 否则，宣告方法查找失败，抛出java.lang.NoSuchMethodError异常。
初始化
初始化是类加载的最后一步，在前面的阶段里，除了加载阶段可以通过用户自定义的类加载器加载，其余部分基本都是由虚拟机主导的。但是到了初始化阶段，才开始真正执行用户编写的java代码了。
在准备阶段，变量都被赋予了初始值，但是到了初始化阶段，所有变量还要按照用户编写的代码重新初始化。换一个角度，初始化阶段是执行类构造器<clinit>()方法的过程。<clinit>()方法是由编译器自动收集类中的所有类变量的赋值动作和静态语句块(static语句块)中的语句合并生成的，编译器收集的顺序是由语句在源文件中出现的顺序决定的，静态语句块中只能访问到定义在静态语句块之前的变量，定义在它之后的变量，在前面的静态语句块中可以赋值，但是不能访问。如下面示例：
//非法前向引用变量public class Test {static {i = 0; // 给变量复制可以正常编译通过System.out.print(i); // 这句编译器会提示“非法向前引用”}static int i = 1;}
// <clinit>() 方法执行顺序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);}
static class DeadLoopClass {static {// 如果不加上这个if 语句，编译器将提示 “Initializer does not complete normally” 并拒绝编译if (true) {System.out.println(Thread.currentThread() + "init DeadLoopClass");while (true) {}}}}public static void main(String[] args) {Runnable script = new Runnable() {public void run() {System.out.println(Thread.currentThread() + "start");DeadLoopClass dlc = new DeadLoopClass();System.out.println(Thread.currentThread() + " run over");}};Thread thread1 = new Thread(script);Thread thread2 = new Thread(script);thread1.start();thread2.start();}运行结果如下，一条线程在死循环以模拟长时间操作，另外一条线程在阻塞等待：Thread[Thread-0,5,main]startThread[Thread-1,5,main]startThread[Thread-0,5,main]init DeadLoopClass
类加载器
概念
类与类加载器
/*** 类加载器与 instanceof关键字演示---- 不同的类加载器对instanceof关键字运算的结果的影响** @author zzm*/public class ClassLoaderTest {public static void main(String[] args) throws Exception {ClassLoader myLoader = 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 (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.ClassLoaderTestfalse
双亲委派模型
- 一种是启动类加载器（Bootstrap ClassLoader），这个类加载器使用C++语言实现，是虚拟机自身的一部分；
- 用户自定义类加载器(User-Defined Class Loader)： Java语言实现，独立存在于虚拟机外部，并且全都继承自抽象类java.lang.ClassLoader。
双亲委派模型图
- 启动类加载器（Bootstrap Class Loader）：这个类加载器负责加载存放在<JAVA_HOME>\lib目录，或者被-Xbootclasspath参数所指定的路径中存放的，而且是Java虚拟机能够识别的（按照文件名识别，如rt.jar、tools.jar，名字不符合的类库即使放在lib目录中也不会被加载）类库加载到虚拟机的内存中。启动类加载器无法被Java程序直接引用，用户在编写自定义类加载器时，如果需要把加载请求委派给引导类加载器去处理，那直接使用null代替即可。
- 扩展类加载器（Extension Class Loader）：这个类加载器是在类sun.misc.Launcher$ExtClassLoader中以Java代码的形式实现的。它负责加载<JAVA_HOME>\lib\ext目录中，或者被java.ext.dirs系统变量所指定的路径中所有的类库。
- 应用程序类加载器（Application Class Loader）：这个类加载器由sun.misc.Launcher$AppClassLoader来实现。由于应用程序类加载器是ClassLoader类中的getSystem-ClassLoader()方法的返回值，所以有些场合中也称它为“系统类加载器”。它负责加载用户类路径（ClassPath）上所有的类库，开发者同样可以直接在代码中使用这个类加载器。如果应用程序中没有自定义过自己的类加载器，一般情况下这个就是程序中默认的类加载器。
双亲委派模型要求除了顶层的Bootstrap ClassLoader外，其它所有类加载器都要有自己的父类加载器。这里的父子关系一般不会议继承实现，而是通过组合实现。
重点来了，为什么要使用双亲委派机制呢？
如果面试官问这个问题，一定要答出关键字：安全性。
反证法来辩证。假设不采用双亲委派机制，那我可以自定义一个类加载器，然后我写一个java.lang.String类用自定义的类加载器加载进去，原来java本身又有一个java.lang.String类，那么类的唯一性就没法保证，就不就给虚拟机的安全带来的隐患了吗。所以要保证一个类只能由同一个类加载器加载，才能保证系统类的的安全。
以下摘自JVM第三版电子书：
使用双亲委派模型来组织类加载器之间的关系，一个显而易见的好处就是 Java 中的类随着它的类加载器一起具备了一种带有优先级的层次关系。例如类java.lang.Object ，它存放在 rt.jar 之中，无论哪一个类加载器要加载这个类，最终都是委派给处于模型最顶端的启动类加载器进行加载，因此Object 类在程序的各种类加载器环境中都能够保证是同一个类。反之，如果没有使用双亲委派模型，都由各个类加载器自行去加载的话，如果用户自己也编写了一个名为java.lang.Object 的类，并放在程序的ClassPath中，那系统中就会出现多个不同的 Object 类， Java 类型体系中最基础的行为也就无从保证，应用程序将会变得一片混乱。
双亲委派模型的实现
protected Class<?> loadClass(String name, boolean resolve) throws ClassNotFoundException{
synchronized (getClassLoadingLock(name)) {
// 首先，检查请求的类是否已经被加载过了
Class<?> c = findLoadedClass(name);
if (c == null) {//没加载过的情况
long t0 = System.nanoTime();
try {
if (parent != null) {
//如果自定义的类加载器的parent不为null,就调用parent的loadClass进行加载类
c = parent.loadClass(name, false);
} else {
//否则就去找bootstrap ClassLoader
c = findBootstrapClassOrNull(name);
}
} catch (ClassNotFoundException e) {
// 如果父类加载器抛出ClassNotFoundException ,说明父类加载器无法完成加载请求
}if (c == null) {
// 在父类加载器无法加载时,再调用本身的findClass方法来进行类加载long t1 = System.nanoTime();
c = findClass(name);
sun.misc.PerfCounter.getParentDelegationTime().addTime(t1 - t0);
sun.misc.PerfCounter.getFindClassTime().addElapsedTimeFrom(t1);
sun.misc.PerfCounter.getFindClasses().increment();
}
}
if (resolve) {
resolveClass(c);
}
return c;
}
}
自定义类加载器
一般来说，自己开发的类加载器只需要覆写findClass(String name)方法即可。java.lang.ClassLoader类的方法loadClass()封装了双亲委派模型的实现。该方法会首先调用findLoadedClass()方法来检查该类是否已经被加载过；如果没有加载过的话，会调用父类加载器的 loadClass()方法来尝试加载该类；如果父类加载器无法加载该类的话，就调用findClass()方法来查找该类。因此，为了保证类加载器都正确实现代理模式，在开发自己的类加载器时，最好不要覆写 loadClass()方法，而是覆写findClass()方法。
被自定义加载器UserClassLoader调用的类方法：
package com.springboot.aop;
public class TestUserClassLoader {
public void hello() {
System.out.println("this is myUserClassLoader....");
}
}自定义类加载器UserClassLoader：
package com.springboot.aop;
import java.io.ByteArrayOutputStream;
import java.io.File;
import java.io.FileInputStream;
import java.io.IOException;
import java.io.InputStream;
import java.lang.reflect.Method;
public class UserClassLoader extends ClassLoader {
private String path;
public UserClassLoader(String path) {
this.path = path;
}
/**
* 编写findClass方法的逻辑
* @param name
* @return
* @throws ClassNotFoundException
*/
@Override
protected Class<?> findClass(String name) throws ClassNotFoundException {
// 获取类的class文件字节数组
byte[] classData = getClassData(name);
if (classData == null) {
throw new ClassNotFoundException();
} else {
//直接生成class对象
return defineClass(name, classData, 0, classData.length);
}
}
/**
* 编写获取class文件并转换为字节码流的逻辑
* @param className
* @return
*/
private byte[] getClassData(String className) {
// 读取类文件的字节
String path = classNameToPath(className);
try {
InputStream ins = new FileInputStream(path);
ByteArrayOutputStream baos = new ByteArrayOutputStream();
int bufferSize = 4096;
byte[] buffer = new byte[bufferSize];
int bytesNumRead = 0;
// 读取类文件的字节码
while ((bytesNumRead = ins.read(buffer)) != -1) {
baos.write(buffer, 0, bytesNumRead);
}
return baos.toByteArray();
} catch (IOException e) {
e.printStackTrace();
}
return null;
}
/**
* 类文件的完全路径
* @param className
* @return
*/
private String classNameToPath(String className) {
return path + File.separatorChar + className.replace('.', File.separatorChar) + ".class";
}
public static void main(String[] args) throws ClassNotFoundException {
String path="D:\\tz\\test\\springboot-helloword\\target\\classes\\com\\springboot\\aop";
//创建自定义文件类加载器
UserClassLoader loader = new UserClassLoader(path);
try {
//加载指定的class文件
Class<?> clazz=loader.loadClass("com.springboot.aop.TestUserClassLoader");
System.out.println("使用类加载器：" + clazz.getClassLoader());
Method method = clazz.getDeclaredMethod("hello");
Object obj = clazz.newInstance();
method.invoke(obj);
} catch (Exception e) {
e.printStackTrace();
}
}
}
控制台输出结果：
使用类加载器：sun.misc.Launcher$AppClassLoader@2a139a55
this is myUserClassLoader....
另外一种加载类的方法：Class.forName
Class.forName是一个静态方法，同样可以用来加载类。该方法有两种形式：Class.forName(String name, boolean initialize, ClassLoader loader)和 Class.forName(String className)。第一种形式的参数 name表示的是类的全名；initialize表示是否初始化类；loader表示加载时使用的类加载器。第二种形式则相当于设置了参数initialize的值为true，loader的值为当前类的类加载器。Class.forName的一个很常见的用法是在加载数据库驱动的时候。如 Class.forName("org.apache.derby.jdbc.EmbeddedDriver").newInstance()用来加载 Apache Derby 数据库的驱动。
破坏双亲委派
1、重写loadClass()方法,前面说过java.lang.ClassLoader类的方法loadClass()封装了双亲委派模型的实现。如果被子类重写loadClass()，很容易破坏身亲委派机制。
2、双亲委派模型的第二次“被破坏”是由这个模型自身的缺陷导致的，双亲委派很好地解决了各个类 加载器协作时基础类型的一致性问题（越基础的类由越上层的加载器进行加载），基础类型之所以被 称为“基础”，是因为它们总是作为被用户代码继承、调用的API存在，但程序设计往往没有绝对不变 的完美规则，如果有基础类型又要调用回用户的代码，那该怎么办呢？
双亲委派机制就是底层的类加载器一直委托上层的类加载器，如果上层的已经加载了，就无需加载，上层的类加载器没有加载则自己加载。这就突出了双亲委派机制的一个缺陷，就是只能子的类加载器委托父的类加载器，不能反过来用父的类加载器委托子的类加载器。
那你会问，什么情况会出现父的类加载器委托子的类加载器呢？
案例一：
加载JDBC的数据库驱动。在JDK中有一个所有 JDBC 驱动程序需要实现的接口Java.sql.Driver。而Driver接口的实现类则是由各大数据库厂商提供。那问题就出现了，DriverManager(JDK的rt.jar包中)要加载各个实现了Driver接口的实现类，然后进行统一管理，但是DriverManager是由Bootstrap类加载器加载的，只能加载JAVA_HOME下lib目录下的文件(可以看回上面双亲委派机制的第一张图)，但是实现类是服务商提供的，由AppClassLoader加载，这就需要Bootstrap(上层类加载器)委托AppClassLoader(下层类加载器)，也就破坏了双亲委派机制
案例二：
JNDI服务， JNDI 现在已经是 Java 的标准服务，它的代码由启动类加载器来完成加载（在JDK 1.3 时加入到 rt.jar 的），肯定属于 Java 中很基础的类型了。但JNDI 存在的目的就是对资源进行查找和集中管理，它需要调用由其他厂商实现并部署在应用程序的ClassPath 下的 JNDI 服务提供者接口（Service Provider Interface ， SPI ）的代码，现在问题来了，启动类加载器是绝不可能认识、加载这些代码的。
扫一扫
9034
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
