深入浅出JVM（一）类加载

---

前言

JVM这三个字母，可以说是超高频出现在我们的开发生活，听上去很高大上。其实JVM并没有我们想象中那么难，只是内容繁琐。我记得我在学校参加面试的时候，面试官问我看过哪些书？说深入理解JVM，以及JAVA编程思想，这俩本书是必看的。今日就好好总结一下JVM。以下从外到内一步步仔细介绍，因涉及东西较多，会分为几篇博客。

---

一、JVM简介

JVM的全称:Java Virtual Machine(Java 虚拟机)，JVM加上一些基础API，这俩部分称为JRE（Java Runtime Environment），JRE是支持Java程序运行的标准环境，也是代码可以运行的最低要求，但是它并不是一个开发环境，因为一个最小的开发环境，除了JRE外，还得有些开发工具。而这种，就是我们熟悉的JDK（Java Development Kit），Kit是工具的意思。JVM、JRE、JDK的区别
实际开发上，我们利用JDK开发出程序后，开发时的文件是.java后缀，经过编译器编译后变成.class后缀的文件，也就是字节码文件。而JVM对这些class文件进行类加载等操作。
JVM执行class文件，与操作系统交互，跨平台的核心。

二、类加载机制

虚拟机把描述类的数据从Class文件加载到内存，并对数据进行校验、转换解析和初始化，最终形成可以被虚拟机直接使用的Java类型，这就是虚拟机的类加载机制。举一个不是非常严谨的例子，人进食，会把食物转变成人体所需要的各种能量维生素等物质。如把jvm比做人进食的一个过程，那么我们先从食物还没入口之前讲，这可不是拿起往嘴里塞就行的操作，而是严谨复杂的一个过程。

1.类加载器

类加载器，顾名思义，就是对类进行加载的一个操作器。它只用于实现类的加载动作，注意，这里特地声明类加载器只用于实现类的加载动作，是为了侧重类的生命周期有很多步，这只是其中的一小步，类的生命周期后面会详解。
引用：对于任意一个类，都需要由加载它的类加载器和这个类本身一同确立其在Java虚拟机中的唯一性，每一个类加载器，都拥有一个独立的类名称空间。这句话可以表达得更通俗一些：比较两个类是否“相等”，只有在这两个类是由同一个类加载器加载的前提下才有意义，否则，即使这两个类来源于同一个Class文件，被同一个虚拟机加载，只要加载它们的类加载器不同，那这两个类就必定不相等。

对于JVM来说，类加载器分为俩种，一种是由C++语言实现的，叫做启动类加载器，另一个种是由Java语言实现的，又分为扩展类加载器、应用程序类加载器以及自定义加载器。

1.1 启动类加载器

启动类加载器（Bootstrap classloader）：这个类是C++语言实现的，是老大级别的加载器，无法被java程序引用。主要负责加载%JAVA_HOME%/jre/lib路径下的jar包，比如rt.jar.这个jar包里面的类，可以说是天天引用，常见的有List、Map、Date等等。
这是jdk包含的jar包，这些jar在jdk安装目录就能一一对应，比如rt.jar就在%JAVA_HOME%/jre/lib下。显然这个jar包的类都是启动类加载器去加载的。

1.2 扩展类加载器

扩展类加载器（Extension ClassLoader）：他主要负责加载%JAVA_HOME%/jre/lib/ext路径下的jar包。是java程序编写的，能够被引用。

1.3 应用程序类加载器

应用程序类加载器（Application ClassLoader）：这个类加载器是我们编写应用程序中默认的类加载器，一般也称为系统类加载器。像我们平常编写类，就是用的这个类加载器。当然也可以自定义类加载器。

自定义类加载器：我们需要的类不一定存放在已经设置好的classPath下(有系统类加载器AppClassLoader加载的路径)，对于自定义路径中的class类文件的加载，我们需要自己的ClassLoader。

启动类加载器负责加载的包

扩展类加载器负责加载的包

贴俩个图，是为了让体现JVM和JDK的联系。

代码实测：

public class Test1 {
    public static void main(String[] args) {
        List<String> listLoader=new ArrayList<String>();//rt.jar下的List  %JAVA_HOME%/jre/lib
        SunEC sunEC = new SunEC();//sunec.jar下的List  %JAVA_HOME%/jre/lib/ext
        System.out.println("自定义类的类加载器"+Test1.class.getClassLoader());//自定义类
        System.out.println("自定义类的父类加载器"+Test1.class.getClassLoader().getParent());
        System.out.println("List的类加载器"+listLoader.getClass().getClassLoader());
        System.out.println("sunEC的类加载器"+sunEC.getClass().getClassLoader());
    }
}

