Java虚拟机(五):虚拟机类加载机制

5.1 概述

          虚拟机把描述类的数据从Class文件加载到内存，并对数据进行校验、转换解析和初始化，最终形成可以被虚拟机直接使用的Java类型，这就是虚拟机的类加载机制。

5.2 类加载的时机

          类从被加载到虚拟机内存中开始，到卸载出内存为止，它的整个生命周期包括：加载、验证、准备、解析、初始化、使用和卸载7个阶段。其中验证、准备、解析3个部分统称为连接，这7个阶段的发生顺序如下图：

          加载、验证、准备、初始化和卸载这5个阶段的顺序是确定的，类的加载过程必须按照这种顺序按部就班地开始，而解析阶段则不一定：它在某些情况下可以在初始化阶段之后再开始，这是为了支持Java语言的运行时绑定(也称为动态绑定或晚期绑定)。

          虚拟机规范严格地规定有且只有5种情况必须立即对类进行"初始化"（而加载、验证、准备自然需要在此之前开始）：

           （1）遇到new、getstatic、putstatic或invokestatic这4条字节码指令时，如果类没有进行过初始化，则需要先触发其初始化。最常见的场景：使用new关键字实例化对       象的时候、读取或设置一个类的静态字段的时候（被final修饰、已在编译期把结果放入常量池的静态字段除外）、以及调用一个类的静态方法的时候。

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

           （3）当初始化一个类的时候，如果发现其父类还没有进行过初始化，则需要先触发其父类的初始化。

           （4）当虚拟机启动时，用户需指定一个要执行的主类(包含main()方法的那个类)，虚拟机会先初始化这个主类。

           （5）当使用JDK1.7的动态语言支持时，如果一个java.lang.invoke.MethodHandle实例最后的解析结果REF_getStatic、REF_putStatic、REF_inovkeStatic的方法句柄，并且这个方法句柄所对应的类没有进行过初始化，则需要先触发其初始化。

           这5种场景中的行为称为对一个类进行主动引用。除此之外，所有引用类的方式都不会触发初始化，称为被动引用。如：

           （1）通过子类引用父类的静态字段，不会导致子类初始化。

           （2）通过数组定义来引用类，不会触发此类的初始化。

           （3）常量在编译阶段会存入调用类的常量池中，本质上并没有直接引用到定义常量的类，因此不会触发定义常量的类的初始化。

5.3 类加载的过程

          主要讲述Java虚拟机中类加载的全过程，即加载、验证、准备、解析和初始化这五个阶段所执行的具体动作。

5.3.1 加载

          “加载”是“类加载”过程的一个阶段，在加载阶段，虚拟机需要完成以下3件事情：

          （1）通过一个类的全限定名来获取定义此类的二进制字节流。

          （2）将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构。

          （3）在内存中生成一个代表这个类的java.lang.Class对象，作为方法区这个类的各种数据的访问入口。       

5.3.2 验证

         验证是连接阶段的第一步，这一阶段的目的是为了确保Class文件的字节流中包含的信息符合当前虚拟机的要求，并且不会危害虚拟机自身的安全。

         验证主要包含文件格式验证、元数据验证、字节码验证、符号引用验证。

5.3.3 准备

         准备阶段是正式为类变量分配内存并设置类变量初始值的阶段，这些变量所使用的内存都将在方法区中进行分配。

5.3.4 解析

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

5.3.5 初始化

         类初始化阶段是类加载过程的最后一步。初始化阶段是执行类构造器<clinit>方法的过程。

5.4 类加载器

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

5.4.1 类与加载器

         类加载器虽然只用于实现类的加载动作，但它在Java程序中起到的作用却远远不限于类加载阶段。对于任意一个类，都需要由加载它的类加载器和这个类本身一同确立其在Java虚拟机中的唯一性，每一个类加载器，都拥有一个独立的类名称空间。通俗理解：比较两个类是否“相等”，只有在这两个类是由同一个类加载器的前提下才有意义，否则，即使这两个类来源于同一个Class文件，被同一个虚拟机加载，只要加载它们的类加载器不同，那这两个类就必定不相等。

