JVM

虚拟机是一种抽象化的计算机，通过在实际的计算机上仿真模拟各种计算机功能来实现的。Java虚拟机有自己完善的硬体架构，如处理器、堆栈、寄存器等，还具有相应的指令系统。Java虚拟机屏蔽了与具体操作系统平台相关的信息，使得Java程序只需生成在Java虚拟机上运行的目标代码（字节码），就可以在多种平台上不加修改地运行。

参考文章：什么是JVM的内存模型？详细阐述Java中局部变量、常量、类名等信息在JVM中的存储位置

JVM基本介绍

Java是一个跨平台的语言，因为它是运行在Java虚拟机上（JVM）的。

在Java程序的实际编译、运行过程中，编译器将Java源代码编译成字节码文件后，JVM将字节码翻译成特定平台的机器码运行程序。

实际上，Java是跨平台的，JVM不是跨平台的，在Linux、windows等系统中安装对应版本的JVM后，同一个Java代码在这些JVM上运行，从而起到跨平台的效果。

JVM 、JDK 、JRE、Java 的区别

JVM是Java虚拟机，JRE是Java运行环境，JDK是个Java开发的工具包，Java是门编程语言

• JVM ：(Java Virtual Machine)，Java虚拟机。只认xxx.class文件，能识别class 文件中的字节码指令并调用操作系统向上的 API 完成动作，是Java程序运行的基础，它将Java程序编译后的字节码解释执行，并将其转换为机器码运行。jvm 是 Java 能够跨平台的核心。
• JRE：(Java Runtime Environment)，Java 运行环境。主要包含 jvm 的标准实现和 Java 的一些基本类库，相对于 jvm 来说，多出来的是一部分的 Java 类库。
• JDK：(Java Development Kit)，Java 开发工具包。提供了 Java 的开发环境和运行环境。jdk 是整个 Java 开发的核心，集成了 jre 和 Java 程序调试和分析的小工具。如：编译器javac.exe，java.exe，打包工具jar.exe、调试器（jdb） 等。

---

JVM内存模型

概述

JVM由三大部分组成：类加载子系统（ClassLoader）、运行时数据区（Runtime Data Area）、执行引擎（Execution Engine）、本地库接口（Native Interface）

组件的作用： 首先通过类加载器（ClassLoader）把 Java 代码转换成字节码，然后运行时数据区（Runtime Data Area）再把字节码加载到内存中，而字节码文件只是 JVM 的一套指令集规范，不能直接交给底层操作系统去执行，因此需要特定的命令解析器执行引擎（Execution Engine），将字节码翻译成底层系统指令，再交由 CPU 执行，而这个过程中需要调用其他语言的本地库接口（Native Interface）来实现整个程序的功能。

类加载子系统

类加载子系统：通过类加载机制，加载类的class文件，若该类是第一次加载，会加载验证、解析。只负责class文件的加载，至于是否可运行，则由执行引擎决定。JVM中，类加载过程是在类加载子系统完成的。

类加载器

类加载器：
对于任意一个类，都需要由加载它的类加载器和这个类本身一同确立在 JVM 中的唯一性，每一个类加载器都有一个独立的类名称空间。类加载器根据指定全限定名称将 class 文件加载到 JVM 内存，然后再转化为 class 对象。
类加载器分类：

• 启动类加载器（Bootstrap ClassLoader）：是虚拟机自身的一部分，用来加载Java_HOME/lib/目录中的，或者被 -Xbootclasspath 参数所指定的路径中并且被虚拟机识别的类库；
• 扩展类加载器（Extension ClassLoader）：负责加载<java_home style=”box-sizing: border-box; outline: 0px !important;”>libext目录或Java. ext.dirs系统变量指定的路径中的所有类库；
• 应用程序类加载器（Application ClassLoader）：负责加载用户类路径（classpath）上的指定类库，我们可以直接使用这个类加载器。一般情况，如果没有自定义类加载器默认就是用这个加载器。

双亲委派模型：
如果一个类加载器收到了类加载的请求，它首先不会自己去加载这个类，而是先把这个请求委派给父类加载器去完成，每一层的类加载器都是如此，这样所有的加载请求都会被传送到顶层的启动类加载器中，只有当父加载无法完成加载请求（它的搜索范围中没找到所需的类）时，子加载器才会尝试去加载类。

类装载的执行过程

类加载过程：加载→ 链接（验证、准备、解析）→ 初始化

