jvm是java中最为核心的部分，现在对于以前学习的细节没有学习到的点做一个概括
学习思路

首先借用一个@pdai佬的思维导图来做一下知识引入。我的jvm篇的知识按照以下的思路进行：

  1. JVM类加载
  2. JVM的内存结构
  3. JVM相关的JMM
  4. JVM的GC
  5. 最后按照情况写一下JVM的排错调优

类的加载

类的生命周期

类加载的过程包括了加载、验证、准备、解析、初始化五个阶段。在这五个阶段中，加载、验证、准备和初始化这四个阶段发生的顺序是确定的，而解析阶段则不一定，它在某些情况下可以在初始化阶段之后开始，这是为了支持Java语言的运行时绑定(也称为动态绑定或晚期绑定)。另外注意这里的几个阶段是按顺序开始，而不是按顺序进行或完成，因为这些阶段通常都是互相交叉地混合进行的，通常在一个阶段执行的过程中调用或激活另一个阶段。

类的加载：查找并加载类的二进制数据

classloader

我们从上图可以得知到的信息有：

  1. 通过一个类的全限定名来获取其对应的二进制数据流
  2. 将这个字节流所代表的数据存储结构转换为方法区的运行时数据结构
  3. 在Java中的堆中创建一个代表这个类的lang.class对象，作为对方法区这些数据的访问入口

连接

验证：确保被加载类的正确性

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

  • 文件格式验证: 验证字节流是否符合Class文件格式的规范；例如: 是否以0xCAFEBABE开头、主次版本号是否在当前虚拟机的处理范围之内、常量池中的常量是否有不被支持的类型。
  • 元数据验证: 对字节码描述的信息进行语义分析(注意: 对比javac编译阶段的语义分析)，以保证其描述的信息符合Java语言规范的要求；例如: 这个类是否有父类，除了java.lang.Object之外。
  • 字节码验证: 通过数据流和控制流分析，确定程序语义是合法的、符合逻辑的。
  • 符号引用验证: 确保解析动作能正确执行。

验证阶段是非常重要的，但不是必须的，它对程序运行期没有影响，如果所引用的类经过反复验证，那么可以考虑采用-Xverifynone参数来关闭大部分的类验证措施，以缩短虚拟机类加载的时间。

准备: 为类的静态变量分配内存，并将其初始化为默认值

值得注意的是，准备阶段只为静态变量分配内存。这时候进行内存分配的仅包括类变量(static)，而不包括实例变量，实例变量会在对象实例化时随着对象一块分配在Java堆中。

假设一个类变量的定义为: public static int value = 3；那么变量value在准备阶段过后的初始值为0，而不是3，因为这时候尚未开始执行任何Java方法，而把value赋值为3的put static指令是在程序编译后，存放于类构造器()方法之中的，所以把value赋值为3的动作将在初始化阶段才会执行。

解析: 把类中的符号引用转换为直接引用

解析阶段是虚拟机将常量池内的符号引用替换为直接引用的过程，解析动作主要针对类或接口、字段、类方法、接口方法、方法类型、方法句柄和调用点限定符7类符号引用进行。符号引用就是一组符号来描述目标，可以是任何字面量。

直接引用就是直接指向目标的指针、相对偏移量或一个间接定位到目标的句柄。

初始化

初始化，为类的静态变量赋予正确的初始值，JVM负责对类进行初始化，主要对类变量进行初始化。在Java中对类变量进行初始值设定有两种方式:

  • 声明类变量是指定初始值
  • 使用静态代码块为类变量指定初始值

类加载器，JVM加载机制

类加载器的层次

类加载器层次

关键词：自定义类加载器，Application classloader, extension classloader, BootstrapclassLoader

类的加载

类加载有三种方式：

  1. 命令行启动应用时候由JVM初始化加载
  2. 通过class.forName()
  3. 通过ClassLoader.loadClass()方法动态加载

JVM类加载机制

父类委托，先让父类加载器试图加载该类，只有在父类加载器无法加载该类时才尝试从自己的类路径中加载该类。

缓存机制，缓存机制将会保证所有加载过的Class都会被缓存，当程序中需要使用某个Class时，类加载器先从缓存区寻找该Class，只有缓存区不存在，系统才会读取该类对应的二进制数据，并将其转换成Class对象，存入缓存区。这就是为什么修改了Class后，必须重启JVM，程序的修改才会生效。

