小研究 - JＶＭ的类装载机制

陆氪和他的那些代码

已于 2023-08-26 16:15:49 修改

阅读量122

点赞数 1

分类专栏： # 小研报文章标签：类装载 JAVA Java虚拟机命名空间

于 2023-08-26 16:15:22 首次发布

本文链接：https://blog.csdn.net/Dream_Weave/article/details/132427747

版权

小研报专栏收录该内容

73 篇文章 0 订阅

订阅专栏

本文通过对一个类装载实例的分析，阐明了 Java虚拟机的类装载的代理机制和由此定义的命名空间，指出了类装载机制在容器/组件/抽象框架结构中的作用。

1 引言

Java虚拟机 JVM）的类装载就是指将包含在类文件中的字节码装载到JVM中，并使其成为JVM一部分的过程口。JVM 的类动态装载技术能够在运行时刻动态地加载或者替换系统的某些功能模块，而不影响系统其他功能模块的正常运行。类的动态加载是 JVM 的一项非常重要的技术，是许多企业 Java技术的基础，应用它可以以相对简单、灵活的形式来构建复杂的企业级应用。类的动态加载技术和具有部分类似功能的动态链接库技术相比，具有灵活、面向对象、平台独立等优点。

2 实例

下面是有关 JVM 的类动态装载技术的一个例子，包括：一个类装载器（CL. java）、一个接口（A. java）和一个实现类B. java）。代码的主要部分如下：

／ＣＬ．ｊａｖａ
ｐｕｂｌｉｃｃｌａｓｓＣＬｅｘｔｅｎｄｓＣｌａｓｓＬｏａｄｅｒ｛
　ｐｒｏｔｅｃｔｅｄＣｌａｓｓｆｉｎｄＣｌａｓｓ）Ｓｔｒｉｎｇｎａｍｅ）ｔｈｒｏｗｓＣｌａｓｓＮｏｔ－
ＦｏｕｎｄＥｘｃｅｐｔｉｏｎ｛
ｂｙｔｅ［］ｂ＝ｌｏａｄＣｌａｓｓＤａｔａ（ｎａｍｅ）；
ｒｅｔｕｒｎｄｅｆｉｎｅＣｌａｓｓ（ｎａｍｅ，ｂ，０，ｂ．ｌｅｎｇｔｈ）；
　｝
　ｐｒｉｖａｔｅｂｙｔｅ［］ｌｏａｄＣｌａｓｓＤａｔａ（Ｓｔｒｉｎｇｎａｍｅ）ｔｈｒｏｗｓＣｌａｓｓ－
ＮｏｔＦｏｕｎｄＥｘｃｅｐｔｉｏｎ｛
　／／获取并返回指定类的字节码…
　｝
　ｐｕｂｌｉｃｓｔａｔｉｃｖｏｉｄｍａｉｎ（Ｓｔｒｉｎｇａｒｇｓ［］）ｔｈｒｏｗｓＥｘｃｅｐｔｉｏｎ｛
Ｃｌａｓｓｂ＝ｎｅｗＣＬ（）．ｌｏａｄＣｌａｓｓ（ａｒｇ［０］）；
Ａａ＝（Ａ）ｂ．ｎｅｗＩｎｓｔａｎｃｅ（）；／／５９行
ａ．ｆ（）
　｝
｝
／／Ａ．ｊａｖａ
ｐｕｂｌｉｃｉｎｔｅｒｆａｃｅＡ｛
　ｐｕｂｌｉｃｖｏｉｄｆ（）；
｝
／／Ｂ．ｊａｖａ
ｐｕｂｌｉｃｃｌａｓｓＢｉｍｐｌｅｍｅｎｔｓＡ ｛
　ｐｕｂｌｉｃｖｏｉｄｆ（）｛
Ｓｙｓｔｅｍ．ｏｕｔ．ｐｒｉｎｔｌｎ（＂Ｂ．ｆ（）＂）；
　｝
｝

其中，实现类B不在类路径（CLASSPATH）中，并且是到运行时才给出的。用 JDK 1.2以上版本的 Java编译器编译以上代码，然后运行：

