1. 概述

类加载器是 JVM 执行类加载机制的前提。

ClassLoader的作用：

ClassLoader是Java的核心组件，所有的Class都是由ClassLoader进行加载的，ClassLoader负责通过各种方式将Class信息的二进制数据流读入JVM内部，转换为一个与目标类对应的java.lang.Class对象实例。然后交给Java虚拟机进行链接、初始化等操作。因此，ClassLoader在整个装载阶段，只能影响到类的加载，而无法通过ClassLoader区改变类的链接和初始化行为。至于它是否可以运行，则由 Execution Engine决定。

类加载器最早出现在Java1.0版本中，那个时候只是单纯地为了满足Java Applet应用而被研发出来。但如今类加载器却在OSGi、字节码加解密领域大放异彩。这主要归功于Java虚拟机的设计者们当初在设计类加载器时，并没有考虑将它绑定在JVM内部，这样做的好处就是能够更加灵活和动态地执行类加载。

1.1 类加载的分类

类加载的分类：显式加载 vs 隐式加载

class文件的显式加载与隐式加载是指JVM加载class文件到内存的方式。

显式加载指的是在代码中通过调用ClassLoader加载class对象，如直接使用Class.forName(name)或this.getClass().getClassLoader().loadClass()加载class对象。
隐式加载则是不直接在代码中调用ClassLoader的方法加载class对象，而是通过虚拟机自动加载到内存中，如在加载某个类的class文件时，该类的class文件中引用了另一个类的对象，此时额外引用的类将通过JVM自动加载到内存中。

在日常开发，以上两种方法一般会混合使用。

1.2 类加载器的必要性

一般情况下，Java开发人员并不需要在程序中显式地使用类加载器，但是了解类加载器的加载机制却显得至关重要。从以下几个方面说：

避免在开发中遇到 java.lang.ClassNotFoundException 或 java.lang.NoClassDefFoundError 异常时无法判断。只有了解类加载器的加载机制才能够在出现异常时快速根据错误异常日志定位问题、解决问题。
需要支持类的动态加载或需要对编译后的字节码文件进行加解密操作时，就需要与类加载器打交道了。
开发人员可以在程序中编写自定义类加载器的加载规则，以便实现一些自定义的处理逻辑。

1.3 命名空间

1.3.1 类的唯一性

对于任意一个类，都需要由加载它的类加载器和这个类本身一同确认其在Java虚拟机中的唯一性。每一个类加载器，都拥有一个独立的类名称空间：比较两个类是否相等，只有在这两个类是由同一个类加载器加载的前提下才有意义。否则，即使这两个类源自同一个Class文件，被同一个虚拟机加载，只要它们的类加载器不同，那这两个类必定不相等。

1.3.2 命名空间

每个类都有自己的命名空间，命名空间由该加载器及所有的父加载器所加载的类组成。
在同一级命名空间中，不会出现类的完整名字（包括类的包名）相同的两个类。
在不同的命名空间中，有可能会出现类的完整名字（包括类的包名）相同的两个类。

在大型应用中，我们往往借助这一特性，来运行同一个类的不同版本。

1.4 类加载机制的基本特征

通常类加载机制由三个基本特征：

双亲委派模型：但不是所有的类加载都遵守这个模型，有的时候，启动类加载器所加载的类型，是可能要加载用户代码的，比如JDK内部的ServiceProvider/ServiceLoader机制，用户可以在标准API框架上，提供自己的实现，JDK也需要提供默认的参考实现。例如，Java中的 JNDI、JDBC、文件系统、Cipher 等很多方面，都是利用的这种机制，这种情况就不会用双亲委派模型去加载，而是利用所谓的上下文加载器。
可见性：子加载器可以访问父加载器加载的类型，但是反过来是不允许的。否则，会因为缺少必要的隔离无法利用类加载器实现容器的逻辑。
单一性：由于父加载器的类型对于子加载器是可见的，所以父加载器中加载过的类型，都不会在子加载器中重复加载。但是注意，类加载器 “邻居” 间，同一类型仍然可以被加载多次，因为互相并不可见。

