java中类加载过程,java类加载机制使用什么模型

　　00-1010 1.导言2。类加载的时机2.1类加载过程2.2类初始化时2.3被动引用不会初始化3。类加载流程3.1加载3.2验证3.3准备3.4解析3.5初始化4。父类和子类初始化中的执行顺序5。类加载器5.1类和类加载器5.2父母委托模型5.3打破父母委托模型6。Java模块化系统

　　一般来说，当你更新一个对象时，你必须首先确保新对象的类已经被加载到内存中。问题来了，为什么一定要加载到内存里？当我们写程序的时候，我们没有说一个新的对象必须被添加到内存中。原因是JVM自带了类加载器的功能，也就是我们新的时候会判断内存中是否有这个类class。如果有，我们不需要加载它。如果没有，类加载器将自动加载并读取类文件到内存中。所以，不深入研究，根本无法感知类加载器的作用。

　　在Java语言中，类型加载、连接和初始化的过程都是在程序运行过程中完成的。这种策略使得Java语言很难提前编译，并且在加载类时也增加了一些性能开销。然而，它为Java应用程序提供了极高的可伸缩性和灵活性。Java动态扩展的自然语言特性是通过运行时动态加载和动态连接的特性来实现的。

　　例如，要编写面向接口的应用程序，可以等到运行时再指定其实际的实现类。从最基础的Applet和JSP到相对复杂的OSGi技术，都是依靠Java语言运行时类加载才能诞生的。

一、前言

　　00-1010一个类型的整个生命周期会经历加载、验证、准备、解析、初始化、使用、解链接七个阶段，其中验证。这七个阶段的顺序如下图所示。

　　加载、验证、准备、初始化和卸载这五个阶段的顺序是确定的。一个类型的加载过程必须按照这个顺序一步一步开始，而解析阶段不一定：在某些情况下可以在初始化阶段之后开始，这是为了支持Java语言的运行时绑定特性(也叫动态绑定或后期绑定)。

二、类加载的时机

《Java虚拟机规范》中关于类加载过程的第一阶段“加载”需要在什么时候开始没有强制约束，可以由虚拟机的具体实现自由把握。但对于初始化阶段，《Java虚拟机规范》严格规定只有6种情况下类必须立即“初始化”(而加载、验证、准备自然需要在此之前开始):

　　1.在遇到new、getstatic、putstatic或invokestatic这四个字节码指令时，如果类型还没有初始化，就需要先触发它的初始化阶段。可以生成这四条指令的典型Java代码场景是：

　　用new关键字实例化一个对象时。当读取或设置一个类型的静态字段时(除了final修饰的静态字段，结果已经在编译时放入常量池)。当调用某个类型的静态方法时。

　　2.使用java.lang.reflect包的方法对类型进行反射调用时，如果该类型尚未初始化，则需要先触发其初始化。

　　3.初始化一个类时，如果发现其父类还没有初始化，需要先触发其父类的初始化。

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

　　5.在使用JDK 7新增的动态语言支持时，如果一个java.lang.invoke.MethodHandle实例的最终解析结果是四种类型的方法语句句柄，即REF_getStatic、REF_invokeStatic、REF_newInvokeSpecial，并且该方法句柄对应的类还没有初始化，则需要先触发其初始化。

　　6.在一个接口中定义JDK 8新增加的默认方法(default关键字修饰的接口方法)时，如果这个接口的实现类被初始化，那么这个接口应该在它之前被初始化。

　　这六种情况下的行为称为对类型的主动引用。

　　00-1010此外，所有参考类型的当事人

　　式都不会触发初始化，称为被动引用。下面举三个例子来说明何为被动引用。

　　代码示例一：

package org.fenixsoft.classloading;/** * 被动使用类字段演示一： * 通过子类引用父类的静态字段，不会导致子类初始化 */public class SuperClass { static { System.out.println("父类 init!"); } public static int value = 123;}class SubClass extends SuperClass { static { System.out.println("子类 init!"); }}/** * 非主动使用类字段演示 */class NotInitialization { public static void main(String[] args) { System.out.println(SubClass.value); }}

