在这里插入图片描述

请添加图片描述

⭐️前言⭐️

本篇文章，博主分享的是在面试中JVM常考的考点，希望这篇文章能够对你有用。

🍉博客主页： 🍁【如风暖阳】🍁
🍉精品Java专栏【JavaSE】、【备战蓝桥】、【JavaEE初阶】、【MySQL】、【数据结构】
🍉欢迎点赞 👍 收藏 ⭐留言评论 📝私信必回哟😁

🍉本文由【如风暖阳】原创，首发于 CSDN🙉

🍉博主将持续更新学习记录收获，友友们有任何问题可以在评论区留言

🍉博客中涉及源码及博主日常练习代码均已上传码云(gitee)、GitHub

请添加图片描述

📍内容导读📍

🍅1.JVM执行流程
🍅2.JVM内存区域划分
- 2.1 程序计数器
- 2.2 栈
- 2.3 堆
- 2.4 方法区
🍅3.JVM类加载机制
- 3.1 类加载过程
- - 3.1.1 Loading
  - 3.1.2 Linking
  - 3.1.3 Initializing
- 3.2 典型面试题
- - 3.2.1 代码块的执行先后
  - 3.2.2 双亲委派模型
🍅4.JVM的垃圾回收(GC)
- 4.1 什么垃圾需要回收？
- 4.2 如何找垃圾（判定垃圾）？
- - 4.2.1 基于引用计数
  - 4.2.2 基于可达性分析
- 4.3 垃圾如何回收（释放内存）？
- - 4.3.1 标记-清除算法
  - 4.3.2 复制算法
  - 4.3.3 标记-整理算法
  - 4.3.4 分代回收算法
- 4.4 垃圾收集器
- - 4.4.1 串行收集器
  - 4.4.2 并行收集器
  - 4.4.3 CMS收集器
  - 4.4.4 G1收集器

请添加图片描述

🍅1.JVM执行流程

程序在执行之前先要把Java代码转换成字节码（class文件），JVM首先需要把字节码通过一定的方式如类加载器(ClassLoader)，把文件加载到内存中的运行时数据区(Runtime Data Area),而字节码文件是JVM的一套指令集规范，并不能直接交给底层操作系统去执行，因此需要特定的命令解析器执行引擎(Execution Engine),将字节码翻译成底层系统指令再交给CPU去执行，而这个过程中需要调用其他语言的接口本地库接口(Native Interface),来实现整个程序的功能，这就是这4个主要组成部分的职责与功能。
在这里插入图片描述

🍅2.JVM内存区域划分

JVM的内存区域的划分就是指JVM的 运行时数据区(Runtime Data Area) 的划分,按照规范，其可以划分为以下几个区域：
在这里插入图片描述
JVM内存分为线程私有区和线程共享区，其中方法区和堆是线程共享区，栈和程序计数器是线程隔离的私有数据区。

2.1 程序计数器

该区域是内存中最小的区域，保存了下一条要执行的指令（指令就是字节码）的地址在哪里。

程序要想运行，JVM就需要把字节码加载起来放到内存中，然后程序把一条一条的指令从内存中取出来，放到CPU上执行，由于CPU是并发式执行程序的，它同时为多个进程服务，线程则更多，所以每个线程都得记录自己的执行位置，即每个线程都有一个程序计数器。

2.2 栈

在该区域存储的有局部变量和方法调用信息

在方法调用的时候，每次调用一个新的方法，就都涉及到入栈操作，每次执行完了一个方法，就都涉及到出栈，每个线程都有这样一份栈。

2.3 堆

实例对象(new 出来的实例)在该区域存储

因为实例对象在堆区域存储，所以对象的成员变量也在该区域存储。

一个进程只有一份堆，多个线程共用一个堆

2.4 方法区

类对象存储在方法区中

程序的.java文件转为.class字节码文件后，通过类加载器加载到内存中，就被JVM构造成了类对象，此处的类对象就在方法区中；
类对象描述了这个类的细节，类的名字、里面有哪些成员/方法，每个成员/方法叫啥名字是啥类型等类信息。
类对象中还有很重要的静态成员，也就是被static修饰的成员，其也是类属性；而普通的成员，叫做实例属性。

🍅3.JVM类加载机制

3.1 类加载过程