2. 类的加载器分类

JVM支持两种类型的类加载器：引导类加载器（Bootstrap ClassLoader）和自定义类加载器（User-Defined ClassLoader）

从概念上类来讲，自定义类加载器一般指的是程序中由开发人员自定义的一类类加载器，但是Java虚拟机规范却没有这么定义，而是将所有派生于抽象类ClassLoader的类加载器都划分为自定义类加载器。无论类加载器的类型如何划分，在程序中我们最常见的类加载器结构主要是如下情况：

除了顶层的启动类加载器外，其余的加载器都应当有自己的父加载器。
不同的类加载器看似是继承关系（Inheritance）关系，实际上是包含关系。在下层加载器中，包含着上层加载器的引用。

2.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等开头的类。
加载扩展类加载器、应用程序类加载器，并指定为它们的父加载器。

可以使用-xx:+TraceClassLoader参数查看类加载具体流程。

2.2 扩展类加载器

扩展类加载器（Extension ClassLoader）

Java语言编写，由sun.misc.Launcher$ExtClassLoader实现。
继承于ClassLoader类
父加载器为Bootstrap启动类加载器
从java.ext.dirs系统属性所指定的目录中加载类库，或从JDK的安装目录的jre/lib/ext子目录下加载类库。如果用户创建的JAR放在此目录下，也会自动由扩展类加载器加载。

2.3 系统类加载器

系统类加载器 / 应用程序类加载器（Application ClassLoader）

Java语言编写，由sun.misc.Launcher$AppClassLoader实现。
继承于ClassLoader类
父加载器为扩展类加载器
它负责加载环境变量classpath或系统属性java.class.path 指定路径下的类库
应用中的类加载器默认为系统类加载器。
它是用户自定义类加载器的默认父加载器
通过ClassLoader的getSystemClassLoader()方法可以获取到该类加载器。

2.4 用户自定义类加载器

用户自定义类加载器

在Java的日常应用程序开发中，类的加载几乎是由上述3种类加载器相互配合执行的。在必要时，我们还可以自定义类加载器，来定制类的加载方式。
体现Java语言强大生命力和巨大魅力的关键因素之一：Java开发者可以自定义类加载器来实现类库的动态加载。加载源可以是本地的JAR包，也可以是网络上的远程资源。
通过类加载器可以实现非常绝妙的插件机制，这方面的实际应用案例举不胜举。例如，著名的OSGi组件框架、Eclipse的插件机制。类加载器为应用程序提供了一种动态增加新功能的机制，这种机制无需重新打包发布应用程序就能实现。
同时，自定义类加载器能够实现应用隔离，例如 Tomcat、Spring等组件框架/中间件都在内部定义了自定义的加载器，并通过自定义加载器隔离不同的组件模块。
- 这种机制比C/C++程序好，几乎不可能做到不修改C/C++程序就能为其新增功能，仅仅一个兼容性就能阻挡所有美好的设想。
自定义类加载器通常需要继承于ClassLoader。

3. 测试不同的类加载器

每个Class对象都会包含一个定义它的ClassLoader的一个引用。

获取ClassLoader的途径

获得当前类的ClassLoader：

Clazz.getClassLoader();

获得当前线程上下文的ClassLoader：

Thread.currentThead().getContextClassLoader();

获得系统的ClassLoader：

ClassLoader.getSystemClassLoader();

说明：

站在程序员的角度看，引导类加载器与另外两种加载器（系统类加载器+扩展类加载器）并不是同一个层次意义上的加载器，引导类加载器由C++语言编写，而另外两种类加载器由Java语言编写。由于引导类加载器并非Java类，因此在Java程序中只能打印出null值。

数组类的Class对象，不是由类加载器去创建的，而是在Java运行期JVM根据需要自动创建的。对于数组类的类加载器来说，是通过Class.getClassLoader()返回的，与数组当中元素类型的类加载器是一样的；如果数组当中的元素类型是基本数据类型(虚拟机预先定义, 无需类加载)，数组类没有类加载器。