上述代码运行之后，只会输出父类 init！，而不会输出子类 init！。

　　得出结论：访问静态属性的时候，不管是通过子类还是父类来访问这个静态属性，只有静态属性所呆的类会被初始化。至于是否要触发子类的加载和验证阶段，在《Java虚拟机规范》中并未明确规定。

　　代码示例二：

/** * 被动使用类字段演示二： * 通过数组定义来引用类，不会触发此类的初始化 */class NotInitialization { public static void main(String[] args) { SuperClass[] sca = new SuperClass[10]; }}

为了节省版面，这段代码复用了代码示例一的SuperClass，运行之后发现没有输出父类 init！，说明并没有触发类org.fenixsoft.classloading.SuperClass的初始化阶段。

　　但是这段代码里面触发了另一个名为[Lorg.fenixsoft.classloading.SuperClass的类的初始化阶段，对于用户代码来说，这并不是一个合法的类型名称，它是一个由虚拟机自动生成的、直接继承于java.lang.Object的子类，创建动作由字节码指令newarray触发。

　　这个类代表了一个元素类型为org.fenixsoft.classloading.SuperClass的一维数组，数组中应有的属性和方法（用户可直接使用的只有被修饰为public的length属性和clone()方法）都实现在这个类里。Java语言中对数组的访问要比C/C++相对安全，很大程度上就是因为这个类包装了数组元素的访问。

　　代码示例三：

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

上述代码运行之后，也没有输出ConstClass init！，原因是常量在编译阶段存入了常量池，已经彻底和类脱离了关系，也就是常量和类的关系在编译成 Class文件后就已不存在任何联系了。常量已经不再属于这个类。

　　接口的加载过程与类加载过程稍有不同，针对接口需要做一些特殊说明：接口也有初始化过程，这点与类是一致的，上面的代码都是用静态语句块static{}来输出初始化信息的，而接口中不能使用static{}语句块，但编译器仍然会为接口生成<clinit>()类构造器，用于初始化接口中所定义的成员变量。接口与类真正有所区别的是前面讲述的六种有且仅有需要触发初始化场景中的第三种：当一个类在初始化时，要求其父类全部都已经初始化过了，但是一个接口在初始化时，并不要求其父接口全部都完成了初始化，只有在真正使用到父接口的时候（如引用接口中定义的常量）才会初始化（被default关键字修饰的接口方法这种情况除外）。

三、类加载的过程

接下来我们会详细了解Java虚拟机中类加载的全过程，即加载、验证、准备、解析和初始化这五个阶段所执行的具体动作。

3.1 加载

加载（Loading）阶段是整个类加载（Class Loading）过程中的一个阶段，希望读者没有混淆这两个看起来很相似的名词。在加载阶段，Java虚拟机需要完成以下三件事情：

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

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

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

　　通过一个类的全限定名来获取定义此类的二进制字节流这条规则，它并没有指明二进制字节流必须得从某个Class文件中获取，确切地说是根本没有指明要从哪里获取、如何获取。许多举足轻重的Java技术都建立在这一基础之上，例如：

　　1.从ZIP压缩包中读取，这很常见，最终成为日后JAR、EAR、WAR格式的基础。

　　2.运行时计算生成，这种场景使用得最多的就是动态代理技术，在java.lang.reflect.Proxy中，就是用了ProxyGenerator.generateProxyClass()来为特定接口生成形式为*$Proxy的代理类的二进制字节流。

　　3.由其他文件生成，典型场景是JSP应用，由JSP文件生成对应的Class文件。

　　4.可以从加密文件中获取，这是典型的防Class文件被反编译的保护措施，通过加载时解密Class文件来保障程序运行逻辑不被窥探。

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

　　对于数组类而言，情况就有所不同，数组类本身不通过类加载器创建，它是由Java虚拟机直接在内存中动态构造出来的。但数组类与类加载器仍然有很密切的关系，因为数组类的元素类型最终还是要靠类加载器来完成加载，一个数组类（下面简称为C）创建过程遵循以下规则：

　　1.如果数组的组件类型是引用类型，那就递归采用本节中定义的加载过程去加载这个组件类型，数组C将被标识在加载该组件类型的类加载器的类名称空间上。

　　2.如果数组的组件类型不是引用类型（例如int[]数组的组件类型为int），Java虚拟机将会把数组C 标记为与引导类加载器关联。

　　加载阶段与连接阶段的部分动作（如一部分字节码文件格式验证动作）是交叉进行的，加载阶段尚未完成，连接阶段可能已经开始，但这些夹在加载阶段之中进行的动作，仍然属于连接阶段的一部分，这两个阶段的开始时间仍然保持着固定的先后顺序。

3.2 验证

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

　　编译器验证： Java语言本身是相对安全的编程语言（起码对于C/C++来说是相对安全的），将一个对象转型为它并未实现的类型、跳转到不存在的代码行之类的事情，如果尝试这样去做了，编译器会毫不留情地抛出异常、拒绝编译。

　　字节码验证： 但前面也曾说过， Class文件并不一定只能由Java源码编译而来，Java代码无法做到的事情在字节码层面上都是可以实现的，至少语义上是可以表达出来的。Java虚拟机如果不检查输入的字节流，对其完全信任的话，很可能会因为载入了有错误或有恶意企图的字节码流而导致整个系统受攻击甚至崩溃，所以验证字节码是Java虚拟机保护自身的一项必要措施。

　　验证阶段的工作量在虚拟机的类加载过程中占了相当大的比重。验证阶段大致上会完成下面四个阶段的检验动作：文件格式验证、元数据验证、字节码验证和符号引用验证。

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

　　元数据验证：这个阶段可能包括的验证点如下（内容比较多，只列了以下几点）：

　　1.这个类是否有父类（除了java.lang.Object之外，所有的类都应当有父类）。

　　2.这个类的父类是否继承了不允许被继承的类（被final修饰的类）。

　　3.如果这个类不是抽象类，是否实现了其父类或接口之中要求实现的所有方法。

　　字节码验证：第三阶段是整个验证过程中最复杂的一个阶段，主要目的是通过数据流分析和控制流分析，确定程序语义是合法的、符合逻辑的。

　　符号引用验证：主要作用是验证该类是否缺少或者被禁止访问它依赖的某些外部类、方法、字段等资源。类、字段、方法的可访问性（private、protected、public、）是否可被当前类访问。

　　如果程序运行的全部代码（包括自己编写的、第三方包中的、从外部加载的、动态生成的等所有代码）都已经被反复使用和验证过，在生产环境的实施阶段就可以考虑使用-Xverify:none参数来关闭大部分的类验证措施，以缩短虚拟机类加载的时间。

3.3 准备

准备阶段是正式为类中定义的变量（即静态变量，被static修饰的变量）分配内存并设置类变量初始值的阶段，从概念上讲，这些变量所使用的内存都应当在方法区中进行分配，但必须注意到方法区本身是一个逻辑上的区域，在JDK 7及之前，HotSpot使用永久代来实现方法区时，实现是完全符合这种逻辑概念的；而在JDK 8及之后，类变量则会随着Class对象一起存放在Java堆中。

　　关于准备阶段，还有两个容易产生混淆的概念笔者需要着重强调，首先是这时候进行内存分配的仅包括类变量，而不包括实例变量，实例变量将会在对象实例化时随着对象一起分配在Java堆中。其次是这里所说的初始值通常情况下是数据类型的零值，假设一个类变量的定义为：

public static int value = 123;

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

3.4 解析

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

　　符号引用（Symbolic References）：符号引用以一组符号来描述所引用的目标，符号可以是任何形式的字面量，只要使用时能无歧义地定位到目标即可直接引用（Direct References）：直接引用是可以直接指向目标的指针、相对偏移量或者是一个能间接定位到目标的句柄符号引用与虚拟机实现的内存布局无关，直接引用是和虚拟机实现的内存布局直接相关的，同一个符号引用在不同虚拟机实例上翻译出来的直接引用一般不会相同。

　　如果有了直接引用，那引用的目标必定已经在虚拟机的内存中存在。

　　解析动作主要针对类或接口、字段、类方法、接口方法、方法类型、方法句柄和调用点限定符这7类符号引用进行

　　符号引用要转换成直接引用才有效，这也说明直接引用的效率要比符号引用高。那为什么要用符号引用呢？这是因为类加载之前，javac会将源代码编译成.class文件，这个时候javac是不知道被编译的类中所引用的类、方法或者变量他们的引用地址在哪里，所以只能用符号引用来表示。

3.5 初始化

类的初始化阶段是类加载过程的最后一个步骤，除了在加载阶段用户应用程序可以通过自定义类加载器的方式局部参与外，其余动作都完全由Java虚拟机来主导控制。直到初始化阶段，Java虚拟机才真正开始执行类中编写的Java程序代码，将主导权移交给应用程序。

　　进行准备阶段时，变量已经赋过一次系统要求的初始零值，而在初始化阶段，则会根据程序员通过程序编码制定的主观计划去初始化类变量和其他资源。

　　初始化阶段就是执行类构造器<clinit>()方法的过程。<clinit>()并不是程序员在Java代码中直接编写的方法，它是Javac编译器的自动生成物。

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

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

　　由于父类的<clinit>()方法先执行，也就意味着父类中定义的静态语句块要优先于子类的变量赋值操作，如下代码示例，输出2。

public class Test { 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); }}

