第5讲 深入理解 ClassLoader 的加载机制

第05讲 深入理解 ClassLoader 的加载机制

拉勾教育：https://kaiwu.lagou.com/course/courseInfo.htm

这一讲主要讲了class文件的加载时机，及加载class的双亲委派机制。还举例说明了如何自定义classLoader。最后还介绍了android中的类加载器，并举例使用自定义的类加载器进行热修复。下面来一一看一下这些内容。

一、class文件的加载时机

在 Java 程序启动的时候，并不会一次性加载程序中所有的 .class 文件，而是在程序的运行过程中，动态地加载相应的类到内存中。

通常情况下,Java 程序中的 .class 文件会在以下 2 种情况下被 ClassLoader 主动加载到内存中：

1. 调用类构造器
2. 调用类中的静态（static）变量或者静态方法

二、双亲委派模型

2.1 类加载器种类

从开发者的角度，类加载器可以细分为：

1. 启动类加载器(BootstrapClassLoader)：负责将 Java_Home/lib下面的类库加载到内存中（比如rt.jar）。由于引导类加载器涉及到虚拟机本地实现细节，开发者无法直接获取到启动类加载器的引用，所以不允许直接通过引用进行操作。

2. 标准扩展类加载器（ExtClassLoader ,JDK 1.9 之后，改名为 PlatformClassLoader）：是由 Sun 的 ExtClassLoader（sun.misc.Launcher$ExtClassLoader）实现的。它负责将Java_Home /lib/ext或者由系统变量 java.ext.dir指定位置中的类库加载到内存中。开发者可以直接使用标准扩展类加载器。

3. 应用程序类加载器（APPClassLoader）：是由 Sun 的 AppClassLoader（sun.misc.Launcher$AppClassLoader）实现的。它负责将系统类路径（CLASSPATH）中指定的类库加载到内存中。开发者可以直接使用系统类加载器。由于这个类加载器是ClassLoader中的getSystemClassLoader()方法的返回值，因此一般称为系统（System）加载器。

除此之外，还有自定义的类加载器，它们之间的关系通过被称为类加载器的双亲委派模型来体现。

2.2 双亲委派模型

用一张图来表示各个类加载器之间的委派关系

双亲委派模型即某个特定的类加载器在接到加载类的请求时，首先将加载任务委托给父类加载器，依次递归，如果父类加载器可以完成类加载任务，就成功返回；只有父类加载器无法完成此加载任务时，才自己去加载。

使用双亲委派模型的好处在于Java类随着它的类加载器一起具备了一种带有优先级的层次关系。例如类java.lang.Object，它存在在rt.jar中，无论哪一个类加载器要加载这个类，最终都是委派给处于模型最顶端的Bootstrap ClassLoader进行加载，因此Object类在程序的各种类加载器环境中都是同一个类。相反，如果没有双亲委派模型而是由各个类加载器自行加载的话，如果用户编写了一个java.lang.Object的同名类并放在ClassPath中，那系统中将会出现多个不同的Object类，程序将混乱。而在双亲委派模型，这个自已编写的Object类可以正常编译，但是永远无法被加载运行。

双亲委派模型在代码中的实现：

protected synchronized Class<?> loadClass(String name,boolean resolve)throws ClassNotFoundException{
    //check the class has been loaded or not
    Class c = findLoadedClass(name);
    if (c == null) {
           try {
               if (parent != null) {
                   c = parent.loadClass(name, false);
               } else {
                   c = findBootstrapClassOrNull(name);
               }
           } catch (ClassNotFoundException e) {
               // ClassNotFoundException thrown if class not found
               // from the non-null parent class loader
           }

           if (c == null) {
               // If still not found, then invoke findClass in order
               // to find the class.
               c = findClass(name);
           }
       }
    return c;
}

• 注意：“双亲委派”机制只是 Java 推荐的机制，并不是强制的机制。我们可以继承 java.lang.ClassLoader 类，实现自己的类加载器。
• 如果想保持双亲委派模型，就应该重写 findClass(name) 方法；
• 如果想破坏双亲委派模型，可以重写 loadClass(name) 方法。

三、自定义classLoader

JVM 中预置的 3 种 ClassLoader 只能加载特定目录下的 .class 文件，如果我们想加载其他特殊位置下的 jar 包或类时（比如，我要加载网络或者磁盘上的一个 .class 文件），默认的 ClassLoader 就不能满足我们的需求了，所以需要定义自己的 Classloader 来加载特定目录下的 .class 文件。

自定义 ClassLoader 步骤

1. 自定义一个类继承抽象类 ClassLoader。
2. 重写 findClass 方法。
3. 在 findClass 中，调用 defineClass 方法将字节码转换成 Class 对象，并返回。

课程举的例子，看下它的代码：

注意：上述动态加载 .class 文件的思路，经常被用作热修复和插件化开发的框架中，包括 QQ 空间热修复方案、微信 Tink 等原理都是由此而来。客户端只要从服务端下载一个加密的 .class 文件，然后在本地通过事先定义好的加密方式进行解密，最后再使用自定义 ClassLoader 动态加载解密后的 .class 文件，并动态调用相应的方法。

四、android中的类加载器

本质上，Android 和传统的 JVM 是一样的，也需要通过 ClassLoader 将目标类加载到内存，类加载器之间也符合双亲委派模型。但是在 Android 中， ClassLoader 的加载细节有略微的差别。

在 Android 虚拟机里是无法直接运行 .class 文件的，Android 会将所有的 .class 文件转换成一个 .dex 文件，并且 Android 将加载 .dex 文件的实现封装在 BaseDexClassLoader 中，而我们一般只使用它的两个子类：PathClassLoader 和 DexClassLoader。

PathClassLoader

PathClassLoader 用来加载系统 apk 和被安装到手机中的 apk 内的 dex 文件。当一个 App 被安装到手机后，apk 里面的 class.dex 中的 class 均是通过 PathClassLoader 来加载的

DexClassLoader

先来看官方对 DexClassLoader 的描述：

A class loader that loads classes from .jar and .apk filescontaining a classes.dex entry.

This can be used to execute code notinstalled as part of an application.

很明显，对比 PathClassLoader 只能加载已经安装应用的 dex 或 apk 文件，DexClassLoader 则没有此限制，可以从 SD 卡上加载包含 class.dex 的 .jar 和 .apk 文件，这也是插件化和热修复的基础，在不需要安装应用的情况下，完成需要使用的 dex 的加载。

由于水平有限，如果文中存在错误之处，请大家批评指正，欢迎大家一起来分享、探讨！

博客：http://blog.csdn.net/MingHuang2017

GitHub：https://github.com/MingHuang1024

Email： [email protected]

g2017)

GitHub：https://github.com/MingHuang1024

Email： [email protected]

微信：724360018