5.4.2 双亲委派模型

          从Java虚拟机的角度来讲，只存在两种不同的类加载器：一种是启动类加载器（Bootstrap ClassLoader），这个类加载器使用C++语言实现，是虚拟机的一部分；另一种就是所有其它的类加载器，这些类加载器都由Java语言实现，独立于虚拟机外部，并全都继承自抽象类java.lang.ClassLoader。

         从Java开发人员的角度来看，大部分Java程序都会使用到以下3种系统提供的类加载器。

         （1）启动类加载器（Bootstrap ClassLoader）：负责将存放在<JAVA_HOME>\lib目录中，或者被-Xbootclasspath参数所指定的路径中的，并且虚拟机识别的类库加载到 虚拟机内存中。

         （2）扩展类加载器（Extension ClassLoader）：由sun.misc.Launcher$ExtClassLoader实现，它将负责加载<JAVA_HOME>\lib\ext目录中的，或者被java.ext.dirs系统变量所指定的所有类库，开发者可以直接使用扩展类加载器。

         （3）应用程序类加载器（Application ClassLoader）：由sun.misc.Launcher$AppClassLoader实现。由于这个类加载器是ClassLoader中的getSystemClassLoader()方法 的返回值，所以一般也称它为系统类加载器。它负责加载用户类路径（ClassPath）所指定的类库，开发者可以直接使用这个类加载器，如果应用程序中没有自定义过自己的类加载器，一般情况下这个就是程序中默认的类加载器。

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

             

             使用双亲委派模型来组织类加载器之间的关系，明显的好处即Java类随着它的类加载器一起具备了一种带有优先级的层次关系。如类java.lang.Object，它存在在rt.jar之中，无论哪一个类加载器要加载这个类，最终都是委派给处于模型最顶端的启动类加载器进行加载，因此Object类在程序的各种类加载器环境中都是同一个类。

             双亲委派模型对于保证Java程序的稳定运作很重要，实现却非常简单，实现双亲委派的代码都集中在java.lang.ClassLoader的loadClass()方法之中。

 public Class<?> loadClass(String paramString)
    throws ClassNotFoundException
  {
    return loadClass(paramString, false);
  }

  protected synchronized Class<?> loadClass(String paramString, boolean paramBoolean)
    throws ClassNotFoundException
  {
    Class localClass = findLoadedClass(paramString);
    if (localClass == null) {//检查是否已经被加载过
      try {
        if (this.parent != null)
          localClass = this.parent.loadClass(paramString, false);//父类加载器存在，则调用父类加载器
        else {
          localClass = findBootstrapClassOrNull(paramString);//父类加载器不存在，默认使用启动类加载器作为父类加载器
        }
      }
      catch (ClassNotFoundException localClassNotFoundException)//父类加载器失败，抛出异常
      {
      }
      if (localClass == null)
      {
        localClass = findClass(paramString);//父类加载器加载失败，调用自己的fiandClass方法进行加载
      }
    }
    if (paramBoolean) {
      resolveClass(localClass);
    }
    return localClass;

 Tomcat类加载简介

          在tomcat目录结构中，有3组（“/common/*”，“/server/*”，“/shared/*”）可以存放Java类库，另外加上Web应用程序自身的目录“/WEB-INF/*”，一共四组，具体含义如下：

        （1）放置在/common目录中：类库可被Tomcat和所有的We应用程序共同使用---Common类加载器(CommonClassLoader)

        （2）放置在/server目录中：类库可被Tomcat使用，对所有的Web应用程序都不可见--Catalina类加载器(CatalinaClassLoader)

        （3）放置在/shared目录中：类库可被该tomcat下所有的Web应用程序共同使用，对tomcat自身不可见--Shared类加载器(SharedClassLoader)

        （4）放置在/WebApp/Web-INF目录中：类库只被自身Web应用程序使用，对Tomcat和其下的其它Web应用程序不可见--WebApp类加载器(WepAppClassLoader)

          为了支持这套目录机构，并对目录里面的类库进行加载和隔离，Tomcat自定义了多个类加载器，这些类加载器按照经典的双亲委派模型来实现。其中WebApp类加载器和Jsp类加载器通常会存在多个实例，每一个Web应用程序对应一个WebApp类加载器，每一个JSP文件对应一个JSP类加载器。

          JsperLoader的加载范围仅仅是这个JSP文件所编译出来的那一个Class，它出现的目的就是为了丢弃：当服务器检测到JSP文件被修改时，会替换掉目前的JasperLoader的实例，并通过再建立一个新的Jsp类加载器来实现文件的HotSwap功能。