接口中不能使用静态语句块，但仍然有变量初始化的赋值操作，因此接口与类一样都会生成 <clinit>()方法。但接口与类不同的是，执行接口的<clinit>()方法不需要先执行父接口的<clinit>()方法，因为只有当父接口中定义的变量被使用时，父接口才会被初始化。此外，接口的实现类在初始化时也一样不会执行接口的<clinit>()方法。

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

public class Test { 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() { @Override 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(); }}

运行结果：

　　需要注意，其他线程虽然会被阻塞，但如果执行＜clinit＞()方法的那条线程退出

　　＜clinit＞()方法后，其他线程唤醒后则不会再次进入＜clinit＞()方法。同一个类加载器下，一个类型只会被初始化一次。

四、父类和子类初始化过程中的执行顺序

　　代码示例：

public class InitDemo {public static void main(String[] args) {System.out.println("第一次实例化子类:");new sub();System.out.println("第二次实例化子类：");new sub();}}class Super{static {System.out.println("父类中的静态块");}{System.out.println("父类中的非静态块");}Super(){System.out.println("父类中的构造方法");}}class sub extends Super{static {System.out.println("子类中的静态块");}{System.out.println("子类中的非静态块");}sub(){System.out.println("子类中的构造方法");}}

运行结果：

五、类加载器

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