数组类 - 举例：

/*** 不同类加载器-测试*/
public class ClassLoaderTest {public static void main(String[] args) {ClassLoader classLoader1 = (new String[10]).getClass().getClassLoader();        //String : BootstrapSystem.out.println(classLoader1);ClassLoader classLoader2 = (new int[10]).getClass().getClassLoader();           //int : 基本数据类型System.out.println(classLoader2);ClassLoader classLoader3 = (new Application[10]).getClass().getClassLoader();   //JavaFX (JDK 1.8) : Application类(Extension)System.out.println(classLoader3);ClassLoader classLoader5 = (new User[10]).getClass().getClassLoader();          //自定义类 : User类(Application)System.out.println(classLoader5);}
}
/*** 用户自定义类*/
class User {private int id;
}

测试结果：

4. ClassLoader源码解析

ClassLoader与现有类加载器的关系：

除了以上虚拟机自带的加载器外，用户还可以定制自己的类加载器。Java提供了抽象类java.lang.ClassLoader，所有用户自定义的类加载器都应该继承ClassLoader类。

4.1 ClassLoader的主要方法

ClassLoader的主要方法（内部没有抽象方法）

4.1.1 getParent()

返回此类加载器的超类加载器。

public final ClassLoader getParent()

4.1.2 loadClass()

加载名称为name的类，返回结果为java.lang.Class类的实例。如果找不到类，则返回ClassNotFoundException异常。该方法中的逻辑就是双亲委派模式的实现。

public Class<?> loadClass(String name) throws ClassNotFoundException

核心方法解析：

/*** 测试代码：ClassLoader.getSystemClassLoader().loadClass("com.ljw.demo.User");*/
protected Class<?> loadClass(String name, boolean resolve)        //resolve:true-加载Class同时进行解析操作throws ClassNotFoundException {synchronized (getClassLoadingLock(name)) {     //同步操作，保证只能加载一次// 首先，在缓存中判断是否已经加载同名的类 (First, check if the class has already been loaded)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;   // 返回Class实例}
}

4.1.3 findClass()

查找二进制名称为name的类，返回结果为java.lang.Class类的实例。这是一个受保护的方法，JVM鼓励我们重写此方法，需要自定义类加载器遵循双亲委托机制。该方法会在检查完父加载器后被 loadClass() 方法调用。

在JDK1.2之前，在自定义类加载时，总会继承ClassLoader类并重写loadClass方法，从而实现自定义的类加载器。但是在JDK1.2之后已不再建议用户覆盖loadClass() 方法，而是建议把自定义的类加载逻辑写在findClass()方法中，从前面的分析可知，findClass()方法是在loadClass() 方法中被调用的，当loadClass() 方法中父加载器加载失败后，则会调用自己的findClass来完成类加载，这样就可以保证自定义类加载器也符合双亲委托模型。

需要注意的是ClassLoader类中并没有实现findClass()方法的具体逻辑，取而代之的是抛出ClassNotFoundException异常，同时需注意findClass方法通常与defineClass方法一起使用。一般情况下，在自定义类加载器时，会直接覆盖ClassLoader的findClass() 方法并编写加载规则，取得要加载类的字节码后转换成流，然后调用defineClass() 方法生成类的Class对象。

URLClassLoader类中有ExtClassLoader、AppClassLoader此方法的具体实现。

protected Class<?> findClass(String name) throws ClassNotFoundException {throw new ClassNotFoundException(name);
}

4.1.4 defineClass()

根据给定的字节数组b转化为Class的实例，off和len参数表示实际Class信息在byte数组中的位置和长度，其中byte数组b是ClassLoader从外部获取的，这是受保护的方法，只有在自定义ClassLoader子类中可以使用。

