JVM里面Java类的生命周期，一篇搞定

若是说核心类库的 API 比作数学公式的话，那么 Java 虚拟机的知识就比如公式的推导过程

类生命周期

• 加载（Loading）
  • 四种类加载器：
  • JAVA_HOME 目录里面的内容
  • 双亲委任
• 链接（Linking）
  • 验证阶段
  • 准备阶段
  • 解析阶段
• 初始化
  • 类初始化的七种触发状况：
• 卸载

JVM

每本Java入门书籍在介绍Java这门语言的时候都会提到Java跨平台，“一次解释，处处运行的特色“，功臣就是jvm（Java Virtual Machine，Java虚拟机）。

可是，若是将jvm只与Java语言绑定在一块儿，那么理解就过于狭隘了，Java虚拟机发展到如今已经脱离了Java语言，造成了一套相对独立，高性能的执行方案。

image

除了以上提到的几种语言以外，scala,热门的kotlin均可以运行在jvm上面。

jvm内存结构规范

先简单看一下 JVM 内存结构，以后会详细讲解这一块的具体存储。

类生命周期

类从被加载到虚拟内存中开始，到卸载内存为止，它的整个生命周期包括:

类从加载到卸载整个生命周期

小提示：

1. 加载阶段和链接阶段有时候是交叉进行的，不须要等到彻底加载结束。
2. 解析阶段有时候能够再初始化以后再作。Jvm仅仅规定了：若是某些字节码使用了符号引用，那么在执行这些字节码以前，须要完成对这些符号引用的解析。
3. 可是这些过程总的开始时间和完成时间都是上图固定顺序。
4. 这里的“加载阶段”和咱们常说的“类加载”是两回事，“类加载”指的是虚线框中三部分加起来。

加载（Loading）

加载，是指查找字节流，而且据此建立类的过程。是类加载过程的一个阶段。 虚拟机须要在这个过程完成三件事情：

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

类加载

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

四种类加载器：

1. 启动(Bootstrap)类加载器

启动类加载器负责加载最为基础、最为重要的类。负责将 JAVA_HOME/lib 下面的类库加载到内存中(好比rt.jar)。因为引导类加载器涉及到虚拟机本地实现细节，开发者没法直接获取到启动类加载器的引用，因此不容许直接经过引用进行操做。

注：启动类加载器是由 C++ 实现的，没有对应的 Java 对象，所以在 Java 中只能用 null 来指代。除了启动类加载器以外，其余的类加载器都是 java.lang.ClassLoader 的子类，所以有对应的 Java 对象。这些类加载器须要先由另外一个类加载器，好比说启动类加载器，加载至 Java 虚拟机中，方能执行类加载。

2. 标准扩展(Extension)类加载器

它负责加载相对次要、但又通用的类，负责将 JAVA_HOME/jre/lib/ext 或者由系统变量 java.ext.dirs指定位置中的类库加载到内存中。

3. 应用程序(Application)类加载器

它负责将系统类路径(CLASSPATH) 中指定的类库加载到内存中。因为这个类加载器是ClassLoader中的 getSystemClassLoader()方法的返回值，所以通常称为系统(System)加载器

4. 自定义类加载器

除了由 Java 核心类库提供的类加载器外，咱们还能够加入自定义的类加载器，来实现特殊的加载方式。举例来讲，咱们能够对 class 文件进行加密，加载时再利用自定义的类加载器对其解密。

JAVA_HOME 目录里面的内容

之因此写这个是由于平时开发中不多有人翻开这个文件夹来看，上面讲到这个目录顺便带着你们来看看。

JAVA_HOME/bin目录放的不少命令

JAVA_HOME/lib目录

JAVA_HOME/jre/lib目录

JAVA_HOME/jre/lib/ext目录

双亲委任

双亲委任工做流程

双亲委派机制的工做流程：

1. 当前ClassLoader首先从本身已经加载的类中查询是否此类已经加载，若是已经加载则直接返回原来已经加载的类。

每一个类加载器都有本身的加载缓存，当一个类被加载了之后就会放入缓存，等下次加载的时候就能够直接返回了。

2. 当前classLoader的缓存中没有找到被加载的类的时候，委托父类加载器去加载，父类加载器采用一样的策略，首先查看本身的缓存，而后委托父类的父类去加载，一直到bootstrp ClassLoader.

3. 当全部的父类加载器都没有加载的时候，再由当前的类加载器加载，并将其放入它本身的缓存中，以便下次有加载请求的时候直接返回。

为何须要双亲委任安全机制？

1. 直观理解

试想一下黑客自定义一个 java.lang.String 类，该 String 类具备系统的 String 类同样的功能，只是在某个函数稍做修改。 这个函数常用，假如在这这个函数中植入一些“病毒代 码”。而且经过自定义类加载器加入到 JVM 中。完了，程序凉凉，这是比较直观的理解。

2. 真实缘由

要彻底理解这个问题还须要引入一个概念，类的命名空间。

类须要类的全限定名（类的全路径）以及加载此类的ClassLoader来共同肯定。也就是说即便两个类的全限定名是相同的，可是由于不一样的ClassLoader加载了此类，那么在JVM中它是不一样的类。