＞ｊａｖａＣＬＢ

如果如下：

ｂ．ｆ（）

可见，类装载器CL已经成功地将类B装载到JVM中。JVM也成功地激活了类 B中的方法。在这个过程中，Java的类装载子系统实现上完成了三个步骤：装载、链接和初始化。其中链接又可以分为校验（Verification）、准备Prepara tion）和决定Resolution）三步。除决定外，其他步骤是严格按顺序完成的。各步骤的主要工作如下：

装载：查找和导入类或接口的二进制数据。

链接：执行下面的校验、准备和决定步骤，其中决定步骤是可选的。

校验：检查导入类或接口的二进制数据的正确性。

准备：给类的静态变量分配并初始化存储空间。

决定：将符号引用转成直接引用。

初始化：激活类的静态变量的初始化Java代码和静态Java代码块。

JVM 的类装载子系统的更多介绍可参见资料。

根据Java2的扩展机制3，将CL. class文件打包成clja文件，并将cl jar文件放在Java执行环境的扩展目录通常为<JAVA-HOME> /jre/lib/ext具体可查看运行时环境变量java ext dirs值）中。

当再次执行以上程序：

> java CL B

结果如下：（第59行已在代码中标出）

Ｅｘｃｅｐｔｉｏｎ ｉｎ ｔｈｒｅａｄ ＂ｍａｉｎ＂ ｊａｖａ．ｌａｎｇ．ＮｏＣｌａｓｓＤｅｆ－
ＦｏｕｎｄＥｒｒｏｒ：Ａ
ａｔＣＬ．ｍａｉｎ（ＣＬ．ｊａｖａ：５９）

抛出的例外指明类A没有找到，可是类A确实在类路径（CLASSPATH）中。而在将cl jar文件放在Java执行环境的扩展目录之前，程序运行正确。那么，从类路径CLASSPATH装载类和从Java扩展目录装载类到底有什么不同呢？

3 分析

3.1 类装载的代理机制

Java2的类装载模型是一种代理（delegation，有人译成委托）模型3.当JVM要求类装载器L1装载一个类时，L1首先将这个类装载请求转发给他的父装载器。只有当父装载器没有装载并无法装载这个类时，L1才获得装载这个类的机会。这样，所有类装载器的代理关系构成了一棵树。树的根是类的根装载器（bootstrap Class Loader），在JVM中他以"null表示。除根装载器以外的类装载器有且仅有一个父装载器。在创建一个装载器时，如果没有显式地给出父装载器，那么JVM将默认系统装载器为其父装载器。Java2的基本的类装载器代理结构如图1所示。

根Bootstrap）装载器：从sun boot class path装载运行时类库的核心代码；是JVM的一部分，没有父装载器。

扩展（Extension）装载器：从 java ext dirs 扩展目录）中装载代码；父装载器为根装载器；用纯Java代码实现。

系统（System orApplication）装载器：从java class path（CLASSPATH环境变量）装载代码；父装载器为扩展装载器；用纯Java代码实现；是用户自定义类装载器的缺省父装载器。

小应用程序（Applet）装载器：从用户指定的网络上的特定目录装载小应用程序代码；父装载器为系统装载器。

一个好的类装载器应该满足以下二个性质2

1）对于相同的类名，类装载器应该返回同一个类对象。

2）如果类装载器 L1将装载类 C的请求转给类装载器L2，那么对于以下的类或接口 T,L1和 L2应该返回同一个类对象：

aT为 C的直接超类；

b）T 为 C的直接超接口；

cT为 C的成员变量的类型；

d）T为C的成员函数或构建器的参数类型；

e）T为C的成员函数的返回类型

每个已经装载到JVM中的类都隐含有装载他的类装载器的信息。类方法getC lassLoader可以得到装载这个类的类装载器。已经装载到JVM中的类不能更改他的类装载器。一个类装载器认识的类包括他的父装载器认识的类和他自己装载的类。一个类装载器认识的类是他自己装载的类的超集。

