虚拟机类加载机制（第七章）

czq
139 阅读9分钟

类加载的时机

类加载过程.webp

《Java虚拟机规范》规定了有且只有以下六种情况必须立即对类进行初始化。

  1. 遇到new、getstatic、putstatic、或invokestatic这四条字节码指令时，如果类型没有进行初始化，则需要先触发其初始化阶段。能够生成这四条指令的Java代码场景有：

    • 使用new关键字实例化对象的时候
    • 读取或设置一个类型的静态字段（常量除外）
    • 调用一个类型的静态方法的时候

  2. 使用java.lang.reflect包的方法对类型进行反射调用的时候，如果类型没有进行过初始化，则需先触发其初始化。

  3. 初始化类的时候，父类没有进行初始化，需先初始化类型。

  4. 当虚拟机启动的时，用户需要执行指定的主类时，需先初始化这个类。

  5. 当使用JDK7新加入的动态语言支持时，如果一个java.lang.invoke.MethodHandle实例最后的解析结果为REF_getStatic、REF_putStatic\REF_invokeStatic\REF_newInvokeSpecial这四种类型的方法句柄，并且这个方法的句柄对应的类没有进行初始化，则需先初始化这个类。

  6. 当接口中定义了JDK8新加入的默认方法（default关键字修饰的方法）时，如果这个接口的实现类进行了初始化，则该接口必须在实现类之前初始化。

类加载的过程

加载

“加载”阶段是整个“类加载”过程中的一个阶段，Java虚拟机需要完成以下三件事：

  1. 通过一个类的权限定名来获取定义此类的二进制字节流。
  2. 将这个字节流的静态存储结构转化为方法区的运行时数据结构。
  3. 在内存中生成一个代表这个类的java.lang.Class对象，作为方法区这个类的各种数据的访问入口。

**注：对于数组，它由Java虚拟机直接在内存中动态构造出来，数组的泛型由类加载器加载。

验证

验证是连接阶段的第一步，这一阶段的目的是确保Class文件的字节流中包含的信息符合《Java虚拟机规范》，保证这些信息不回威胁虚拟机的自身安全。验证阶段大致有以下四个阶段：

  1. 文件格式验证：如是否以魔数开头、主次版本号、常量池中是否有不被支持的常量类型等等
  2. 元数据验证：这个阶段是对字节码描述的信息进行语义分析，如这个类是否有父类，这个类是否继承了不允许继承的类等等。
  3. 字节码验证：主要目的是通过数据流分析和控制流分析，确定程序语义是合法的、符合逻辑的。
  4. 符号引用验证：符号引用验证的目的是确保解析行为能正常执行，如通过字符串全限定名能否找到对应的类。

准备

准备阶段时正式为类中定义的变量（即静态变量）分配内存并设置类变量的初始值。首先注意这里的实例变量是在实例初始化时随着对象一起分配在Java堆中，其次就是在准备阶段，如一个int类型的类变量，设置的初始值为0，而非定义的xxx，xxx是在类构造器()方法中。final static的值将在ConstantValue属性中设置。

解析

解析阶段是Java虚拟机将常量池内符号引用替换为直接引用的过程。

  • 符号引用：符号引用一组符号来描述所引用的目标，符号可以是任何形式的字面量，只要使用时能无歧义地定位到目标即可。符号引用与虚拟机实现的内存布局无关，引用的目标并不一定时已经加载到虚拟机内存当中的内容。
  • 直接引用：直接引用时可以直接指向目标的指针、相对偏移量或者时一个能间接定位到目标的句柄。直接引用与虚拟机实现的内存布局直接相关的，如果有直接引用，那引用的目标必定已经在虚拟机的内存中存在。

初始化

类的初始化阶段时类加载过程的最后一个步骤，此时Java虚拟机才真正开始执行类中编写的Java程序代码。

类加载器

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

类与类加载器

对于任意一个类，都必须由加载它的类加载器和这个类本身一起共同确定其在Java虚拟机中的唯一性，每一个类加载器，都拥有一个独立的类名称空间。 这里的相等，包括代表类的class对象的equals()方法、isAssignableFrom()方法、isInstance()方法的返回结果，也包括了使用instanceof关键字做所属对象关系判定等各种情况。

双亲委派模型

双亲委派模型的工作过程是：如果一个类加载器收到了类加载的请求，它首先不会自己去尝试加载这个类，而是把这个请求委派给父类加载器去完成，每一个层次的类加载器都是如此，因此所有的加载请求最终都应该传送到最顶层的启动类加载器中，只有当父类加载器反馈自己无法完成这个加载请求时，子加载器才会尝试自己去完成加载。

