《深入理解JVM虚拟机》读书笔记-类加载器&Java模块化系统

类加载器

一.类加载器

1.1 类与类加载器

类加载器的定义：

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

  • 记忆：类加载阶段 通过 这个动作 以便

类加载器虽然只用于实现类的加载动作，但它在Java程序中起到的作用却远超类加载阶段：

• 对于任意一个类，都必须由加载它的类加载器和这个类本身一起共同确立其在Java虚拟机中的唯一性，每一个类加载器，都拥有一个独立的类名称空间。

• 这句话可以表达得更通俗一些：

  • 比较两个类是否“相等”，只有在这两个类是由同一个类加载器加载的前提下才有意义，否则，即使这两个类来源于同一个Class文件，被同一个Java虚拟机加载，只要加载它们的类加载器不同，那这两个类就必定不相等。

  • 类相等在java中的体现：

    • 这里所指的“相等”，包括代表类的Class对象的equals()方法、isAssignableFrom()方法、isInstance()方法的返回结果，

    • 也包括了使用instanceof关键字做对象所属关系判定等各种情况。

如果没有注意到类加载器的影响，在某些情况下可能会产生具有迷惑性的结果，如下代码演示了不同的类加载器对instanceof关键字运算的结果的影响。

/*

 * 类加载器与instanceof关键字演示

 *

 * @author zzm

 */

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("org.fenixsoft.classloading.ClassLoaderTest").newInstance();

        System.out.println(obj.getClass());

        System.out.println(obj instanceof org.fenixsoft.classloading.ClassLoaderTest);

    }

}

输出

class org.fenixsoft.classloading.ClassLoaderTest

false

  两行输出结果中，从第一行可以看到这个对象确实是类org.fenixsoft.classloading.ClassLoaderTest实例化出来的，但在第二行的输出中却发现这个对象与类org.fenixsoft.classloading.ClassLoaderTest做所属类型检查的时候返回了false。这是因为Java虚拟机中同时存在了两个ClassLoaderTest类，一个是由虚拟机的应用程序类加载器所加载的，另外一个是由我们自定义的类加载器加载的，虽然它们都来自同一个Class文件，但在Java虚拟机中仍然是两个互相独立的类，做对象所属类型检查时的结果自然为false。

1.2 双亲委派模型

1.2.1 类加载器的分类：

• 粗分类：

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

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

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

• 细分类：

  • 站在Java开发人员的角度来看，类加载器就应当划分得更细致一些，即三层类加载器（JDK 8及之前版本绝大多数Java程序都会使用到以下3个系统提供的类加载器来进行加载）<见补充说明1>：

    • 1.启动类加载器（Bootstrap Class Loader）：

      • 存放位置：

        • 这个类加载器负责加载存放在\lib目录，或者被-Xbootclasspath参数所指定的路径中存放的，而且是Java虚拟机能够识别的类库加载到虚拟机的内存中。

          • 按照文件名识别，如rt.jar、tools.jar，名字不符合的类库即使放在lib目录中也不会被加载。

      • 引用：

        • 启动类加载器无法被Java程序直接引用，用户在编写自定义类加载器时，如果需要把加载请求委派给引导类加载器去处理，那直接使用null代替即可<见补充说明2>。

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

      • 实现方式：

        • 这个类加载器是在类sun.misc.Launcher$ExtClassLoader中以Java代码的形式实现的。

      • 加载路径：

        • 它负责加载\lib\ext目录中，或者被java.ext.dirs系统变量所指定的路径中所有的类库。

      • 作用：

        • 扩展：根据“扩展类加载器”这个名称，就可以推断出这是一种Java系统类库的扩展机制，JDK的开发团队允许用户将具有通用性的类库放置在ext目录里以扩展Java SE的功能。

          • 在JDK 9之后，这种扩展机制被模块化带来的天然的扩展能力所取代。由于扩展类加载器是由Java代码实现的，开发者可以直接在程序中使用扩展类加载器来加载Class文件。

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

      • 实现方式：

        • 这个类加载器由sun.misc.Launcher$AppClassLoader来实现。

        • 由于应用程序类加载器是ClassLoader类中的getSystem-ClassLoader()方法的返回值，所以有些场合中也称它为“系统类加载器”。

      • 作用：

        • 它负责加载用户类路径（ClassPath）上所有的类库，开发者同样可以直接在代码中使用这个类加载器。

        • 如果应用程序中没有自定义过自己的类加载器，一般情况下这个就是程序中默认的类加载器。

