java虚拟机类加载机制， Java模块化系统（二）

java虚拟机类加载机制， Java模块化系统（二）

Java模块化系统

在jdk9中引入的 java模块化系统（Java Platform Module System，JPMS） 是对java技术的一次重要升级，为了能够实现模块化的关键目标——可配置的封装隔离机制，java虚拟机对类加载架构也做出了相应的变动调整，才是模块化系统得以顺利的运作。jdk9的模块不仅仅像之前的jar包那样只是简单的充当代码的容器，除了代码外，java的模块定义还包含以下内容：

• 依赖其他模块的列表
• 导出的包列表，即其他模块可以使用的列表
• 开放的包列表，即其他模块可反射访问模块的列表
• 使用的服务列表
• 提供服务的实现列表

可配置的封装隔离机制首先要解决jdk9之前基与 类路径（ClassPath） 来查找依赖的可靠性问题。此前，如果类路径中缺失了运行时依赖的类型，那就只能等程序运行到发生该类型的加载、链接时才会报出运行的异常。而在jdk9之后，如果启用了模块化进行封装，模块就可以声明对其他模块的显示依赖，这样java虚拟机就能够在启动时验证应用程序开发阶段设定好的依赖关系在运行期是否完备，如果缺失那就直接启动失败，从而避免了很大一部分（除非某个模块中原本公开的包中的某些类型移除掉了，但不修改模块的导出信息，还是能够启动了，但仍然会在运行期出现类加载异常）由于类型依赖而引发的运行时异常。

可配置的封装隔离机制还解决了原来类路径上跨JAR文件的public类型的可访问性问题。jdk9中的public类型不再意味着程序的所有代码都可以随意访问到他们，模块提供了更精细的可访问性控制，必须明确声明其中哪一些public的类型可以被其他哪一些模块访问，这种访问控制也主要是在类加载过程中完成的。

模块的兼容性

为了使可配置的封装隔离机制能够兼容传统的类路径查找机制，jdk9提出了与类路径相对应的 模块路径（ModulePath） 的概念。简单来说，就是某个类库到第是模块还是传统的JAR包，值取决于他存放在那种路径上。只要是放在类路径上的JAR包文件，无论其中是否包含模块化信息（是否包含了module-info.class文件），他都会被当做传统的jar包来对待；相应的，只要放在模块路径上的jar文件，即使没有使用JMOD后缀，甚至说其中并不包含module-info.class文件，他也仍然会被当做一个模块来对待。

模块化系统将按照以下规则来保证使用传统类路径依赖的java程序可以不经修改地直接运行在jdk9及以上的版本上，即使这些版本的jdk已经用模块来封装了JavaSE的标准类库，模块化系统的这套规则也仍然保证了传统程序可以访问到所有标准类库模块中导出的包。

• JAR文件在类路径的访问规则：所有类路径下的JAR文件以及其他资源文件，都被视为自动打包在一个匿名模块（Unnamed Module）里，这个匿名模块几乎是没有任何隔离的，它可以看到和使用类路径上所有的包、JDK系统模块中所有的导出包，以及模块路径上所有模块中导出的包
• 模块在模块路径的访问规则：模块路径下的具名模块（Named Module）只能访问到它依赖定义中列明依赖的模块和包，匿名模块里所有的内容对具名模块来说都是不可见的，即具名模块看不见传统JAR包的内容
• JAR文件在模块路径的访问规则：如果把一个传统的、不包含模块定义的JAR文件放置到模块路径中，它就会变成一个自动模块（Automatic Module）。尽管不包含module-info.class，但自动模块将默认依赖于整个模块路径中的所有模块，因此可以访问到所有模块导出的包，自动模块也是默认导出自己所有的包

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

除了向后兼容性外，随着JDK9模块化的引入，更值得关注的是它本身面临的模块间的管理和兼容性问题：如果同一个模块发行了多个不同的版本，那只能由开发者在编译打包时人工选择好正确版本的模块来保证依赖的准确性。Java模块化系统目前不支持在模块定义中加入版本号来管理和约束依赖，本身也不支持多版本号的概念和版本选择功能。前面这句话引来过很多的非议，但它确实是Oracle官方对模块化系统的明确目标说明。我们不论是在Java命令、Java类库的API亦或是《Java虚拟机规范》定义的Class文件格式里都能轻易的找到证据，表明模块版本应是编译、加载、运行期间都可以使用的。譬如输入 java --list-modules ，会得到明确待着版本号的模块列表：

java.base@12.0.1
java.compiler@12.0.1
.....