• 加载：根据查找路径找到相应的 class 文件然后导入；
• 检查：检查加载的 class 文件的正确性；
• 准备：给类中的静态变量分配内存空间；
• 解析：虚拟机将常量池中的符号引用替换成直接引用的过程。
  • 符号引用就理解为一个标示，而在直接引用直接指向内存中的地址；
• 初始化：对静态变量和静态代码块执行初始化工作。

类加载过程：加载、链接（验证、准备、解析）、初始化。这个过程是在类加载子系统完成的。

加载：生成类的Class对象。

1. 通过一个类的全限定名获取定义此类的二进制字节流（即编译时生成的类的class字节码文件）
2. 将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构。包括创建运行时常量池，将类常量池的部分符号引用放入运行时常量池。
3. 在内存中生成一个代表这个类的java.lang.Class对象，作为方法区这个类各种数据的访问入口。注意类的class对象是运行时生成的，类的class字节码文件是编译时生成的。

链接：将类的二进制数据合并到JRE中。该过程分为以下3个阶段：

• 验证：确保代码符合JAVA虚拟机规范和安全约束。包括文件格式验证、元数据验证、字节码验证、符号引用验证。

  • 文件格式验证：验证字节码文件是否符合规范。

    • 魔数：是否魔数0xCAFEBABE开头
    • 版本号：版本号是否在JVM兼容范围
    • 常量类型：类常量池里常量类型是否合法
    • 索引值：索引值是否指向不存在或不符合类型的常量。

  • 元数据验证：元数据是字节码里类的全名、方法信息、字段信息、继承关系等。

    • 标识符：验证类名接口名标识符有没有符合规范
    • 接口实现方法：有没有实现接口的所有方法
    • 抽象类实现方法：有没有实现抽象类的所有抽象方法
    • final类：是不是继承了final类。

  • 指令验证：主要校验类的方法体，通过数据流和控制流分析，保证方法在运行时不会危害虚拟机安全

    • 类型转换：保证方法体中的类型转换是否有效。例如把某个类强转成没继承关系的类

    • 跳转指令：保证跳转指令不会跳转到方法体以外的字节码指令上；

    • 保证任意时刻操作数栈的数据类型与指令代码序列都能配合工作。

• 准备：为类变量（即static变量）分配内存并赋零值。

• 解析：将方法区-运行时常量池内的符号引用（类的名字、成员名、标识符）转为直接引用（实际内存地址，不包含任何抽象信息，因此可以直接使用）。

初始化：类变量赋初值、执行静态语句块。

运行时数据区

基本介绍

运行时数据区：在程序运行时，存储程序的内容（例如字节码、对象、参数、返回值等）。

不同虚拟机运行时数据区可能略微有所不同，但都会遵从Java 虚拟机规范，Java 虚拟机规范规定区域分为以下 5 个部分：

1. Java 虚拟机栈（Java Virtual Machine Stacks）：用于存储局部变量表、操作数栈、动态链接、方法出口等信息。
2. 本地方法栈（Native Method Stack）：与虚拟机栈的作用一样，只不过虚拟机栈是服务 Java 方法的，而本地方法栈为虚拟机调用 Native 方法服务。
3. 方法区（Methed Area）：用于存储已被虚拟机加载的类信息、常量、静态变量、即时编译后的代码等数据。
4. Java 堆（Java Heap）：Java 虚拟机中内存最大的一块，被所有线程共享，几乎所有的对象实例都在这里分配内存。
5. 程序计数器（Program Counter Register）：当前线程所执行的字节码的行号指示器，字节码解析器的工作是通过改变这个计数器的值，来选取下一条需要执行的字节码指令，分支、循环、跳转、异常处理、线程恢复等基础功能，都需要依赖此计数器完成。

在运行时数据区中，只有方法区和堆是各线程共享的进程内存区域，其他运行区都是每个线程可以独立拥有的。

图示：

本地方法栈：由C语言实现

本地方法栈：存放本地方法调用过程中的栈帧。

本地方法栈用于管理本地方法的调用，本地方法是C语言写的，被编译为基于本机硬件和操作系统的程序。

注意：不是所有虚拟机都支持本地方法栈，例如Hotspot虚拟机（HotSpot是Sun/OracleJDK和OpenJDK中的默认Java虚拟机）就是将本地方法栈和虚拟机栈合二为一。栈解决程序的运行问题，即程序如何执行、如何处理数据。