---

补充说明1：

  自JDK 1.2以来，Java一直保持着三层类加载器、双亲委派的类加载架构，尽管这套架构在Java模块化（1.9）系统出现后有了一些调整变动，但依然未改变其主体结构，我们将在后面的章节中专门讨论模块化系统下的类加载器。

补充说明2：

/*

Returns the class loader for the class.  Some implementations may use null to represent the bootstrap class loader. This method will return  null in such implementations if this class was loaded by the bootstrap class loader.

*/

public ClassLoader getClassLoader() {

    ClassLoader cl = getClassLoader0();

    if (cl == null)

        return null;

    SecurityManager sm = System.getSecurityManager();

    if (sm != null) {

        ClassLoader ccl = ClassLoader.getCallerClassLoader();

        if (ccl != null && ccl != cl && !cl.isAncestor(ccl)) {

            sm.checkPermission(SecurityConstants.GET_CLASSLOADER_PERMISSION);

        }

    }

    return cl;

}

以上展示的就是java.lang.ClassLoader.getClassLoader()方法的代码片段，其中的注释和代码实现都明确地说明了以null值来代表引导类加载器的约定规则。

---

1.2.2 双亲委派模型

image.png

  如上图中展示的各种类加载器之间的层次关系被称为类加载器的“双亲委派模型（Parents Delegation Model）”。

双亲委派模型的规则：

• 双亲委派模型要求除了顶层的启动类加载器外，其余的类加载器都应有自己的父类加载器。

类加载器之间的父子关系的实现方式：

• 这里类加载器之间的父子关系一般不是以继承（Inheritance）的关系来实现的，而是通常使用组合（Composition）关系来复用父加载器的代码。

  • 前面描述这种类加载器协作关系时，专门用双引号强调这是“通常”的协作关系：

    • 类加载器的双亲委派模型在JDK 1.2时期被引入，并被广泛应用于此后几乎所有的Java程序中，但它并不是一个具有强制性约束力的模型，而是Java设计者们推荐给开发者的一种类加载器实现的最佳实践。

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

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

双亲委派模型的好处：

• 使用双亲委派模型来组织类加载器之间的关系，一个显而易见的好处就是Java中的类随着它的类加载器一起具备了一种带有优先级的层次关系。

• 例如类java.lang.Object，它存放在rt.jar之中，无论哪一个类加载器要加载这个类，最终都是委派给处于模型最顶端的启动类加载器进行加载，因此Object类在程序的各种类加载器环境中都能够保证是同一个类。

  • 即启动类加载器的加载顺序高于其他加载器，能够保证jvm需要的类的唯一性。

• 反之，如果没有使用双亲委派模型，都由各个类加载器自行去加载的话，如果用户自己也编写了一个名为java.lang.Object的类，并放在程序的ClassPath中，那系统中就会出现多个不同的Object类，Java类型体系中最基础的行为也就无从保证，应用程序将会变得一片混乱。

例子：

protected synchronized Class loadClass(String name, boolean resolve) throws ClassNotFoundException

{

    // 首先，检查请求的类是否已经被加载过了

    Class c = findLoadedClass(name);

    if (c == null) {

        try {

        if (parent != null) {

            c = parent.loadClass(name, false);

        } else {

            c = findBootstrapClassOrNull(name);

        }

        } catch (ClassNotFoundException e) {

            // 如果父类加载器抛出ClassNotFoundException

            // 说明父类加载器无法完成加载请求

        }

        if (c == null) {

            // 在父类加载器无法加载时

            // 再调用本身的findClass方法来进行类加载

            c = findClass(name);

        }

    }

    if (resolve) {

        resolveClass(c);

    }

    return c;

}

  这段代码的逻辑清晰易懂：先检查请求加载的类型是否已经被加载过，若没有则调用父加载器的loadClass()方法，若父加载器为空则默认使用启动类加载器作为父加载器。假如父类加载器加载失败，抛出ClassNotFoundException异常的话，才调用自己的findClass()方法尝试进行加载。