这里我引用了不同jar下面的类或接口，并标注了它们的来源路径。但输出结果我相信不少人会答错。

自定义类的类加载器sun.misc.Launcher$AppClassLoader@18b4aac2
自定义类的父类加载器sun.misc.Launcher$ExtClassLoader@610455d6
List的类加载器null
sunEC的类加载器sun.misc.Launcher$ExtClassLoader@610455d6

控制台输出的结果，再一次验证了我上面所介绍的内容。应用程序类加载器的父类是扩展类加载器，所以第二条结果也是非常明确的。而扩展类加载器它的父类加载器是启动类加载器，但是因为启动类加载器是C++编写的底层代码，不可引用。所以第三条结果也就为null。

2.类加载器工作机制（双亲委派机制）

前面介绍完了类加载器，那么JVM对于每个类，又是怎么知道该用哪个类加载器呢？由前文可知，类加载器之间是有层次关系的。这种层次关系被称为类加载器的双亲委派模型。
双亲委派机制，主要是“向上委托，向下查找”。
​​

下面引用官方的一段话，感觉讲的十分清晰明了，所以贴出来。

双亲委派模型要求除了顶层的启动类加载器外，其余的类加载器都应当有自己的父类加载器。这里类加载器之间的父子关系一般不会以继承（Inheritance）的关系来实现，而是都使用组合（Composition）关系来复用父加载器的代码。
双亲委派模型的工作过程是：如果一个类加载器收到了类加载的请求，它首先不会自己去尝试加载这个类，而是把这个请求委派给父类加载器去完成，每一个层次的类加载器都是如此，因此所有的加载请求最终都应该传送到顶层的启动类加载器中，只有当父加载器反馈自己无法完成这个加载请求（它的搜索范围中没有找到所需的类）时，子加载器才会尝试自己去加载。
使用双亲委派模型来组织类加载器之间的关系，有一个显而易见的好处就是Java类随着它的类加载器一起具备了一种带有优先级的层次关系。例如类java.lang.Object，它存放在rt.jar之中，无论哪一个类加载器要加载这个类，最终都是委派给处于模型最顶端的启动类加载器进行加载，因此Object类在程序的各种类加载器环境中都是同一个类。相反，如果没有使用双亲委派模型，由各个类加载器自行去加载的话，如果用户自己编写了一个称java.lang.Object的类，并放在程序的ClassPath中，那系统中将会出现多个不同的Object类，Java类型体系中最基础的行为也就无法保证，应用程序也将会变得一片混乱。如果读者有兴趣的话，可以尝试去编写一个与rt.jar类库中已有类重名的Java类，将会发现可以正常编译，但永远无法被加载运行[2]。
双亲委派模型对于保证Java程序的稳定运作很重要，但它的实现却非常简单，实现双亲委派的代码都集中在java.lang.ClassLoader的loadClass（）方法之中， 逻辑清晰易懂：先检查是否已经被加载过，若没有加载则调用父加载器的loadClass（）方法，若父加载器为空则默认使用启动类加载器作为父加载器。如果父类加载失败，抛出ClassNotFoundException异常后，再调用自己的findClass（）方法进行加载。

双亲委派机制：
1、安全，防止核心API被随意篡改。
2、避免类的重复加载，父类加载过，子类加载器就没必要再加载，保证了被加载类的唯一性

三、类加载的过程

通过前面的环节，JVM已经能够找到需要加载的类了，接下来开始类加载。

1、类的生命周期

类的生命周期总的来说分为七个阶段，加载、验证、准备、解析、初始化、使用、卸载。其中验证、准备和解析三个阶段可以称为连接阶段。稍后会逐个介绍每个阶段，这里先做大致总结。

这七个阶段中，解析阶段的顺序是不一定的，也可能在初始化后才解析，为了支持Java语言的动态绑定，通俗的说就是运行时才确定我要加载谁，使用阶段也是不一定的。因为有些对象没有使用就有可能被卸载了。
因此 加载、验证、准备、初始化和卸载 这五个阶段的顺序时确定的，必须按照这个顺序开始。但不一定是12345这种顺序，因为这些阶段通常都是互相交叉混合式进行的，通常会在一个阶段执行的过程中调用、激活另外一个阶段。
关于加载阶段什么时候开始，Jvm并没有进行强制约束，但是初始化阶段，是由严格规范的五种情况。