5.1 类与类加载器

对于任意一个类，都必须由加载它的类加载器和这个类本身一起共同确立其在Java虚拟机中的唯一性，两个类来源于同一个 Class文件，被同一个Java虚拟机加载，只要加载它们的类加载器不同，那这两个类就必定不相等。

　　这里所指的相等，包括代表类的Class对象的equals()方法、isAssignableFrom()方法、isInstance() 方法的返回结果，也包括了使用instanceof关键字做对象所属关系判定等各种情况。如果没有注意到类加载器的影响，在某些情况下可能会产生具有迷惑性的结果，如下代码演示了不同的类加载器对 instanceof关键字运算的结果的影响。

　　代码示例：

package com.gzl.cn;import java.io.IOException;import java.io.InputStream;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("com.gzl.cn.ClassLoaderTest").newInstance(); System.out.println(obj.getClass()); System.out.println(obj instanceof com.gzl.cn.ClassLoaderTest); }}

上面示例当中构造了一个简单的类加载器，尽管它极为简陋，但是对于这个演示来说已经足够。它可以加载与自己在同一路径下的Class文件，我们使用这个类加载器去加载了一个名为com.gzl.cn.ClassLoaderTest的类，并实例化了这个类的对象。但在第二行的输出中却发现这个对象与类com.gzl.cn.ClassLoaderTest做所属类型检查的时候返回了false。

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