1.2.3 破坏双亲委派模型（选看）

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

破坏该模型的历史：

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

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

• 双亲委派模型的第二次“被破坏”是由这个模型自身的缺陷导致的

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

    这并非是不可能出现的事情，一个典型的例子便是JNDI服务，JNDI现在已经是Java的标准服务，它的代码由启动类加载器来完成加载（在JDK 1.3时加入到rt.jar的），肯定属于Java中很基础的类型了。但JNDI存在的目的就是对资源进行查找和集中管理，它需要调用由其他厂商实现并部署在应用程序的ClassPath下的JNDI服务提供者接口（Service Provider Interface，SPI）的代码

    • 现在问题来了，启动类加载器是绝不可能认识、加载这些代码的，那该怎么办？

      • 为了解决这个困境，Java的设计团队只好引入了一个不太优雅的设计：线程上下文类加载器（Thread Context ClassLoader）。这个类加载器可以通过java.lang.Thread类的setContext-ClassLoader()方法进行设置，如果创建线程时还未设置，它将会从父线程中继承一个，如果在应用程序的全局范围内都没有设置过的话，那这个类加载器默认就是应用程序类加载器。

      • 有了线程上下文类加载器，程序就可以做一些“舞弊”的事情了。JNDI服务使用这个线程上下文类加载器去加载所需的SPI服务代码，这是一种父类加载器去请求子类加载器完成类加载的行为，这种行为实际上是打通了双亲委派模型的层次结构来逆向使用类加载器，已经违背了双亲委派模型的一般性原则，但也是无可奈何的事情。Java中涉及SPI的加载基本上都采用这种方式来完成，例如JNDI、JDBC、JCE、JAXB和JBI等。不过，当SPI的服务提供者多于一个的时候，代码就只能根据具体提供者的类型来硬编码判断，为了消除这种极不优雅的实现方式，在JDK 6时，JDK提供了java.util.ServiceLoader类，以META-INF/services中的配置信息，辅以责任链模式，这才算是给SPI的加载提供了一种相对合理的解决方案。

• 双亲委派模型的第三次“被破坏”是由于用户对程序动态性的追求而导致的

  • 这里所说的“动态性”指的是一些非常“热”门的名词：代码热替换（Hot Swap）、模块热部署（Hot Deployment）等。说白了就是希望Java应用程序能像我们的电脑外设那样，接上鼠标、U盘，不用重启机器就能立即使用，鼠标有问题或要升级就换个鼠标，不用关机也不用重启。对于个人电脑来说，重启一次其实没有什么大不了的，但对于一些生产系统来说，关机重启一次可能就要被列为生产事故，这种情况下热部署就对软件开发者，尤其是大型系统或企业级软件开发者具有很大的吸引力。

Java社区关于模块化规范的历史：

• 早在2008年，在Java社区关于模块化规范的第一场战役里，由Sun/Oracle公司所提出的JSR-294、JSR-277规范提案就曾败给以IBM公司主导的JSR-291（即OSGi R4.2）提案。尽管Sun/Oracle并不甘心就此失去Java模块化的主导权，随即又再拿出Jigsaw项目迎战，但此时OSGi已经站稳脚跟，成为业界“事实上”的Java模块化标准。曾经在很长一段时间内，IBM凭借着OSGi广泛应用基础让Jigsaw吃尽苦头，其影响一直持续到Jigsaw随JDK 9面世才算告一段落。而且即使Jigsaw现在已经是Java的标准功能了，它仍需小心翼翼地避开OSGi运行期动态热部署上的优势，仅局限于静态地解决模块间封装隔离和访问控制的问题，，现在我们先来简单看一看OSGi是如何通过类加载器实现热部署的：

  • OSGi实现模块化热部署的关键是它自定义的类加载器机制的实现，每一个程序模块（OSGi中称为Bundle）都有一个自己的类加载器，当需要更换一个Bundle时，就把Bundle连同类加载器一起换掉以实现代码的热替换。在OSGi环境下，类加载器不再双亲委派模型推荐的树状结构，而是进一步发展为更加复杂的网状结构，当收到类加载请求时，OSGi将按照下面的顺序进行类搜索：

    1）将以java.*开头的类，委派给父类加载器加载。

    2）否则，将委派列表名单内的类，委派给父类加载器加载。

    3）否则，将Import列表中的类，委派给Export这个类的Bundle的类加载器加载。

    4）否则，查找当前Bundle的ClassPath，使用自己的类加载器加载。

    5）否则，查找类是否在自己的Fragment Bundle中，如果在，则委派给Fragment Bundle的类加载器加载。

    6）否则，查找Dynamic Import列表的Bundle，委派给对应Bundle的类加载器加载。

    7）否则，类查找失败。

    上面的查找顺序中只有开头两点仍然符合双亲委派模型的原则，其余的类查找都是在平级的类加载器中进行的，关于OSGi的其他内容，笔者就不再展开了。

  本节中虽然使用了“被破坏”这个词来形容上述不符合双亲委派模型原则的行为，但这里“被破坏”并不一定是带有贬义的。只要有明确的目的和充分的理由，突破旧有原则无疑是一种创新。正如OSGi中的类加载器的设计不符合传统的双亲委派的类加载器架构，且业界对其为了实现热部署而带来的额外的高复杂度还存在不少争议，但对这方面有了解的技术人员基本还是能达成一个共识，认为OSGi中对类加载器的运用是值得学习的，完全弄懂了OSGi的实现，就算是掌握了类加载器的精粹。