双亲委派机制，如果一个类加载器收到了类加载的请求，它首先不会自己去尝试加载这个类，而是把请求委托给父加载器去完成，依次向上，因此，所有的类加载请求最终都应该被传递到顶层的启动类加载器中，只有当父加载器在它的搜索范围中没有找到所需的类时，即无法完成该加载，子加载器才会尝试自己去加载该类。

JVM内存结构

framework

程序计数器

程序计数寄存器（Program Counter Register），Register 的命名源于 CPU 的寄存器，寄存器存储指令相关的线程信息，CPU 只有把数据装载到寄存器才能够运行。

这里，并非是广义上所指的物理寄存器，叫程序计数器（或PC计数器或指令计数器）会更加贴切，并且也不容易引起一些不必要的误会。

JVM 中的 PC 寄存器是对物理 PC 寄存器的一种抽象模拟。程序计数器是一块较小的内存空间，可以看作是当前线程所执行的字节码的行号指示器。

虚拟机栈

Java 虚拟机栈(Java Virtual Machine Stacks)，早期也叫 Java 栈。每个线程在创建的时候都会创建一个虚拟机栈，其内部保存一个个的栈帧(Stack Frame），对应着一次次 Java 方法调用，是线程私有的，生命周期和线程一致。

作用：主管 Java 程序的运行，它保存方法的局部变量、部分结果，并参与方法的调用和返回。

栈中可能出现的异常：
Java 虚拟机规范允许 Java虚拟机栈的大小是动态的或者是固定不变的

  • 如果采用固定大小的 Java 虚拟机栈，那每个线程的 Java 虚拟机栈容量可以在线程创建的时候独立选定。如果线程请求分配的栈容量超过 Java 虚拟机栈允许的最大容量，Java 虚拟机将会抛出一个 StackOverflowError 异常

  • 如果 Java 虚拟机栈可以动态扩展，并且在尝试扩展的时候无法申请到足够的内存，或者在创建新的线程时没有足够的内存去创建对应的虚拟机栈，那 Java 虚拟机将会抛出一个OutOfMemoryError异常

可以通过参数-Xss来设置线程的最大栈空间，栈的大小直接决定了函数调用的最大可达深度。

栈帧的结构:
栈帧
每个栈帧（Stack Frame）中存储着：

  • 局部变量表（Local Variables）
  • 操作数栈（Operand Stack）(或称为表达式栈)
  • 动态链接（Dynamic Linking）：指向运行时常量池的方法引用
  • 方法返回地址（Return Address）：方法正常退出或异常退出的地址
  • 一些附加信息

操作数栈，主要用于保存计算过程的中间结果，同时作为计算过程中变量临时的存储空间

本地方法栈

简单的讲，一个 Native Method 就是一个 Java 调用非 Java 代码的接口。我们知道的 Unsafe 类就有很多本地方法。

为什么要使用本地方法？

  • 与 Java 环境外交互：有时 Java 应用需要与 Java 外面的环境交互，这就是本地方法存在的原因。
  • 与操作系统交互：JVM 支持 Java 语言本身和运行时库，但是有时仍需要依赖一些底层系统的支持。通过本地方法，我们可以实现用 Java 与实现了 jre 的底层系统交互， JVM 的一些部分就是 C 语言写的。
  • Sun’s Java：Sun的解释器就是C实现的，这使得它能像一些普通的C一样与外部交互。jre大部分都是用 Java 实现的，它也通过一些本地方法与外界交互。比如，类 java.lang.Thread 的 setPriority() 的方法是用Java 实现的，但它实现调用的是该类的本地方法 setPrioruty()，该方法是C实现的，并被植入 JVM 内部。

堆内存

对于大多数应用，Java 堆是 Java 虚拟机管理的内存中最大的一块，被所有线程共享。此内存区域的唯一目的就是存放对象实例，几乎所有的对象实例以及数据都在这里分配内存。

为了进行高效的垃圾回收，虚拟机把堆内存逻辑上划分成三块区域（分代的唯一理由就是优化 GC 性能）：

  • 新生带（年轻代）：新对象和没达到一定年龄的对象都在新生代
  • 老年代（养老区）：被长时间使用的对象，老年代的内存空间应该要比年轻代更大
  • 元空间（JDK1.8 之前叫永久代）：像一些方法中的操作临时对象等，JDK1.8 之前是占用 JVM 内存，JDK1.8 之后直接使用物理内存

内存划分

Java 虚拟机规范规定，Java 堆可以是处于物理上不连续的内存空间中，只要逻辑上是连续的即可，像磁盘空间一样。实现时，既可以是固定大小，也可以是可扩展的，主流虚拟机都是可扩展的（通过 -Xmx 和 -Xms 控制），如果堆中没有完成实例分配，并且堆无法再扩展时，就会抛出 OutOfMemoryError 异常。

年轻代

年轻代是所有新对象创建的地方。当填充年轻代时，执行垃圾收集。这种垃圾收集称为 Minor GC。年轻一代被分为三个部分——伊甸园（Eden Memory）和两个幸存区（Survivor Memory，被称为from/to或s0/s1），默认比例是8:1:1

  • 大多数新创建的对象都位于 Eden 内存空间中
  • 当 Eden 空间被对象填充时，执行Minor GC，并将所有幸存者对象移动到一个幸存者空间中
  • Minor GC 检查幸存者对象，并将它们移动到另一个幸存者空间。所以每次，一个幸存者空间总是空的
  • 经过多次 GC 循环后存活下来的对象被移动到老年代。通常，这是通过设置年轻一代对象的年龄阈值来实现的，然后他们才有资格提升到老一代

老年代

旧的一代内存包含那些经过许多轮小型 GC 后仍然存活的对象。通常，垃圾收集是在老年代内存满时执行的。老年代垃圾收集称为 主GC（Major GC），通常需要更长的时间。大对象直接进入老年代（大对象是指需要大量连续内存空间的对象）。这样做的目的是避免在 Eden 区和两个Survivor 区之间发生大量的内存拷贝

oldgen

我们可以从上图中看出一个明显的区别，java1.8之后取消了永久代

主要用于存储与类加载相关的数据，如 类的元数据、方法区、常量池、JIT 编译后的代码等。

存储方式不同：Metaspace 使用 本地内存（Native Memory），不占用堆（Heap）。

自动扩展：不再受 -XX:MaxPermSize 限制，而是可以根据可用内存动态调整。

减少 OOM：可以通过 -XX:MaxMetaspaceSize 设定上限，但默认是 无限制，只受物理内存限制。

元空间

不管是 JDK8 之前的永久代，还是 JDK8 及以后的元空间，都可以看作是 Java 虚拟机规范中方法区的实现。

设置堆内存和OOM

Java堆用于存储java对象，那么堆的大小在JVM在启动的时候就确定了，我们可以通过-Xmx和-Xms来设定

  • -Xms 用来表示堆的起始内存，等价于 -XX:InitialHeapSize
  • -Xmx 用来表示堆的最大内存，等价于 -XX:MaxHeapSize

如果堆的内存大小超过 -Xmx 设定的最大内存， 就会抛出 OutOfMemoryError 异常。

可以通过代码获取到我们设置的值：

1
2
3
4
5
6
7
8
9
10
11
12
13
public static void main(String[] args) {

  //返回 JVM 堆大小
  long initalMemory = Runtime.getRuntime().totalMemory() / 1024 /1024;
  //返回 JVM 堆的最大内存
  long maxMemory = Runtime.getRuntime().maxMemory() / 1024 /1024;

  System.out.println("-Xms : "+initalMemory + "M");
  System.out.println("-Xmx : "+maxMemory + "M");

  System.out.println("系统内存大小：" + initalMemory * 64 / 1024 + "G");
  System.out.println("系统内存大小：" + maxMemory * 4 / 1024 + "G");
}

为对象分配内存是一件非常严谨和复杂的任务，JVM 的设计者们不仅需要考虑内存如何分配、在哪里分配等问题，并且由于内存分配算法和内存回收算法密切相关，所以还需要考虑 GC 执行完内存回收后是否会在内存空间中产生内存碎片。

  1. new 的对象先放在伊甸园区，此区有大小限制
  2. 当伊甸园的空间填满时，程序又需要创建对象，JVM 的垃圾回收器将对伊甸园区进行垃圾回收（Minor GC），将伊甸园区中的不再被其他对象所引用的对象进行销毁。
  3. 再加载新的对象放到伊甸园区然后将伊甸园中的剩余对象移动到幸存者 0 区
  4. 如果再次触发垃圾回收，此时上次幸存下来的放到幸存者 0 区，
  5. 如果没有回收，就会放到幸存者 1 区
  6. 如果再次经历垃圾回收，此时会重新放回幸存者 0 区，接着再去幸存者 1 区
  7. 什么时候才会去养老区呢？ 默认是 15 次回收标记在养老区，相对悠闲。
  8. 当养老区内存不足时，再次触发 Major GC，进行养老区的内存清理若养老区执行了
  9. Major GC 之后发现依然无法进行对象的保存，就会产生 OOM 异常

GC垃圾回收简介

JVM 在进行 GC 时，并非每次都对堆内存（新生代、老年代；方法区）区域一起回收的，大部分时候回收的都是指新生代。针对 HotSpot VM 的实现，它里面的 GC 按照回收区域又分为两大类：部分收集（Partial GC）和整堆收集（Full GC）。

部分收集：不是完整收集整个 Java 堆的垃圾收集。其中又分为：

  • 新生代收集（Minor GC/Young GC）：只是新生代的垃圾收集。
  • 老年代收集（Major GC/Old GC）：只是老年代的垃圾收集。
    • 目前，只有 CMS GC 会有单独收集老年代的行为。
    • 很多时候 Major GC 会和 Full GC 混合使用，需要具体分辨是老年代回收还是整堆回收。
  • 整堆收集（Full GC）：收集整个 Java 堆和方法区的垃圾。

TLAB

  1. 什么是TLAB（Thread Local Allocation Buffer）
    从内存模型而不是垃圾回收的角度，对 Eden 区域继续进行划分，JVM 为每个线程分配了一个私有缓存区域，它包含在 Eden 空间内。
  2. 多线程同时分配内存时，使用 TLAB 可以避免一系列的非线程安全问题，同时还能提升内存分配的吞吐量，因此我们可以将这种内存分配方式称为快速分配策略。
  3. OpenJDK 衍生出来的 JVM 大都提供了 TLAB 设计。

为什么要有TLAB？
堆区是线程共享的，任何线程都可以访问到堆区的共享数据。由于堆区数据的实例在 JVM 中创建非常频繁，因此在并发环境下从堆区中划分内存是线程不安全的，为了提高效率使用的 TLAB 技术。

方法区

方法区（Method Area）与 Java 堆一样，是所有线程共享的内存区域。虽然 Java 虚拟机规范把方法区描述为堆的一个逻辑部分，但是它却有一个别名叫 Non-Heap（非堆），目的是与 Java 堆区分开。

运行时常量池（Runtime Constant Pool）是方法区的一部分。Class 文件中除了有类的版本、字段、方法、接口等描述信息外，还有一项信息是常量池（Constant Pool Table），用于存放编译期生成的各种字面量和符号引用。这部分内容将在类加载后进入方法区的运行时常量池中存放。

运行期间也可能将新的常量放入池中，这种特性被开发人员利用得比较多的是 String.intern() 方法。受方法区内存的限制，当常量池无法再申请到内存时会抛出 OutOfMemoryError 异常。

方法区的大小和堆空间一样，可以选择固定大小也可选择可扩展。方法区的大小决定了系统可以放多少个类，如果系统类太多，导致方法区溢出，虚拟机同样会抛出内存溢出错误。JVM 关闭后方法区即被释放。

方法区内部结构

方法区用于存储已被虚拟机加载的类型信息、常量、静态变量、即时编译器编译后的代码缓存等。

类型信息对每个加载的类型（类 class、接口 interface、枚举 enum、注解 annotation），JVM 必须在方法区中存储以下类型信息：

  • 这个类型的完整有效名称（全名=包名.类名）。
  • 这个类型直接父类的完整有效名（对于 interface 或是 java.lang.Object，都没有父类）。
  • 这个类型的修饰符（public，abstract，final 的某个子集）。
  • 这个类型直接接口的一个有序列表。

域（Field）信息
JVM 必须在方法区中保存类型的所有域的相关信息以及域的声明顺序。域的相关信息包括：域名称、域类型、域修饰符（public、private、protected、static、final、volatile、transient 的某个子集）。

方法（Method）信息
JVM 必须保存所有方法的方法名称、方法的返回类型、方法参数的数量和类型、方法的修饰符（public，private，protected，static，final，synchronized，native，abstract 的一个子集）、方法的字符码（bytecodes）、操作数栈、局部变量表及大小（abstract 和 native 方法除外）、异常表（abstract 和 native 方法除外）。每个异常处理的开始位置、结束位置、代码处理在程序计数器中的偏移地址、被捕获的异常类的常量池索引。

栈、堆、方法区的交互关系。