栈帧：栈帧是栈的元素，由三部分组成，即局部变量表（存方法参数和局部变量）、操作数栈（存方法执行过程中的中间结果，或者其他暂存数据）和帧数据区（存方法返回地址、线程引用等附加信息）。

Java方法栈（虚拟机栈）

存放Java方法调用过程中的栈帧。用于管理Java方法的调用。Java方法是开发时写的Java方法。

方法区

基本概念

方法区：可以看作是一块独立于Java堆的内存空间，方法区是各线程共享的内存区域。

实现方式：永久代和元空间

方法区有两种实现方式，分别是：永久代和元空间。

永久代：属于JVM方法区的内存，用来存储类的元数据，如类名、方法信息、字段信息等一些静态的数据。

永久代的特点：

• JDK7及之前方法区也叫永久代。
• 永久代的缺点是内存大小固定，容易出现oom问题。
• 可通过-XX:PermSize设置永久代大小。永久代对象只能通过Major GC（又称Full GC）进行垃圾回收。

元空间：是Hotspot在JDK8引入的，用于取代永久代。

元空间属于本地内存，由操作系统直接管理，不再受JVM管理。同时内存空间可自动扩容，避免内存溢出。默认情况下元空间可无限使用本地内存，也可通过-XX:MetaspaceSize限制内存大小。

方法区和永久代、元空间的关系：方法区是一个抽象概念，永久代和元空间是方法区的实现方式。

组成元素：类常量池、运行时常量池、字符串常量池

常量池：就是一张表，JVM根据这张常量表找到要执行的类信息和方法信息

• 类常量池：是.class字节码文件中的资源仓库，主要存放字面量（表示字符串值和数值，例如字符串值”abc”、final常量、静态变量）和符号引用（类和接口的全限定名、字段名、方法名）。
• 运行时常量池：类加载的“加载”阶段会创建运行时常量池，统一存放各个类常量池去重后的符号引用。在类加载的“解析”阶段JVM会把运行时常量池的这些符号引用转为直接引用。类常量池。类常量池在字节码文件中的，运行时常量池在内存中。
• 字符串常量池：专门针对String类型设计的常量池。是当前应用程序里所有线程共享的，每个jvm只有一个字符串常量池。存储字符串对象的引用。在创建String对象时，JVM会先在字符串常量池寻找是否已存在相同字符串的引用，如果有的话就直接返回引用，没的话就在堆中创建一个对象，然后常量池保存这个引用并返回引用。

堆

堆：存放对象实例、实例变量、数组，包括新生代（伊甸园区、幸存区S0和S1）和老年代。堆是垃圾收集器管理的内存区域。

堆解决的是数据存储的问题，即数据怎么放、放在哪儿。堆实际内存空间可以不连续，大小可以选择固定大小或可扩展，堆是各线程共享的内存区域。

堆的GC流程：

1. 首先，任何新对象都分配到 eden 空间。两个幸存者空间开始时都是空的。

2. 当 eden 空间填满时，将触发一个Minor GC(年轻代的垃圾回收，也称为Young GC)，删除所有未引用的对象，大对象（需要大量连续内存空间的Java对象，如那种很长的字符串）直接进入老年代。

3. 所有被引用的对象作为存活对象，将移动到第一个幸存者空间S0，并标记年龄为1，即经历过一次Minor GC。之后每经过一次Minor GC，年龄+1。GC分代年龄存储在对象头的Mark Word里。

4. 当 eden 空间再次被填满时，会执行第二次Minor GC，将Eden和S0区中所有垃圾对象清除，并将存活对象复制到S1并年龄加1，此时S0变为空。

5. 如此反复在S0和S1之间切换几次之后，还存活的年龄等于15的对象

   （JDK8默认15，JDK9默认7，-XX:InitialTenuringThreshold=7）在下一次Minor GC时将放到老年代中。

6. 如果老年代内存不足够存储新对象，则会执行Full GC（清空整个新生代和老年代）。

7. 当老年代满了时会触发Full GC或者Major GC（老年代的垃圾回收，清理整个老年代空间），Major GC 清理整个堆 – 包括年轻代和老年代。具体是Full GC还是Major GC取决于用哪个垃圾回收器，传统垃圾回收器会Full GC，G1（优先使用Mixed GC，清空部分新生代和老年代）、ZGC（直接抛出内存溢出错误）等现代回收器会避免Full GC。

程序计数器（PC寄存器）