二.Java模块化系统

• 引入的版本:

  • 在JDK 9中引入的Java模块化系统（Java Platform Module System，JPMS）是对Java技术的一次重要升级，为了能够实现模块化的关键目标——可配置的封装隔离机制，Java虚拟机对类加载架构也做出了相应的变动调整，才使模块化系统得以顺利地运作。

• Java的模块定义还包含以下内容：

  • 依赖其他模块的列表。

  • 导出的包列表，即其他模块可以使用的列表。

  • 开放的包列表，即其他模块可反射访问模块的列表。

  • 使用的服务列表。

  • 提供服务的实现列表。

• 模块化-可配置的封装隔离机制 带来的好处：

  • 避免了很大一部分由于类型依赖而引发的运行时异常

    • JDK9之前因为基于路径加载类，一旦类路径缺失对应依赖，那就只能等程序发生该类型的加载、链接时才能报错

      • 在JDK9之前是基于类路径（ClassPath）来查找依赖的，如果类路径中缺失了运行时依赖的类型，那就只能等程序运行到发生该类型的加载、链接时才会报出运行的异常。

    • JDK9之后如果启用模块化进行封装，模块可以声明对其他模块的显示依赖，让JVM在启动时验证依赖关系是否完备，如果缺失则直接报错

      • 而在JDK 9以后，如果启用了模块化进行封装，模块就可以声明对其他模块的显式依赖，这样Java虚拟机就能够在启动时验证应用程序开发阶段设定好的依赖关系在运行期是否完备，如有缺失那就直接启动失败，从而避免了很大一部分由于类型依赖而引发的运行时异常。

  • 对于public类型，模块提供了更精细的可访问性控制，必须明确声明哪些public类型可以被哪些模块访问，否则不能让所有代码访问到public

    • 可配置的封装隔离机制还解决了原来类路径上跨JAR文件的public类型的可访问性问题。

    • JDK 9中的public类型不再意味着程序的所有地方的代码都可以随意访问到它们，模块提供了更精细的可访问性控制，必须明确声明其中哪一些public的类型可以被其他哪一些模块访问，这种访问控制也主要是在类加载过程中完成的，具体内容笔者在前文对解析阶段的讲解中已经介绍过。

2.1 模块兼容性

这里讲的兼容性，主要指以下特性：

