JVM学习笔记

（一）类加载

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

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

一启动类加载器，无法被java程序引用，由C++实现，负责加载%JAVA_HOME%/jre/lib下的jar包
二扩展类加载器，负责加载%JAVA_HOME%/jre/lib/ext下的jar包；
三自定义程序类加载器；

public class Test1 {
    public static void main(String[] args) {
        List<String> listLoader=new ArrayList<String>();
        SunEC sunEC=new SunEC();
        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());
    }
}

输出结果如下

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

应用程序类加载器的父类是扩展类加载器，所以第二条结果显而易见。而扩展类加载器它的父类加载器是启动类加载器，但是因为启动类加载器是C++编写的底层代码，不可引用。所以第三条结果为null。

双亲委派模型

直接贴官方的解释

双亲委派模型要求除了顶层的启动类加载器外，其余的类加载器都应当有自己的父类加载器。这里类加载器之间的父子关系一般不会以继承（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（）方法进行加载。

多阅读两遍一定能看懂，解释的还是很明白的。总的来说就是保证了每一个类在加载时的唯一性，让JAVA程序能稳定运行。ClassNotFoundException这个异常，不少人都见过，现在知道了它是在那个地方被抛出来的了吗。

三类加载的过程

1.类的生命周期

类的生命周期总的来说分为七个阶段，加载、验证、准备、解析、初始化、使用、卸载。其中验证、准备和解析三个阶段可以称为连接阶段。
这七个阶段中，解析阶段的顺序是不一定的，也可能在初始化后才解析，为了支持Java语言的动态绑定。通俗的说就是运行时才确定我要加载谁。使用阶段也是不一定的，因为有些对象没有使用就有可能被卸载了。
因此 加载、验证、准备、初始化和卸载 这五个阶段的开始顺序是确定的，必须按照这个顺序开始。但它们的执行顺序并不确定，而是会互相交叉混合式进行的，通常会在一个阶段执行的过程中调用、激活另外一个阶段。
关于加载阶段什么时候开始，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对象、反射机制（框架灵魂）、用子类先将父类初始化、执行某类时初始化该类。

类的生命周期详解

加载

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

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

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

验证

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

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

准备

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

解析

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

初始化

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