Java2中的类的装载过程是代理装载的过程。比如：W el浏览器中的JVM需要装载一个小应用程序SampleApplet JVM调用小应用程序装载器ACL来完成装载。ACL首先请求他的父装载器，即系统装载器装载SampleApplet由于SampleA pplet不在系统装载器的装载路径中，所以系统装载器没有找到这个类，也就没有装载成功。接着ACL自己装载SampleApplet ACL通过网络成功地找到了SampleApplet class文件并将他导入到了JVM中。在装载过程中，JVM发现SampleApplet是从超类java applet Applet继承的。所以JVM再次调用ACL来装载java applet Applet类。ACL又再次按上面的顺序装载Applet类，结果ACL发现他的父装载器已经装载了这个类，所以ACL就直接将这个已经装载的类返回给了JVM，完成了Applet类的装载。接下来， Applet类的超类也一样处理。最后， SampleA pplet及所有有关的类都装载到了 JVM 中。

3.2 Java的命名空间

从类装载的代理机制可以看出：在Java中，不同的类装载器定义了不同的命名空间。并且这些由类装载器定义的命名空间会有部分重叠，这保证了面向对象技术的一些重要特性，比如继承和多态的实现同。可以想象，如果没有这种父装载器首先获得装载权利的代理机制，而是所有的类装载器都各自装载，那么各个类装载器装载到JVM中的类都相互无关。JVM 本身的一些基本的类，如java lang. Object类在每个类装载器的命名空间中都得保留一个副本。并且更为严重的是，这些不同命名空间中的类被完全隔离开来了，他们之间不能进行任何形式的交互，也就不存在继承、多态等一些面象对象的关键特性。

3.3 解决问题

理解了类装载的代理机制和Java的命名空间后，再看本文前面的实例中抛出的例外，就很显然了。将cl jar文件放在Java执行环境的扩展目录以前，从命令行运行程序 CL,JVM首先调用系统类装载器装载CL类，由于系统装载器的父装载器是扩展类装载器，所以扩展类装载器先于系统类装载器获得装载CL的机会，可是扩展装载器在他的装载目录中没有找到 CL类的定义，接着，系统类装载器获得装载 CL类的机会，由于CL类在系统路径中，所以系统类装载器最终装载了类CL。类 A在类CL中被引用，其装载过程和类CL的装载过程完全一致。

从 java命名空间的划分来看，在将 cl jar文件放在 Java执行环境的扩展目录以前和以后。类CL和类A在Java的命名空间的位置如图2所示。

对类装载的代理机制和 Java的命名空间的理解能够加深对Java语言的认识。比如：有时会听到这样的表述：“一个Java类可由它的全名包名+.+类名）唯一标识”。这种表述只有在同一命名空间中是正确的，如果要在所有命名空间中都成立，须如下表述：“一个 Java类可由它的全名包名+.+类名）和它的类装载器唯一标识”。

4 应用

4.1 容器组件抽象框架

抽象框架是容器和由容器管理的组件之间的某种约定。通常，容器为组件提供了一些公共服务，如激活、生命周期、持久性、安全、事务等回。比如：一个Java兼容的WEB浏览器给小应用程序提供了激活和生命周期服务。这时，java applet包就是抽象框架，用户写的特定的小应用程序就是组件，浏览器就是容器。注意：java applet包中的Applet类是抽象的。容器和组件间的接口的定义通常是抽象的，这也是为什么称抽象框架的原因。

4.2 类装载器和容器组件抽象框架

为了实现容器组件抽象框架这种架构，关键的一点是要确保定义抽象框架的抽象类由唯一的类装载器装载，并且对所有需要引用抽象框架的抽象类的类装载器可见。这样就保证了容器中引用的抽象框架和组件中引用的抽象框架是同一个抽象框架，也满足了面向对象的继承、多态特性。通常，定义抽象框架的抽象类由实现他的组件的类装载器的父装载器来装载。如在Servlet兼容的WEB服务器中，将装载Servle抽象框架类的某个核心类装载器作为所有 Servlet类的父装载器。容器 /组件 /抽象框架和类装载器的关系如图3所示。图3可以看出，类装载器的代理机制从逻辑上保证了容器/组件抽象框架这三者关系的正确实现。