• 兼容：传统的类路径查找机制

  • 为了使可配置的封装隔离机制能够兼容传统的类路径查找机制，JDK 9提出了与“类路径”（ClassPath）相对应的“模块路径”（ModulePath）的概念。

    • 简单来说，就是某个类库到底是模块还是传统的JAR包，只取决于它存放在哪种路径上。

      • 只要是放在类路径上的JAR文件，无论其中是否包含模块化信息（是否包含了module-info.class文件），它都会被当作传统的JAR包来对待；

      • 相应地，只要放在模块路径上的JAR文件，即使没有使用JMOD后缀，甚至说其中并不包含module-info.class文件，它也仍然会被当作一个模块来对待。

  • 记忆版：

    • 为了能够兼容传统的类路径查找机制，JDK 9提出了与“类路径”（ClassPath）相对应的“模块路径”（ModulePath）的概念，某个类库到底是模块还是传统的JAR包，只取决于它存放在哪种路径上。

  • JDK9通过如下3条规则保证了即使Java应用依然使用传统的类路径，升级到JDK 9对应用来说几乎不会有任何感觉，项目也不需要专门为了升级JDK版本而去把传统JAR包升级成模块

    • JAR文件在类路径的访问规则：所有类路径下的JAR文件及其他资源文件，都被视为自动打包在一个匿名模块（Unnamed Module）里，这个匿名模块几乎是没有任何隔离的，它可以看到和使用类路径上所有的包、JDK系统模块中所有的导出包，以及模块路径上所有模块中导出的包。

    • 模块在模块路径的访问规则：模块路径下的具名模块（Named Module）只能访问到它依赖定义中列明依赖的模块和包，匿名模块里所有的内容对具名模块来说都是不可见的，即具名模块看不见传统JAR包的内容。

    • JAR文件在模块路径的访问规则：如果把一个传统的、不包含模块定义的JAR文件放置到模块路径中，它就会变成一个自动模块（Automatic Module）。尽管不包含module-info.class，但自动模块将默认依赖于整个模块路径中的所有模块，因此可以访问到所有模块导出的包，自动模块也默认导出自己所有的包。

• 不兼容：Java模块化系统目前不支持在模块定义中加入版本号来管理和约束依赖，本身也不支持多版本号的概念和版本选择功能。

2.2 模块化下的类加载器

  为了保证兼容性，JDK 9并没有从根本上动摇从JDK 1.2以来运行了二十年之久的三层类加载器架构以及双亲委派模型。但是为了模块化系统的顺利施行，模块化下的类加载器仍然发生了一些应该被注意到变动，主要包括以下几个方面：

• 1.扩展类加载器（Extension Class Loader）被平台类加载器（Platform Class Loader）取代。

  • 这其实是一个很顺理成章的变动，既然整个JDK都基于模块化进行构建（原来的rt.jar和tools.jar被拆分成数十个JMOD文件），其中的Java类库就已天然地满足了可扩展的需求

    • 那自然无须再保留\lib\ext目录，此前使用这个目录或者java.ext.dirs系统变量来扩展JDK功能的机制已经没有继续存在的价值了，用来加载这部分类库的扩展类加载器也完成了它的历史使命。

  • 类似地，在新版的JDK中也取消了\jre目录，因为随时可以组合构建出程序运行所需的JRE来

    • 譬如假设我们只使用java.base模块中的类型，那么随时可以通过以下命令打包出一个“JRE”

      
      jlink -p $JAVA_HOME/jmods --add-modules java.base --output jre
      
      

• 2.平台类加载器和应用程序类加载器都不再派生自java.net.URLClassLoader

  • 如果有程序直接依赖了这种继承关系，或者依赖了URLClassLoader类的特定方法，那代码很可能会在JDK 9及更高版本的JDK中崩溃。

  • 现在启动类加载器、平台类加载器、应用程序类加载器全都继承于jdk.internal.loader.BuiltinClassLoader，在BuiltinClassLoader中实现了新的模块化架构下类如何从模块中加载的逻辑，以及模块中资源可访问性的处理。

    ---

          jdk9之前的类加载器继承架构
    

image.png

JDK 9及以后的类加载器继承架构

image.png

---

• 3.启动类加载器现在是在Java虚拟机内部和Java类库共同协作实现的类加载器，尽管有了BootClassLoader这样的Java类，但为了与之前的代码保持兼容，所有在获取启动类加载器的场景（譬如Object.class.getClassLoader()）中仍然会返回null来代替，而不会得到BootClassLoader的实例。

image.png

• 4.JDK 9中虽然仍然维持着三层类加载器和双亲委派的架构，但类加载的委派关系也发生了变动。

  • 当平台及应用程序类加载器收到类加载请求，在委派给父加载器加载前，要先判断该类是否能够归属到某一个系统模块中，如果可以找到这样的归属关系，就要优先委派给负责那个模块的加载器完成加载，也许这可以算是对双亲委派的第四次破坏。