程序计数器（PC寄存器）：存放下一条字节码指令的地址，由执行引擎读取下一条字节码指令并转为本地机器指令进行执行。是程序控制流（分支、循环、跳转、线程恢复）的指示器，只有它不会抛出OutOfMemoryError。每个线程有自己独立的程序计数器，以便于线程在切换回来时能知道下一条指令是什么。程序计数器生命周期与线程一致。

执行引擎

执行引擎：将字节码指令解释/编译为对应平台上的本地机器指令。充当了将高级语言翻译为机器语言的译者。

执行引擎在执行过程中需要执行什么样的字节码指令依赖于PC寄存器。每当执行完一项指令操作后，PC寄存器就会更新下一条需要被执行的指令地址。指令可以分为字节码指令和本地机器指令。

• 字节码指令（JVM指令）：字节码文件中的指令，内部只包含一些能够被JVM所识别的字节码指令、符号表，以及其他辅助信息，不能够直接运行在操作系统之上。
• 本地机器指令：可以直接运行在操作系统之上。

---

相关问题

堆栈的区别

功能方面：堆是用来存放对象的，栈是用来执行程序的。
共享性：堆是线程共享的，栈是线程私有的。
空间大小：堆大小远远大于栈。

队列和栈及其区别

队列和栈都是被用来预存储数据的。
队列允许先进先出检索元素，但也有例外的情况，Deque 接口允许从两端检索元素。
栈和队列很相似，但它运行对元素进行后进先出进行检索。

Java 中的引用类型

强引用：发生 gc 的时候不会被回收。
软引用：有用但不是必须的对象，在发生内存溢出之前被回收。
弱引用：有用但不是必须的对象，在下一次GC时被回收。
虚引用(幽灵引用/幻影引用)：无法通过虚引用获得对象，用 PhantomReference 实现虚引用，虚引用的用途是在 gc 时返回一个通知。

JVM 调优的工具

JDK 自带了很多监控工具，都位于 JDK 的 bin 目录下，其中最常用的是 jconsole 和 jvisualvm 这两款视图监控工具。
jconsole：对 JVM 中的内存、线程和类等进行监控；
jvisualvm：JDK 自带的全能分析工具，可以分析：内存快照、线程快照、程序死锁、监控内存的变化、gc 变化等。

常用的 JVM 调优的参数

-Xms2g：初始化推大小为 2g；
-Xmx2g：堆最大内存为 2g；
-XX:NewRatio=4：设置年轻的和老年代的内存比例为 1:4；
-XX:SurvivorRatio=8：设置新生代 Eden 和 Survivor 比例为 8:2；
–XX:+UseParNewGC：指定使用 ParNew + Serial Old 垃圾回收器组合；
-XX:+UseParallelOldGC：指定使用 ParNew + ParNew Old 垃圾回收器组合；
-XX:+UseConcMarkSweepGC：指定使用 CMS + Serial Old 垃圾回收器组合；
-XX:+PrintGC：开启打印 gc 信息；
-XX:+PrintGCDetails：打印 gc 详细信息。

内存溢出的情况

• JVM Heap（堆）溢出：java.lang.OutOfMemoryError: Java heap space
  • JVM在启动的时候会自动设置 JVM Heap 的值， 可以利用JVM提供的-Xmn -Xms -Xmx等选项可进行设置。
  • Heap的大小是Young Generation 和Tenured Generaion 之和。
  • 在JVM中如果98%的时间是用于GC，且可用的Heap size 不足2%时将抛出此异常信息。
• 解决方法：手动设置JVM Heap（堆）的大小。
• Permanent Generation space（内存的永久保存区域）溢出： java.lang.OutOfMemoryError: PermGen space
  • 这块内存主要是被 JVM 存放 Class 和 Meta 信息的，Class在被Load的时候被放入 PermGen space 区域，它和存放 Instance 的Heap区域不同，sun 的 GC 不会在主程序运行期对PermGen space进行清理，所以如果你的 APP 会载入很多 CLASS 的话，就很可能出现 PermGen space 溢出。一般发生在程序的启动阶段。
• 解决方法： 通过-XX:PermSize和-XX:MaxPermSize设置永久代大小。
• 栈溢出： java.lang.StackOverflowError : Thread Stack space
  • 栈溢出了，JVM是采用栈式的虚拟机，这个和C和Pascal一样。函数的调用过程都体现在堆栈和退栈上了。调用构造函数的 “层”太多以致于把栈区溢出了。 一般栈区远远小于堆区，因为函数调用过程往往不会多于上千层，而即便每个函数调用需要 1K的空间（这大约相当于在一个C函数内声明了256个int变量），那么栈区也不过是需要1MB的空间。
  • 通常栈的大小是1-2MB。通俗点讲就是单线程的程序所需内存太大了。 通常递归也不要递归的层次过多，很容易溢出。
