JVM 类文件 类装入器 初级概念学习

.java 文件 经过 java命令 后形成 .class文件，称为类文件。

类文件是符合JVM 规范的二进制文件，在送往JVM 虚拟机之前，

类文件是没有经过链接类的，类还是类自己，而没有和依赖关

系的其他类产生链接关系。 jar是类文件的容器，里面存放的当然也是无

链接关系的类文件集合了。

这样做的好处应用程序提供了高度灵活性。例如，在编写应用程序以使

用接口时，可以到运行时才指定其实际实现。这样做的坏处是在JVM虚拟机

读这些代码的时候，必须要链接他们。所谓的读，是指JVM虚拟机，把链接后

的类文件放到它虚拟的内存区中去。JVM 是堆栈体系结构结构，这样话，放到

JVM 的所谓内存，就是放到某个堆栈中去，以便让JVM 虚拟CPU 开始读。

其实好处坏处是相对的说话，因为JVM 虚拟CPU 读JVM 二进制文件，必须要把

二进制文件联结，就像C/C++ 那样，才可以生成让真正的计算机的CPU执行的文件。

这么说的目的，无非是让一件事，分成两个概念，也就是分成两个层，因为，我们

要在一个层上做动做，实现我们的目的----增加灵活性(Java反射机制，有对这层操作

的API)。这样说，不知道是不是难于理解。打个比方，甲要送信给乙，甲可以直接送

到乙，或者通过丙再转到乙，丙就可以对这信加点东西了。

JVM制定了链接的规范，链接是一个每个装入的类都可能拥有其它所依赖的类，

所以装入过程是递归的。这个装入程序的设计，可以按照触发器的设计思想来写。在

装入并初始化类时，JVM 内部会完成许多操作，包括解码二进制类格式、检查与其它

类的兼容性、验证字节码操作的顺序以及最终构造 java.lang.Class 实例来表示新类。

这个 Class 对象成了 JVM 创建新类的所有实例的基础，这个 Class 实例来表示的新

类，有多个副本，每个副本都有其自己的 Class 实例，即这些副本都共享同一个类

名，但对 JVM 而言它们都是独立的类。

上面讲的装入程序就称为类装入器，类装入器不是唯一的，有扩展类装入器（装

入标准 Java 扩展 API 中的类），系统类装入器（一般类路径上的类包括应用程序

类）。我们还可以自己定一个类装入器，只要派生自 java.lang.ClassLoader 类，该类

对从字节数组构建内部类表示（ java.lang.Class 实例）提供了核心支持。每个构造好

的类在某种意义上是由装入它的类装入器所“拥有”。类装入器通常保留它们所装入

类的映射，从而当再次请求某个类时，能通过名称找到该类。 每个类装入器还保留对

父类装入器的引用，这样就定义了类装入器树，树根为引导程序装入器。

J2EE 应用程序都需要拥有一个独立的类装入器以防止一个应用程序中的类干

扰其它应用程序，所以会会使用多个应用程序类装入器。被Web application容器共享

的类可以由一个类装入器实现，对于各自的Web application，分别由不同类装入器装

入。在这种环境中，跟踪合适的装入器以用于请求新类会很混乱,为此，在J2EE中将

setContextClassLoader 方法和 getContextClassLoader 方法添加到了

java.lang.Thread 类中。这些方法允许该框架设置类装入器，使得在运行每个应用程序

中的代码时可以将类装入器用于该应用程序。 这样做会使得处理 JVM 类路径时，会

很复杂，我想起来就觉的头疼，看来这J2EE类装入器还不是怎么好写的。