好比上面说的，咱们 JDK 本生提供的类库，好比 string,hashmap,linkedlist 等等，这些类由bootstrp 类加载器加载了之后，不管你程序中有多少个类加载器，那么这些类其实都是能够共享的，这样就避免了不一样的类加载器加载了一样名字的不一样类之后形成混乱。

归纳：

1. 检查顺序:自底向上
2. 加载顺序:自顶向下

链接（Linking）

验证阶段

当一个类被加载以后，必需要验证一下这个类是否合法，好比这个类是否是符合字节码的格式、变量与方法是否是有重复、数据类型是否是有效、继承与实现是否合乎标准等等。

咱们日常写代码不少时候第一步都是写校验，jvm也是这个思路，Java 编译器生成的类文件必然知足 Java 虚拟机的约束条件，可是为了防止“解字节码注入”。

验证阶段大体会完成下面四个阶段的检验动做：

• 文件格式验证 （主要验证是否符合Class文件格式规范，而且能被当前版本的虚拟机处理。）

基于二进制字节流进行验证，只有经过了这个阶段的验证后，字节流才会进入内存的方法区中进行存储，因此后面的验证阶段全是基于方法区的存储结构进行的，不会再直接操做字节流。

• 元数据验证（对字节码描述的信息进行语义分析，以保证其描述的信息符合Java语言规范的要求）

如验证这个类是否有父类（除了java.lang.Object是全部类的父类），若是这个类不是抽象类是否实现了父类或者接口中要求实现的全部方法等。

• 字节码验证
• 符号引用验证（发生在虚拟机将符号引用转化为直接引用的时候，这个转化动做将在链接的第三阶段解析阶段中发生）

如验证符号引用中经过字符串描述的全限定名是否能找到对应的类。

准备阶段

就是为类的静态变量分配内存并设为 jvm 默认的初值，而不是咱们设置的，咱们设置的会在后面一个阶段“初始化”期间来作，对于非静态的变量，则不会为它们分配内存。

jvm默认的初值是这样的：

基本类型（int、long、short、char、byte、boolean、float、double）的默认值为0。其中boolean只有true,false两种类型，对应到jvm值分别是数据1，0。

引用类型（对象，数组）的默认值为null。

构造其余跟类层次相关的数据结构，好比说用来实现虚方法的动态绑定的方法表。

在 class 文件被加载至 Java虚拟机以前，这个类没法知道其余类及其方法、字段所对应的具体地址，甚至不知道本身方法、字段的地址。所以，每当须要引用这些成员时，Java 编译器会生成一个符号引用。在运行阶段，这个符号引用通常都可以无歧义地定位到具体目标上（由于验证阶段进行符号引用验证了）。

例外：public static final int value=123,常量直接赋值为设置的123.

解析阶段

上面说到的“在运行阶段，这个符号引用通常都可以无歧义地定位到具体目标上”，就是在解析阶段进行的符号解析。

这个阶段目的正是将常量池中的符号引用转换解析成为实际引用。在解析阶段，jvm会将全部的类或接口名、字段名、方法名转换为具体的内存地址，从而让用到了别的类或者接口的类能找到和加载其余的类/接口。

若是符号引用指向一个未被加载的类，或者未被加载类的字段或方法，那么解析将触发这个类的加载（但未必触发这个类的连接以及初始化）

初始化

在 Java 代码中，若是要初始化一个静态字段，咱们能够在声明时直接赋值，也能够在静态代码块中对其赋值。除了 final static 修饰的常量，直接赋值操做以及全部静态代码块中的代码，则会被 Java 编译器置于同一方法中，并把它命名为 < clinit >。

类加载的最后一步是初始化，目的即是为标记为常量值的字段赋值，以及执行< clinit > 方法的过程。Java 虚拟机会经过加锁来确保类的 < clinit > 方法仅被执行一次。

类初始化的七种触发状况：

1. 当虚拟机启动时，初始化用户指定的主类（main函数）；

2. 当遇到用以新建目标类实例的 new 指令时，初始化 new 指令的目标类；

3. 当遇到调用静态方法的指令时，初始化该静态方法所在的类；

4. 子类的初始化会触发父类的初始化；

5. 若是一个接口定义了 default 方法，那么直接实现或者间接实现该接口的类的初始化，会触发该接口的初始化；

6. 使用反射 API 对某个类进行反射调用时，初始化这个类；

7. 当初次调用 MethodHandle 实例时，初始化该 MethodHandle 指向的方法所在的类。

设计模式中单例延迟加载，即是充分利用了这个特色。

卸载

那么多的类，什么时候卸载谁呢？关于卸载谁，知足以下条件：

1. 该类全部的实例都已经被回收，也就是java堆中不存在该类的任何实例；

2. 加载该类的ClassLoader已经被回收；

3. 该类对应的java.lang.Class对象没有任何地方被引用，没法在任何地方经过反射访问该类的方法。

关于何时卸载，当以上条件都知足了，垃圾回收时候回在方法区清空类信息进行卸载，英雄迟暮，这个类的一辈子也就走到了尽头了。