• 解决方法：
  • 修改程序。
  • 通过 -Xss: 来设置每个线程的Stack大小。

---

垃圾回收

怎么判断对象是否可以被回收

一般有两种方法来判断：

1. 引用计数器：为每个对象创建一个引用计数，有对象引用时计数器 +1，引用被释放时计数 -1，当计数器为 0 时就可被回收。它有一个缺点不能解决循环引用问题；
2. 可达性分析：从 GC Roots 开始向下搜索，搜索所走过的路径称为引用链。当一个对象到 GC Roots 没有任何引用链相连时，则证明此对象是可以被回收的。

JVM 有哪些垃圾回收算法

1. 标记-清除算法：标记无用对象，然后进行清除回收。缺点：效率不高，无法清除垃圾碎片。
2. 标记-整理算法：标记无用对象，让所有存活的对象都向一端移动，然后直接清除端边界以外的内存。
3. 复制算法：按照容量划分两个大小相等的内存区域，当一块用完的时候将活着的对象复制到另一块上，然后再把已使用的内存空间一次清理掉。缺点：内存使用率不高，只有原来的一半。
4. 分代算法：根据对象存活周期的不同将内存划分为几块，一般是新生代和老年代，新生代基本采用复制算法，老年代采用标记整理算法。

JVM 有哪些垃圾回收器

• Serial：最早的单线程串行垃圾回收器。

• Serial Old：Serial 垃圾回收器的老年版本，同样也是单线程的，可以作为 CMS 垃圾回收器的备选预案。

• ParNew：是 Serial 的多线程版本。

• Parallel ： 多线程的， 使用复制的内存回收算法。但 Parallel 是吞吐量优先的收集器，可以牺牲等待时间换取系统的吞吐量。

• Parallel Old：是 Parallel 老生代版本，Parallel Old 使用标记-整理的内存回收算法。

• CMS：一种以获得最短停顿时间为目标的收集器，非常适用 B/S 系统。

• G1：一种兼顾吞吐量和停顿时间的 GC 实现，是 JDK 9 以后的默认 GC 选项。

CMS 垃圾回收器

CMS 是英文 Concurrent Mark-Sweep 的简称，是以牺牲吞吐量为代价来获得最短回收停顿时间的垃圾回收器。对于要求服务器响应速度的应用上，这种垃圾回收器非常适合。在启动 JVM 的参数加上“-XX:+UseConcMarkSweepGC”来指定使用 CMS 垃圾回收器。
CMS 使用的是标记-清除的算法实现的，所以在 gc 的时候会产生大量的内存碎片，当剩余内存不能满足程序运行要求时，系统将会出现 Concurrent Mode Failure，临时 CMS 会采用 Serial Old 回收器进行垃圾清除，此时的性能将会被降低。

新生代垃圾回收器和老生代垃圾回收器分类及区别

• 新生代回收器：Serial、ParNew、Parallel Scavenge
• 老年代回收器：Serial Old、Parallel Old、CMS
• 整堆回收器：G1

新生代垃圾回收器一般采用的是复制算法，复制算法的优点是效率高，缺点是内存利用率低；
老年代回收器一般采用的是标记-整理的算法进行垃圾回收。

分代垃圾回收器工作流程

分代回收器有两个分区：老生代和新生代，新生代默认的空间占比总空间的 1/3，老生代的默认占比是 2/3。
新生代使用的是复制算法，新生代里有 3 个分区：Eden、To Survivor、From Survivor，它们的默认占比是 8:1:1。
它的执行流程如下：

• 把 Eden + From Survivor 存活的对象放入 To Survivor 区；
• 清空 Eden 和 From Survivor 分区；
• From Survivor 和 To Survivor 分区交换（From Survivor 变 To Survivor，To Survivor 变 From Survivor）
• 每次在 From Survivor 到 To Survivor 移动时都存活的对象，年龄 +1，当年龄到达 15（默认配置是 15）时，升级为老生代。大对象也会直接进入老生代。
• 老生代空间占用到达某个值后就触发全局垃圾收回，一般使用标记整理执行算法。

以上这些循环往复就构成了整个分代垃圾回收的整体执行流程。