JVM的类加载，就是为了把.class文件加载到内存中，构建成类对象；具体加载过程见下图：
在这里插入图片描述
类加载包括三个步骤：Loading,Linking,Initializing
可参考官方文档：https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-5.html

3.1.1 Loading

先找到对应的.class文件，然后打开并读取.class文件，把读取并解析到的信息，初步的填写到生成的类对象中。

.class文件的格式如下图，JVM就按照这个格式来加载生成类对象

3.1.2 Linking

1)Verification
校验阶段

主要就是验证读到的内容是不是和规范中的规定格式完全匹配，如果发现这里读到的数据格式不符合规范，就会类加载失败，并且抛出异常。

2)Preparation
准备阶段

该阶段主要完成的工作是正式为类中定义的变量（即被staitic修饰的静态变量）分配内存，并设置类变量的初始值。

3)Resolution
解析阶段

该阶段主要完成的工作是Java虚拟机将常量池内的符号引用替换为直接引用的过程，也就是初始化常量的过程。

3.1.3 Initializing

真正地对类对象进行初始化，特别是静态成员，Java虚拟机真正开始执行类中编写的Java程序代码，将主导权移交给应用程序。

3.2 典型面试题

3.2.1 代码块的执行先后

执行以下代码块：

class A {
    public A() {
        System.out.println("A的构造方法");
    }
    {
        System.out.println("A的构造代码块");
    }
    static {
        System.out.println("A的静态代码块");
    }
}

class B extends A {
    public B() {
        System.out.println("B的构造方法");
    }
    {
        System.out.println("B的构造代码块");
    }
    static  {
        System.out.println("B的静态代码块");
    }
}
public class Test {
    public static void main(String[] args) {
        new B();
        System.out.println("----------");
        new B();
    }
}

//
A的静态代码块
B的静态代码块
A的构造代码块
A的构造方法
B的构造代码块
B的构造方法
----------
A的构造代码块
A的构造方法
B的构造代码块
B的构造方法

由以上代码的执行结果可得：

对象创建时代码的加载顺序为：静态代码–>非静态代码–>构造方法

若继承了父类，则加载顺序为：父类的静态代码块–>子类的静态代码块–>父类内部非静态代码–>父类的构造方法–>子类的非静态代码块–>子类的构造方法

静态代码块在类加载的时候只会执行一次，再实例化对象时并不会再次执行静态代码块。

3.2.2 双亲委派模型

双亲委派模型，描述的是JVM中的类加载器，如何根据类的全限定名(java.lang.String)来找到.class文件的过程。

类加载器是专门负责进行类加载的对象，默认的类加载器主要有三个，每个类加载器负责一个片区：

1.启动类加载器 (Bootstrap Class Loader)
负责加载标准库中的类(String,ArrayList,Random,Scanner…)

2.扩展类加载器 (Extension Class Loader)
负责加载JDK中扩展的类（较少用到）

3.应用程序类加载器（Application Class Loader）
负责加载当前项目目录中的类

程序猿还可以自定义类加载器，来加载其他目录中的类

例如Tomcat就自定义了类加载器，用来专门加载webapps里面的.class

双亲委派模型就描述了上述类加载器如何通过配合，来找目录的过程：
在这里插入图片描述

1）加载java.lang.String

a. 程序启动，先进入ApplicationClassLoader类加载器。

b. ApplicationClassLoader会检查其父加载器是否已经加载过了；如果没有就调用父 类加载器 ExtensionClassLoader

c. ExtensionClassLoader也会检查其父加载器是否加载过了；如果没有就调用父 类加载器 BootStrapClassLoader

d. BootStrapClassLoader也会检查其父加载器是否加载过了；但因为其没有父加载器，于是就扫描自己负责的目录

e. java.lang.String这个类在标准库中能找到，则直接由BootStrapClassLoader负责后续的加载过程

在这里插入图片描述
2）加载自己写的Test类
a. 程序启动，先进入ApplicationClassLoader类加载器。

b. ApplicationClassLoader会检查其父加载器是否已经加载过了；如果没有就调用父 类加载器 ExtensionClassLoader

c. ExtensionClassLoader也会检查其父加载器是否加载过了；如果没有就调用父 类加载器 BootStrapClassLoader

d. BootStrapClassLoader也会检查其父加载器是否加载过了；但因为其没有父加载器，于是就扫描自己负责的目录；没有扫描到，回到子加载器继续扫描