defineClass()方法是用来将byte字节流解析成JVM能够识别的Class对象(ClassLoader中已实现该方法逻辑)，这个方法不仅能够通过class文件实例化对象，也可以通过其他方式实例化class对象，如通过网络接收一个类的字节码，然后转换为byte字节流创建对应的Class对象。

defineClass()方法通常与findClass()方法一起使用，一般情况下，在自定义类加载器时，会直接覆盖ClassLoader的findClass()方法并编写加载规则，取得要加载类的字节码后转换成流，然后调用defineClass()方法生成类的Class对象。

protected final Class<?> defineClass(String name, byte[] b, int off, int len)

举例：

@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);}
}

4.1.5 resolveClass()

链接指定的一个Java类。使用该方法可以使用类的Class对象创建完成的同时也被解析。前面我们说连接阶段主要是对字节码进行验证，为类变量分配内存并设置初始值同时将字节码文件的符号引用转化为直接引用。

protected final void resolveClass(Class<?> c)

4.1.6 findLoadedClass()

查找名称为name的已经被加载过的类，返回结果为java.lang.Class类的实例。这个方法被final修饰，无法被修改。

protected final Class<?> findLoadedClass(String name)

4.1.7 parent

它也是ClassLoader的实例，这个字段表示的ClassLoader也成为这个ClassLoader的双亲。在类加载的过程中，ClassLoader可能会将某些请求交予自己的双亲处理。

private final ClassLoader parent;

4.2 SecureClassLoader 与 URLClassLoader

SecureClassLoader扩展了ClassLoader，新增了几个与使用相关的代码 (对代码源的位置及其证书的验证) 和权限定义类验证 (主要指对class源码的访问权限) 的方法，一般我们不会直接与这个类打交道，更多是与它的子类URLClassLoader有所关联。

前面提到，ClassLoader是一个抽象类，很多方法是空的没有实现（比如 findClass()、findResource() 等）。而URLClassLoader这个实现类为这些方法提供了具体的实现。并新增了URLClassPath类协助取得Class字节码流等功能。在编写自定义类加载器时，如果没有太过于复杂的需求，可以直接继承URLClassLoader类，这样就可以避免自己编写findClass()方法及其获取字节码流的方式，使自定义类加载器编写更加简洁。

4.3 ExtClassLoader 与 AppClassLoader

扩展类加载器ExtClassLoader 和系统类加载器AppClassLoader，这两个类都继承自URLClassLoader，并作为sun.misc.Launcher的静态内部类。

sun.misc.Launcher主要被系统用于启动主应用程序，而ExtClassLoader和AppClassLoader都是由sun.misc.Launcher创建的。

ExtClassLoader没有重写loadClass()方法，说明其遵循双亲委派模型。而AppClassLoader重载了loadClass()方法，但最终调用的还是父类loadClass()方法，因此依然遵循双亲委派模型。

4.4 Class.forName() 与 ClassLoader.loadClass()

Class.forName()：一个静态方法，最常用的是Class.forName(String className)；根据传入的类的全限定名返回一个Class对象。该方法在将Class文件加载到内存的同时，会执行类的初始化。（如：Class.forName(“com.ljw.demo.Demo”);）
ClassLoader.loadClass()：一个实例方法，需要一个ClassLoader对象来调用该方法。该方法将Class文件加载到内存时，并不会执行类的初始化，直到这个类第一次使用时才进行初始化。该方法因为需要得到一个ClassLoader对象，所以可以根据需要指定使用哪个类加载器。（如：ClassLoader cl = …; cl.loadClass(“com.ljw.demo.Demo”); ）

5. 双亲委派模型

5.1 定义与本质

类加载器用于将类加载到Java虚拟机中。从JDK1.2版本开始，类的加载过程采用双亲委派机制，这种机制能更好地保证Java平台的安全。

5.1.1 定义

如果一个类加载器在接到加载类的请求时，它首先不会自己尝试去加载这个类，而是把这个请求任务委托给父加载器去完成，依次递归，如果父加载器可以完成类加载任务，就成功返回。只有父类加载器无法完成此加载任务时，才自己去加载。