　　注意：同一个类加载器下，一个类型只会被初始化一次。

5.2 双亲委派模型

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

　　1.一种是启动类加载器（Bootstrap ClassLoader），这个类加载器使用C++语言实现，是虚拟机自身的一部分；

　　2.另外一种就是由Java语言实现的类加载器，独立存在于虚拟机外部，并且全都继承自抽象类 java.lang.ClassLoader。

　　站在Java开发人员的角度来看，类加载器就应当划分得更细致一些。自JDK 1.2以来，Java一直保持着三层类加载器、双亲委派的类加载架构。

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

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

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

　　为什么使用双亲委派模型？

　　简单的来说：一个是安全性，另一个就是性能；（避免重复加载和避免核心类被篡改）

　　用户自定义一个java.lang.String类，该String类具有系统的String类一样的功能，只是在某个函数稍作修改。比如equals函数，这个函数经常使用，如果在这这个函数中，黑客加入一些病毒代码。并且通过自定义类加载器加入到JVM中。此时，如果没有双亲委派模型，那么JVM就可能误以为黑客自定义的java.lang.String类是系统的String类，导致病毒代码被执行。

　　而有了双亲委派模型，黑客自定义的java.lang.String类永远都不会被加载进内存。因为首先是最顶端的类加载器加载系统的java.lang.String类，最终自定义的类加载器无法加载java.lang.String类。

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

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) { c = parent.loadClass(name, false); } else { c = findBootstrapClassOrNull(name); } } catch (ClassNotFoundException e) { // 如果父类加载器抛出ClassNotFoundException // 说明父类加载器无法完成加载请求，那就继续往下走 } if (c == null) { // 在父类加载器无法加载时 // 再调用本身的findClass方法来进行类加载 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; }}

启动类加载器（Bootstrap Class Loader）：引导类加载器，又叫启动类加载器。这个类加载器负责加载存放在 <JAVA_HOME>lib目录，或者被-Xbootclasspath参数所指定的路径中存放的，而且是Java虚拟机能够识别的（按照文件名识别，如rt.jar、tools.jar，名字不符合的类库即使放在lib目录中也不会被加载）类库加载到虚拟机的内存中。

　　扩展类加载器（Extension Class Loader）：

　　Java语言编写，由sun.misc.Launcher类的内部类ExtClassLoader类实现，派生于ClassLoader类，父加载器为引导类加载器。

　　从java.ext.dirs系统属性所指定的目录中加载类库，或从JDK的安装目录的jre/lib/ext子目录（扩展目录）下加载类库。如果用户创建的jar包放在此目录下，也会自动由扩展类加载器加载。

　　应用程序类加载器（Application Class Loader）：

　　这个类加载器由 sun.misc.Launcher$AppClassLoader来实现。由于应用程序类加载器是ClassLoader类中的getSystemClassLoader()方法的返回值，所以有些场合中也称它为系统类加载器。

　　它负责加载用户类路径（ClassPath）上所有的类库，开发者同样可以直接在代码中使用这个类加载器。如果应用程序中没有自定义过自己的类加载器，一般情况下这个就是程序中默认的类加载器。

5.3 破坏双亲委派模型

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

　　这里所说的破坏指的是没有遵循自下而上的规则。也就是刚刚提到的双亲委派模型的工作过程。

　　第一次破坏：

　　在 jdk 1.2 之前，那时候还没有双亲委派模型，不过已经有了 ClassLoader 这个抽象类，所以已经有人继承这个抽象类，重写 loadClass 方法来实现用户自定义类加载器。

　　而在 1.2 的时候要引入双亲委派模型，为了向前兼容， loadClass 这个方法还得保留着使之得以重写，新搞了个 findClass 方法让用户去重写，并呼吁大家不要重写 loadClass 只要重写 findClass。

　　这就是第一次对双亲委派模型的破坏，因为双亲委派的逻辑在 loadClass 上，但是又允许重写 loadClass，重写了之后就可以破坏委派逻辑了。

　　第二次破坏：

　　第二次破坏指的是 JNDI、JDBC 之类的情况。

　　首先得知道什么是 SPI(Service Provider Interface)，它是面向拓展的，也就是说我定义了个规矩，就是 SPI ，具体如何实现由扩展者实现。

　　像我们比较熟的 JDBC 就是如此。

　　MySQL 有 MySQL 的 JDBC 实现，Oracle 有 Oracle 的 JDBC 实现，我 Java 不管你内部如何实现的，反正你们这些数据库厂商都得统一按我这个来，这样我们 Java 开发者才能容易的调用数据库操作，所以在 Java 核心包里面定义了这个 SPI。

　　而核心包里面的类都是由启动类加载器去加载的，但它的手只能摸到<JAVA_HOME>lib或Xbootclasspath指定的路径中，其他的它鞭长莫及。

　　而 JDBC 的实现类在我们用户定义的 classpath 中，只能由应用类加载器去加载，所以启动类加载器只能委托子类来加载数据库厂商们提供的具体实现，这就违反了自下而上的委托机制。

　　具体解决办法是搞了个线程上下文类加载器（Thread Context ClassLoader）。这个类加载器可以通过java.lang.Thread类的setContext-ClassLoader()方法进行设置，如果创建线程时还未设置，它将会从父线程中继承一个，如果在应用程序的全局范围内都没有设置过的话，那这个类加载器默认就是应用程序类加载器。

　　如下图就是JDBC加载驱动当中用到的上下文类加载器。

　　其实这里说的打破双亲规则，就是说用来加载spi实现用的是线程中的加载器(其实就是AppclassLoader)，当加载spi实现类时就没有继续调用父类加载器了，因为它知道父类就是找不到才找它去加载的，说这里违反了双亲规则。

　　第三次破坏：

　　这次破坏是为了满足热部署的需求，不停机更新这对企业来说至关重要，毕竟停机是大事。

　　OSGI 就是利用自定义的类加载器机制来完成模块化热部署，而它实现的类加载机制就没有完全遵循自下而上的委托，有很多平级之间的类加载器查找，具体就不展开了，有兴趣可以自行研究一下。

六、Java模块化系统

在JDK 9中引入的Java模块化系统（Java Platform Module System，JPMS）是对Java技术的一次重要升级，此前，如果类路径中缺失了运行时依赖的类型，那就只能等程序运行到发生该类型的加载、链接时才会报出运行的异常。而在JDK 9以后，如果启用了模块化进行封装，模块就可以声明对其他模块的显式依赖，这样Java虚拟机就能够在启动时验证应用程序开发阶段设定好的依赖关系在运行期是否完备，如有缺失那就直接启动失败，从而避免了很大一部分由于类型依赖而引发的运行时异常。

　　JDK 9中的public类型不再意味着程序的所有地方的代码都可以随意访问到它们，模块提供了更精细的可访问性控制，必须明确声明其中哪一些public的类型可以被其他哪一些模块访问，这种访问控制也主要是在类加载过程中完成的。

　　其次是是扩展类加载器（Extension Class Loader）被平台类加载器（Platform Class Loader）取代。由于咱们一时半会也不会用JDK9，更多具体的我就不整理了。

　　以上就是一文详解Java中的类加载机制的详细内容，更多关于Java类加载机制的资料请关注盛行IT其它相关文章！

郑重声明：本文由网友发布，不代表盛行IT的观点，版权归原作者所有，仅为传播更多信息之目的，如有侵权请联系，我们将第一时间修改或删除，多谢。

目录