e. ExtensionClassLoader也扫描自己的目录，也没扫描到，回到子加载器继续扫描

f. ApplicationClassLoader也扫描自己负责的目录，能找到Test类，于是进行后续加载，查找目录环节结束

如果最终ApplicationClassLoader也找不到，就会抛出ClassNotFoundException的异常

在这里插入图片描述
这样的查找规则就叫做双亲委派模型

🍅4.JVM的垃圾回收(GC)

在我们写代码的时候，经常会通过创建变量，new 对象或者加载类等方式来申请内存，但我们不能只申请内存而不释放。

申请内存的时机我们一般都是明确的（需要保存某些数据时，就需要申请内存），但是释放内存的时机，则不是那么清楚；

内存释放的早或者晚都会影响开发效率，所以我们需要让内存释放的时机恰到好处；

Java，Go，Python等较为主流的编程语言就采取了垃圾回收机制（GC），靠运行时环境额外多做一些工作，来完成释放内存的操作，让程序猿的工作量减少。

同样，垃圾回收机制也带来了一些劣势：

消耗额外的开销（消耗的资源更多了）
可能会影响程序的流畅运行（会引入STW问题）

STW<=>Stop The World 时间静止，就是卡了。

4.1 什么垃圾需要回收？

在JVM的内存中，划分有很多区域，我们在2中也有介绍，但是不是这些所有的区域都需要进行垃圾回收；

程序计数器占据固定大小的内存，不涉及释放，所以也就用不到GC；栈在函数执行完毕后，对应的栈帧就自动释放了，也不需要GC；堆是最需要GC的，因为代码中大量的内存都是在堆上；方法区中存储类对象，进行类卸载操作需要释放内存，但类卸载操作是一个非常低频的操作，所以也不需要过多考虑，只需考虑堆区域内存的垃圾回收即可。

在堆区域中，空间被分为三部分，一部分是正在使用的内存，一部分是不再使用，但尚未回收的内存，另一部分是未分配的内存；同时也有三类对象在这三部分区域中存在，一种是“积极派”，一种是“消极派”，还有另一种是“中间摇摆派”。
在这里插入图片描述
在上述的三个对象中，JVM只会回收“消极派”对象，GC回收是以对象为单位的，并不会出现半个对象的情况。

我们知道了什么垃圾需要回收，下边就需要我们来进行具体的垃圾回收操作，第一阶段需要我们找垃圾（判别垃圾），第二阶段就是释放垃圾，下边具体介绍：

4.2 如何找垃圾（判定垃圾）？

4.2.1 基于引用计数

该方案的具体操作是，针对每个对象，都会额外引入一小块内存，保存这个对象有多少个引用，当这个引用计数为0时，也就说明这个内存不再使用了，就释放了。

void func() {
	Test t=new Test();
	Test t2=t;//t和t2都是指向new对象的引用
}

在这里插入图片描述
如上边的func()方法的调用过程中，创建了分配对象（分配了内存），在方法的执行过程中，引用计数是2，当方法执行结束后，由于t和t2都是局部变量，就跟随栈帧一起释放了，如此而来引用计数就变为了0，此时就认为这个对象是垃圾。

通过引用计数的方法来找垃圾，确实简单可靠高效，但也存在两个问题：

1.空间利用率较低
每个new的对象都需要额外开辟一块空间来存储计数器，如果对象本身就很小，而且还需要计数器，就会导致空间浪费很大。

2.会有循环引用的问题
通过以下代码来引入这个问题：

class Test {
	Test t=null;
}
Test t1=new Test();
Test t2=new Test();

t1.t=t2;
t2.t=t1;
---------------------
t1=null;
t2=null;
//代码执行到这里就会出现循环引用的问题

在这里插入图片描述
在代码执行完最后一行后，两个对象的引用计数不为0，但是引用在彼此身上，外界的代码无法访问到这两个对象，此时此刻，这两个对象既不能使用，也不能释放，就出现了“内存泄漏”的问题。

4.2.2 基于可达性分析

该方案是Java采取的方案。

可达性分析就是通过额外的线程，对整个内存空间的对象进行扫描，首先会找到一些起始位置GCRoots，从这些位置开始，以类似深度优先搜索的方式去遍历对象，它会对所有可以到达的对象进行标记，无法到达的对象自然也就没有标记，就被视为垃圾。
在这里插入图片描述
可以作为GCRoots的对象有以下几种：