5.1.2 本质

规定了类加载的顺序：引导类加载器先加载，若加载不到，则由扩展类加载器加载，若还加载不到，才会由系统类加载器/自定义类加载器进行加载。

5.2 优势与劣势

5.2.1 优势

避免类的重复加载，确保一个类的全局唯一性

Java类随着它的类加载器一起具备了一种带有优先级的层次关系，通过这种层次关系可以避免类的重复加载，当父加载器已经加载了该类时，就没有必要子加载器再加载一次。
保护程序安全，防止核心API被随意篡改。

5.2.2 代码支持

双亲委派机制在java.lang.ClassLoader.loadClass(String, boolean)接口中体现。该接口的逻辑如下：

先在当前加载器的缓存中擦好找有无目标类，如果有，直接返回。
判断当前加载器的父加载器是否为空，如果不为空，则调用parent.loadClass(name, false)接口进行加载。
反之，如果当前加载器的父加载器为空，则调用findBootstrapClassOrNull(name) 接口，让引导类加载器进行加载。
如果通过以上3条路径都没成功加载，则调用findClass(name) 接口进行加载。该接口最终会调用java.lang.ClassLoader接口的defineClass系列的native接口加载目标Java类。

双亲委派模型就隐藏在第2、3步中。

5.2.3 举例

假设当前加载的是java.lang.Obejct类，显然，此类属于JDK中的核心类，因此只能由Bootstrap引导类加载器进行加载。当JVM准备加载java.lang.Obejct时，JVM会默认使用系统类加载器加载，按照上面4步加载逻辑，在第1步从系统类的缓存中肯定查找不到此类，于是进入第2步。由于从系统类加载器的父加载器时扩展类加载器，于是扩展类加载器继续从第1步开始重复。由于扩展类加载器的缓存中也查找不到此类，因此进入第2步，扩展类的父加载器是null，因此系统调用findClass(String)，最终通过引导类加载器进行加载。

5.2.4 思考

如果在自定义的类加载器中重写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核心类库的保护。

5.2.5 弊端

检查类是否加载的委托过程是单向的，这个方式虽然从结构上说比较清晰，使各个ClassLoader的职责非常明确，但是同时会带来一个问题，即顶层的ClassLoader无法访问底层ClassLoader所加载的类。

通常情况下，启动类加载器的类为系统核心类，包括一些重要的系统接口，而在应用类加载器中，为应用类。按照这种模式，应用类访问系统类自然是没有问题，但是系统类访问应用类就会出现问题。比如在系统类中提供了一个接口，该接口需要在应用类中得以实现，该接口还绑定了一个工厂方法，用于创建该接口的实例，而接口和工厂方法都在启动类加载器中。这时，就会出现该工厂方法无法创建由应用类加载器加载的应用实例的问题。

5.2.6 结论

由于Java虚拟机规范并没有明确要求类加载器的加载机制一定要使用双亲委派模型，只是建议采用这种方式而已。

比如在Tomcat中，类加载器所采用的加载机制就和传统的双亲委派模型有一定的区别，当缺省的类加载器接收到一个类的加载任务时，首先会由它自行加载，当它加载失败时，才会将类的加载任务委派给它的超类加载器去执行，这同时也是Servlet规范推荐的一种做法。

5.3 破坏双亲委派机制

双亲委派模型并不是一个具有强制性约束的模型，而是Java设计者推荐给开发者们的类加载器实现方式。

在Java的世界中大部分的类加载器都遵循这个模型，但也有例外的情况，直到Java模块化出现为止，双亲委派模型主要出现过3次较大规模 “被破坏” 的情况。

5.3.1 第1次破坏

双亲委派模型的第一次 “被破坏” 其实发生在双亲委派模型出现之前——即 JDK 1.2 问世以前的 “远古” 时代。