站在Java虚拟机的角度看，只存在两种不同的类加载器：一种时启动类加载器，有C++语言实现，是虚拟机自身的一部分；另外一种就是其他所有的类加载器，这些类加载器由Java语言实现，独立存在于虚拟机外部，并且全部继承自抽象类java.lang.ClassLoader。

站在Java开发人员来说，类加载器划分得更细致一些。自JDK1.2以来，Java一直保持着三层类加载器、双亲委派的类加载架构。

image.png 启动类加载器： 这个类加载器负责加载存放在<JAVA_HOME>/lib目录，或者被-Xbootclasspath参数指定的路径中存放的，而且是Java虚拟机能够识别的类库加载到虚拟机的内存中。启动类加载无法直接被Java程序直接引用，用户在编写自定义类加载器时，如果需要把加载请求委派给启动类加载器去处理，那直接使用null代替即可。

拓展类加载器： 这个类加载器是在类sun.misc.Launcher$ExtClassLoader中以Java代码的形式实现的。它负责的<JAVA_HOME>\lib\ext目录中，或者被java.ext.dirs系统变量所指定的路径中所有的类库。由于拓展类加载器是Java代码实现的，开发者可以直接在程序中使用拓展类加载器来加载class文件。

应用程序加载器： 这个类加载器由sun.misc.Launcher$AppClassLoader来实现。由于应用程序类加载器时ClassLoader类中的getSstem-ClassLoadser()方法的返回值，所以有些场合中也称为“系统类加载器”。它负责加载用户类路径（classpath）上所有的类库。

自定义类加载器： 用户可以加入自定义的类加载器来进行拓展，典型的如增加除了磁盘位置之外的class文件来源，或者通过类加载器实现类的隔离，重载等功能。

破坏双亲委派模型

第一次破坏： 在 jdk 1.2 之前，那时候还没有双亲委派模型，不过已经有了 ClassLoader 这个抽象类，所以已经有人继承这个抽象类，重写 loadClass 方法来实现用户自定义类加载器。而在 1.2 的时候要引入双亲委派模型，为了向前兼容， loadClass 这个方法还得保留着使之得以重写，新搞了个 findClass 方法让用户去重写，并呼吁大家不要重写 loadClass 只要重写 findClass。

这就是第一次对双亲委派模型的破坏，因为双亲委派的逻辑在 loadClass 上，但是又允许重写 loadClass，重写了之后就可以破坏委派逻辑了。

第二次破坏： 第二次破坏指的是 JNDI、JDBC 之类的情况。

首先得知道什么是 SPI(Service Provider Interface)，它是面向拓展的，也就是说我定义了个规矩，就是 SPI ，具体如何实现由扩展者实现。

像我们比较熟的 JDBC 就是如此。MySQL 有 MySQL 的 JDBC 实现，Oracle 有 Oracle 的 JDBC 实现，我 Java 不管你内部如何实现的，反正你们这些数据库厂商都得统一按我这个来，这样我们 Java 开发者才能容易的调用数据库操作，所以在 Java 核心包里面定义了这个 SPI。而核心包里面的类都是由启动类加载器去加载的，但它的手只能摸到\lib或Xbootclasspath指定的路径中，其他的它鞭长莫及。而 JDBC 的实现类在我们用户定义的 classpath 中，只能由应用类加载器去加载，所以启动类加载器只能委托子类来加载数据库厂商们提供的具体实现，这就违反了自下而上的委托机制。

具体解决办法是搞了个线程上下文类加载器，通过setContextClassLoader()默认情况就是应用程序类加载器，然后利用Thread.current.currentThread().getContextClassLoader()获得类加载器来加载。

第三次破坏： 这次破坏是为了满足热部署的需求，不停机更新这对企业来说至关重要，毕竟停机是大事。OSGI 就是利用自定义的类加载器机制来完成模块化热部署，类加载器不再使用双亲委派模型推荐的树状结构，而是进一步发展为更加复杂的网状结构。

应用场景

Tomcat，类加载器架构，自己定义了多个类加载器，

  • 保证了同一个服务器的两个Web应用程序的Java类库隔离；
  • 保证了同一个服务器的两个Web应用程序的Java类库又可以相互共享；比如多个Spring组织的应用程序不能共享，会造成资源浪费；
  • 保证了服务器尽可能保证自身的安全不受不受部署Web应用程序影响；
  • 支持JSP应用的服务器，大多需要支持热替换(HotSwap)功能。

OSGi(Open Service GateWay Initiative)，是基于Java语言的动态模块化规范。已成为Java世界的“事实上”的模块化标准，最为熟悉的案例的Eclipse IDE。

\

avatar
文章
阅读
粉丝