1）遇到new、getstatic、putstatic或invokestatic这4条字节码指令时，如果类没有进行过初始化，则需要先触发其初始化。生成这4条指令的最常见的Java代码场景是：使用new关键字实例化对象的时候、读取或设置一个类的静态字段（被final修饰、已在编译期把结果放入常量池的静态字段除外）的时候，以及调用一个类的静态方法的时候。
2）使用java.lang.reflect包的方法对类进行反射调用的时候，如果类没有进行过初始化， 则需要先触发其初始化。
3）当初始化一个类的时候，如果发现其父类还没有进行过初始化，则需要先触发其父类的初始化。
4）当虚拟机启动时，用户需要指定一个要执行的主类（包含main（）方法的那个类），虚拟机会先初始化这个主类。
5）当使用JDK 1.7的动态语言支持时，如果一个java.lang.invoke.MethodHandle实例最后
的解析结果REF_getStatic、REF_putStatic、REF_invokeStatic的方法句柄，并且这个方法句柄所对应的类没有进行过初始化，则需要先触发其初始化。

这五种情景中的行为，称为对一个类进行主动引用。除此之外所有引用类的方式都不会触发初始化，称为被动引用。官方解释的五种场景，我们平常熟悉的至少有前四种，new对象、反射机制（框架灵魂）、用子类先将父类初始化、执行某类时初始化该类。

2、类的生命周期详解

2.1、加载

加载阶段，Jvm有明确规定该阶段需要完成三件事情

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

第一条，我们肯定听说过，通过类的全限定名来获取定义此类的二进制字节流，比如动态代理技术。
第二条以及第三条，涉及一个内存中的模型，方法区。它用于存储已被虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码等数据。虚拟机加载的类信息，这个信息来自于java.lang.Class这个类对象，注意，这个类是用来记录类的信息的。方法区中存有java.lang.Class对象。很多人会有疑问，对象不是存在堆中的吗？怎么存在方法区中了？
堆中存的是实例对象，而这个java.lang.Class对象，是java.lang.Class这个类的对象，不是同一个概念。要知道java.lang.Class是一个类，就像com.shop.orderVo（举例）一样，orderVo记录订单信息，而这里的Class类记录的是类的信息。
前面说到类的生命周期阶段通常都是互相交叉混合式进行的，对于加载阶段而言，与连接夹断的部分内容也是交叉进行的，比如这里第二点“将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构”，当我们存储之前是需要经过一些验证的，通过这些验证才能进入方法区进行存储，下面继续介绍验证阶段。

2.2、验证

验证阶段，其目的是为了确保Class文件的字节流包含的信息符合当前虚拟机的要求，并且不会危害虚拟机本身的安全。验证阶段十分严谨，因为该阶段决定了Java虚拟机能否承受恶意代码的攻击，其总体分又为四个小阶段，因此验证阶段的工作量在类加载子系统中是相当大的一部分。

• 文件格式验证：验证字节流是否符合Class文件格式的规范，并且能被当前版本的虚拟机处理。
• 字节码验证：通过数据流和控制流分析， 确定程序语义是合法的、符合逻辑的。
• 符号引用验证：确保解析动作能正常执行。
• 元数据验证：保证不存在不符合Java语言规范的元数据信息。

2.3、准备

当我们通过所有验证后，就可以正式为类变量分配内存并设置类变量初始值了。这个阶段正要干这俩件事。值得注意的是，这些类变量仅仅只是被Static修饰的变量，而上面有提到，虚拟机加载的类信息、常量、静态变量等是存放于方法区的。因此这个阶段也就是在方法区中完成的。还有一件事就是设置类变量初始值，注意是初始值。
public static int study=123；这是一个类变量，在准备阶段。我们是给study在方法区中分配了内存，其次给它赋上了初始值，也就是int的初始值0；
另外还需要提出的是，实例变量的分配内存。我们都知道，局部变量（基本类型存栈中，String存在常量池）存放在栈中。但是当这个类实例化后，这个类的局部变量也会随着实例对象存到堆中。

Java中局部变量、实例变量和静态变量在方法区、栈内存、堆内存中的分配

2.4、解析

解析阶段是虚拟机将常量池内的符号引用替换为直接引用的过程。原本加载只是一些符号，但是该阶段将符号引用转化为指针引用。比如user类中 引用job类。编译时引用的只是job符号比如（CONSTANT_Class_info啥的），而解析阶段将这个符号转换成job的内存地址。

2.5、初始化

这是类加载过程中最后一步，了初始化阶段，才真正开始执行类中定义的Java程序代码，该阶段会对初始化类变量进行赋值，而不是再是初始值。

---

总结

加载一个类到jvm中，这途中的操作相当复杂。至此一个类总算是加载到jvm中了，万里长征已经踏出第一步，革命尚未成功，同志仍须努力。下一篇博客将探讨jvm的内存模型。