由于双亲委派模型在 JDK 1.2 之后才被引入，但是类加载器的概念和抽象类java.lang.ClassLoader则在Java的第一个版本中就已经存在，面对已经存在的用户自定义类加载器的代码，Java设计者们引入双亲委派模型时不得不做出一些妥协，为了兼容这些已有代码，无法再以技术手段避免loadClass()被子类覆盖的可能性，只能在JDK1.2之后的java.lang.ClassLoader中添加一个新的protected方法findClass()，并引导用户编写的类加载逻辑时尽可能去重写这个方法，而不是在loadClass()中编写代码。上节我们已经分析过loadClass()方法，双亲委派的具体逻辑就实现在这里面，按照loadClass()方法的逻辑，如果父类加载失败，会自动调用自己的findClass()方法来完成加载，这样既不影响用户按照自己的意愿去加载类，又可以保证新写出来的类加载器是符合双亲委派机制的。

5.3.2 第2次破坏

第二次破坏双亲委派机制：线程上下文类加载器

双亲委派模型的第二次 “被破坏” 是由这个模型自身的缺陷导致的，双亲委派很好地解决了各个类加载器协作时基础类型的一致性问题（越基础的类由越上层的加载器进行加载），基础类型之所以被称为 “基础”，是因为他么按总是作为被用户代码继承、调用的API存在，但程序设计往往没有绝对不变的完美规则，如果有基础类型又要调用回用户的代码，那该怎么办呢？

这并非是不可能出现的事情，一个典型的例子便是JNDI服务，JNDI现在已经是Java的标准服务，它的代码由启动类加载器来完成加载（在JDK 1.3时加入到rt.jar），肯定属于Java中很基础的类型，但JNDI存在的目的就是对资源进行查找和集中管理，它需要调用由其他厂商实现并部署在应用程序的ClassPath下的 JNDI服务提供者接口（Service Provider Interface, SPI）的代码。现在问题来了，启动类加载器是绝不可能认识、加载这些代码的，那么该怎么办？（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中的配置信息，辅以责任链模式(职责链模式)，这才算是一种相对合理的解决方案。

默认上下文加载器就是应用类加载器，这样以上下文加载器为中介，使得启动类加载器中的代码也可以访问应用类加载器中的类。

5.3.3 第3次破坏

双亲委派模型的第三次 “被破坏” 是由于用户对程序动态性的追求而导致的。如：代码热替换（Hot Swap）、**模块热部署（Hot Deployment）**等。

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

当收到类加载请求时，OSGi将按照下面的顺序进行类搜索：

将以java.*开头的类，委派给父加载器加载。
否则，将委派列表名单内的类，委派给父加载器加载。
否则，将Import列表中的类，委托给Export这个类的Bundle的类加载器加载。
否则，查找当前Bundle的ClassPath，使用自己的类加载器加载。
否则，查找类是否在自己的Fragment Bundle中，如果在，则委派给Fragment Bundle的类加载器加载。
否则，查找Dynamic Import列表中的Bundle，委派给对应Bundle的类加载器加载。
否则，类查找失败。

说明：仅有开头两点仍然符合双亲委派模型的原则，其余的类查找都是在平级的类加载器中进行的。

小结：

这里，我们用 “被破坏” 这个词来形容上述不符合双亲委派模型原则的行为，但这里 “被破坏” 并不一定是带有贬义的。只要有明确的目的和充分的理由，突破旧有原则无疑是一种创新。

5.4 热替换的实现

热替换是指在程序运行过程中，不停止服务，只通过替换程序文件来修改程序的行为。热替换的关键需求在于服务不能中断，修改必须立即表现正在运行的系统之中。基本上大部分脚本语言都是天生支持热替换的。(如：PHP, 替换源文件改动立即生效, 无需重启Web服务器)

但对Java来说，热替换并非天生就支持，如果一个类已经加载到系统中，通过修改类文件，并无法让系统再来加载并重定义这个类。因此，在Java中实现这一功能的一个可行的方法就是灵活运用ClassLoader。

注意：由不同ClassLoader加载的同名类属于不同类型，不能相互转换和兼容。即两个不同的ClassLoader加载同一个类，在虚拟机内部，会认为这2个类是完全不同的。