在JDK9时加入Class文件格式的Module属性，里面有module_version_index这样的字段，用户可以在编译时使用 javac --module-version 来指定模块版本，在Java类库API中也存在 java.lang.module.ModuleDescriptor.Version 这样的接口可以在运行时获取到模块的版本号。这一切迹象都证明了模块化系统对于版本号的支持本可以不局限在编译期。而官方却在Jigsaw的规范文件、JavaOne大会的宣讲和与专家的讨论列表中，都反复强调“JPMS的目的不是代替OSGi”，“JPMS不支持模块版本”这样的话语。

Oracle给出的理由是希望维持一个足够简单的模块化标准系统，避免技术过于复杂。但结合JCP执行委员会关于的Jigsaw投票中Oracle与IBM、RedHat的激烈冲突，实在很难让人信服这种设计知识单纯的基于技术原因，而不是厂家之间互相博弈妥协的结果。Jigsaw仿佛也在刻意地给OSGi让出一块生存空间，以换取IBM支持或者说不去反对Jigsaw，其代价是几乎宣告Java模块化系统不可能拥有像OSGi那样支持多版本模块并存、支持运行时热替换、热部署模块的能力，可这却往往是一个应用进行模块化的最大驱动力所在。如果要在JDK9之后实现这种目的，就只能将OSGi和JPMS混合使用， 如下图所示 ，这无疑带来了更高的复杂度。模块的运行时部署、替换能力没有内置在Java模块化系统和Java虚拟机之中，仍然必须通过类加载器去实现，不得不说是一个缺憾。

其实Java虚拟机内置的JVMTI接口（java.lang.instrument.Instrumentation）提供了一定程度的运行时修改类的能力（RedefineClass、RetransformClass），但这种修改能力会受到很多限制（只能修改已有方法，而不能添加新成员、修改已有成员的签名等），不可能直接用来实现OSGi那样的热替换和多版本并存，用在Intellij IDEA、Eclipse这些IDE上做HotSwap（是指IDE编辑方法的代码后不需要重启即可生效）倒是非常的合适。也曾有一个研究性项目Dynamic Code Evolution VM（ECVMD）探索过载虚拟机内部支持运行时类型替换的可行性，允许修改任意已加载到内存中的CLass，并不损失任何性能，但可惜已经很久没有更新了，最新版只支持到JDK7.

模块化下的类加载器

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

首先，是扩展类加载器（Extension Class Loader）被 平台类加载器（Platform Class Loader） 取代。这其实是一个很顺理成章的变动，既然整个JDK都基于模块化进行构建（原来的rt.jar和tools.jar被拆分成数十个JMOD文件），其中的Java类库就已天然地满足了可扩展的需求，那自然无须再保留<JAVA_HOME>\lib\ext目录，此前使用这个目录或者java.ext.dirs系统变量来拓展JDK功能的机制已经没有继续存在的价值了，用来加载这部分类库的扩展类加载器也完成了它的历史使命。类似地，在新版的JDK中也取消了<JAVA_HOME>\jre目录，因为随时可以组合构建出程序运行所需的JRE来，譬如假设我们只使用java.base模块中的类型，那么随时可以通过以下命令打出一个 “JRE”：

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

其次，平台类加载器和应用程序类加载器都不再派生自java.net.URLClassLoader，如果有程序直接依赖了这种继承关系，或者依赖了URLClassLoader类的特定方法，那代码很可能会在JDK9及更高版本的JDK中奔溃。现在启动类加载器、平台类加载器、应用程序类加载器全部继承与jdk.internal.loader.BuiltinClassLoader，在BuiltinClassLoader中实现了新的模块化架构下类如何从模块中加载的逻辑，以及模块中资源可访问性的处理。
两者的前后变化如下图所示：

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

最后，JDK9中虽然仍然维持着三层类加载器和双亲委派的架构，但类加载器的委派关系也发生了变化。当平台及应用程序类加载器收到了类加载请求，在委派给父类加载器加载前，要先判断该类是否能够归属到某个系统模块中，如果可以找到这样的归属关系，就要优先委派给负责那个模块的加载器完成加载，这也可以算是对双亲委派模型的第四次破坏。在JDK9以后的三层类加载器架构如下图所示：

和JDK9之前的架构相比有些许差异：

不一定是给父级加载，甚至可以绕过父级，交给更上级的父类进行加载。

在Java模块化系统明确规定了三个类加载器负责各自加载的模块，即上面所说的归属关系。

模块化系统就介绍到这里。

本文摘自周志明老师所著的《深入理解Java虚拟机》