根据这个特点，可以用来模拟热替换的实现，基本思路如下：

代码举例：

热替换测试类：

public class Demo1 {public void hot() {System.out.println("OldDemo");//System.out.println("OldDemo ---> NewDemo");}
}

自定义类加载器：

/*** 热部署用-自定义类加载器*/
public class MyClassLoader extends ClassLoader {private String rootDir;public MyClassLoader(String rootDir) {this.rootDir = rootDir;}@Overrideprotected Class<?> findClass(String className) throws ClassNotFoundException {Class clazz = this.findLoadedClass(className);FileChannel fileChannel = null;WritableByteChannel outChannel = null;if (null == clazz) {try {String classFile = getClassFile(className);FileInputStream fis = new FileInputStream(classFile);fileChannel = fis.getChannel();ByteArrayOutputStream baos = new ByteArrayOutputStream();outChannel = Channels.newChannel(baos);ByteBuffer buffer = ByteBuffer.allocateDirect(1024);while (true) {int i = fileChannel.read(buffer);if(i == 0 || i == -1) {break;}buffer.flip();outChannel.write(buffer);buffer.clear();}byte[] bytes = baos.toByteArray();clazz = defineClass(className, bytes, 0, bytes.length);} catch (FileNotFoundException e) {e.printStackTrace();} catch (IOException e) {e.printStackTrace();} finally {try {if (fileChannel != null) {fileChannel.close();}} catch (IOException e) {e.printStackTrace();}try {if (outChannel != null) {outChannel.close();}} catch (IOException e) {e.printStackTrace();}}}return clazz;}/*** 类文件的完全路径*/public String getClassFile(String className) {return rootDir + "\\" + className.replace('.', '\\') + ".class";}
}

测试类：

public class LoopRun {public static void main(String[] args) {while (true) {try {// 1. 创建自定义类加载器实例MyClassLoader loader = new MyClassLoader("D:\\Workplace-Myabtis\\jvm-demo-02\\src\\main\\java");// 2. 加载指定的类Class clazz = loader.findClass("com.ljw.demo09.Demo1");// 3. 创建运行时类的实例Object demo = clazz.newInstance();// 4. 获取运行时类中指定的方法Method m = clazz.getMethod("hot");// 5. 调用指定的方法m.invoke(demo);Thread.sleep(5000);} catch (Exception e) {System.out.println("not find");try {Thread.sleep(5000);} catch (InterruptedException ex) {ex.printStackTrace();}}}}
}

分别在更改代码前后使用两次javac，实现代码热替换：

6. 沙箱安全机制

沙箱安全机制

保证程序安全
保护Java原生的JDK代码

Java安全模型的核心就是Java沙箱 (sandbox)。沙箱即一个限制程序运行的环境。

沙箱机制就是将Java代码限定在虚拟机（JVM）特定的运行范围中，并且严格限制代码对本地系统资源的访问。通过这样的措施来保证对代码的有限隔离，防止对本地系统造成破坏。

沙箱主要限制系统资源访问，那系统资源包括什么？CPU、内存、文件系统、网络。不同级别的沙箱对这些资源访问的限制也可以不一样。

所有的Java程序都可以指定沙箱，可以定制安全策略。

6.1 JDK1.0时期

在Java中将执行程序分为本地代码和远程代码两种，本地代码默认视为可信任的，而远程代码则被看作是不受信的。对于授信的本地代码，可以访问一切本地资源。而对于非授信的远程代码在早期的Java实现中，安全依赖于沙箱（Sandbox）机制。

6.2 JDK1.1时期

JDK1.0中如此严格的安全机制也给程序的功能扩展带来了障碍，比如当用户希望远程代码访问本地系统的文件时，就无法实现。

因此在后续的Java1.1版本中，针对安全机制做了改进，增加了 安全策略。允许用户指定本地代码对本地资源的访问权限。

6.3 JDK1.2时期

在JDK1.2版本中，再次改进了安全机制，增加了 代码签名。不论本地代码或是远程代码，都会按照用户的安全策略设定，由类加载器加载到虚拟机中权限不同的运行空间，来实现差异化的代码执行权限控制。

6.4 JDK1.6时期

当前最新的安全机制，则引入了 **域（Domain）**的概念。

虚拟机会把所有代码加载到不同的系统域和应用域。系统域部分专门负责与关键资源进行交互，而各个应用域部分则通过系统域的部分代理来对各种需要的资源进行访问。虚拟机中不同的受保护域（Protected Domain），对应不一样的权限（Permission）。存在于不同于中的类文件就具有了当前域的全部权限，下面是最新的安全模型（JDK 1.6）

7. 自定义类加载器

7.1 概述

7.1.1 类加载器作用

隔离加载类

在某些框架内进行中间件与应用的模块隔离，把类加载到不同的环境。
- 例1：阿里内某容器框架通过自定义类加载器确保应用中依赖的jar包不会影响到 中间件 运行时使用的jar包。（类的仲裁 --> 类冲突）
- 例2：Tomcat这类Web应用服务器，内部自定义了好几种类加载器，用于隔离同一个Web应用服务器上的不同应用程序。
修改类加载的方式

类的加载模型并非强制，除Bootstrap外，其他的加载并非一定要引入，或者根据实际情况在某个时间点按需进行动态加载。
扩展加载源

比如从数据库、网络、电视机机顶盒进行加载
防止源码泄漏

Java代码容易被编译和篡改，可以进行编译加密，那么类加载也需要自定义，还原加密的字节码。

7.1.2 常见的场景

实现类似进程内隔离，类加载器实际上用作不同的命名空间，以提供类似容器、模块化的效果。
- 例如，两个模块依赖于某个类库的不同版本，如果分别被不同的容器加载，就可以互不干扰。这个方面集大成者是Java EE 和 OSGi、JPMS等框架。
应用需要从不同的数据源获取类定义信息。
- 例如网络数据源，而非本地文件系统。或是需要自己操纵字节码，动态修改或生成类型。

7.1.3 注意

在一般情况下，使用不同的类加载器去加载不同的功能模块，会提高应用程序的安全性。

但是，如果涉及Java类型转换，则加载器反而容易产生不美好的事情。在做Java类型转换时，只有两个类型都是由同一个加载器所加载，才能进行类型转换，否则转换时会发生异常。

7.2 实现方式

用户通过定制自己的类加载器，这样可以重新定义类的加载规则，以便实现一些自定义的处理逻辑。

7.2.1 实现方式

Java提供了抽象类java.lang.ClassLoader，所有用户自定义的类加载器都应该继承ClassLoader类。
在自定义ClassLoader子类时，我们常见的会有两种做法：
- 方式一：重写loadClass()方法
- 方式二：重写findClass()方法 → 推荐

7.2.2 对比

这两种方法本质上差不多，毕竟loadClass()也会调用findClass()，但是从逻辑上讲我们最好不要直接修改loadClass()的内部逻辑。建议的做法是只在findClass()里重写自定义类的加载方法，根据参数指定类的名字，返回对应的Class对象的引用。

loadClass()这个方法是实现双亲委派模型逻辑的地方，擅自修改这个方法会导致模型的破坏，容易造成问题。因此，最好是在双亲委派模型框架内进行小范围改动，不破坏原有的稳定结构。同时，也避免了自己重写loadClass()方法的过程中必须写双亲委托的重复代码，从代码的复用性来看，不直接修改这个方法始终是比较好的选择。
当编写好自定义类加载器后，便可以在程序中调用loadClass() 方法来实现类加载操作。

7.2.3 说明

其父类加载器是系统类加载器
JVM中的所有类加载都会使用java.lang.ClassLoader.loadClass(String)接口 (自定义类加载器并重写java.lang.ClassLoader.loadClass(String)接口的除外)，连JDK的核心类库也不能例外。

7.2.4 举例