JVM八股文

目录

一、JVM内存划分

二、类加载的过程

双亲委派模型

三、JVM垃圾回收机制GC

找垃圾的策略

释放垃圾的策略

---

一、JVM内存划分

JVM也就是Java进程，这个进程跑起来后会向操作系统申请一大块内存空间，JVM接下来要进一步的对这块内存空间进行划分，划分成不同区域，每个区域有不同的功能，具体的图如下：

1、堆：整个内存区最大的一块空间，主要存放new出来的对象（成员变量）

2、栈，本地方法栈&虚拟机栈，用来存放方法之间的调用关系（局部变量）

3、元数据区，存放类对象：代码中的每个类在运行时在JVM上都会有对应的类对象；方法相关信息：类有一些方法，每个方法都代表了一系列的指令合集；常量池；

4、程序计数器，内存区中最小的一块空间，主要存放要执行的下一条指令（JVM字节码）的地址（元数据区的一个地址）

这四个区域，堆和元数据区整个进程只有一份，栈和程序计数器每个线程一份

二、类加载的过程

写的java代码是.java文件（硬盘），一个进程要跑起来（要执行的指令通过字节码让jvm翻译出来）要将.java变为.class(硬盘)加载到内存中得到类对象

类加载的几个环节：

1、加载：在硬盘上找到对应的.class文件读取文件内容

2、验证：看文件中的内容是否符合要求（.class文件的格式在java官方文档中是有明确定义的，将读出来的文件往这个格式里套，看能不能套进去就可以知道是否符合要求）

3、准备：给类对象分配内存空间（类加载最终要得到的就是类对象），会把元数据区中的这块空间先全部填充为0

4、解析：针对字符串常量进行初始化，将刚才.class文件中常量的内容取出来放到元数据区

5、初始化：针对类对象进行初始化，给静态成员初始化，执行静态代码块

此时类对象就搞定了，后续可以使用这个类对象创建实例或者使用里面的静态成员

双亲委派模型

出现在类加载环节的第一步——加载，根据代码中给出的全限定类名找到对应的.class文件。

双亲委派模型描述了JVM加载.class文件过程中，找文件的过程；

类加载器：在JVM中负责一个特定的模块，这个模块负责完成后续的类加载工作。JVM中内置了三个类加载器：

（1）BootStrapClassLoader：负责加载标准库的类（爷爷）

（2）ExtentionClassLoader：负责加载JVM扩展库的类（父亲）

（3）ApplicantClassLoader:负责加载第三方库的类和程序员自己写的类（儿子）

此处的父子关系不是类继承那样的父子关系，而是类加载器中有一个parent字段指向了自己的父亲（类似于二叉树的三叉实现形式）

实现过程：

比如自己给定一个全限定类名java.Test

（1）工作从ApplicationClassLoader开始进行，它不会立即搜索第三方库的类而是将任务交给他的父亲来处理

（2）工作到了ExtentionClassLoader，它不会立即搜索JVM扩展库而是将任务交给它的父亲来处理

（3）工作到了ApplicationClassLoader，它也想先将任务交给父类，而它的parent指向空，所以它开始搜索标准库中是否存在上述类，如果在标准库中找到这个类了，那么搜索任务完成了，类加载器进行打开文件读取文件等后续操作；如果在标准库中没找到这个类，那么将任务交给它的儿子来进行搜索

（4）工作到了ExtentionClassLoader，它开始搜索扩展库中的目录是否存在上述类，如果在标准库中找到这个类了，那么搜索任务完成了，类加载器进行打开文件读取文件等后续操作；如果在标准库中没找到这个类，那么将任务交给它的儿子来进行搜索

（5）工作回到了ApplicationClassLoader，此时要搜索第三方库的目录了，找到了就进行操作，没找到会返回ClassNotFoundException异常

上述过程主要为了应对这个场景：你写的类名与标准库/扩展库的冲突了，JVM会保证加载的类是标准库的类

三、JVM垃圾回收机制GC

垃圾回收机制是Java提供对于内存自动回收的机制，GC需要消耗额外的系统资源而且存在非常影响系统资源的“STW”问题（触发GC时可能一瞬间将系统载荷拉满，导致服务器无法处理其他请求）。

GC回收的内存，更准确的说是对象，回收的堆上的内存（一定是一次回收一个完整的对象，比如说一个对象有十个成员，一次要将十个成员都回收）

GC回收的流程主要是两个步骤：

（1）找到谁是垃圾

（2）释放对应内存

在编程中一定要确保每个对象是有效的，千万不能出现提前释放的情况，此处引入非常保守的办法：判断某个对象是否存在引用指向它（使用对象都是通过引用的方式，如果没有引用指向它说明这个对象无法被使用）

找垃圾的策略

具体怎么判断一个对象是否被引用呢？

这里介绍两种方式：
（1）引用计数：在堆上每个对象本体旁边都会有一个计数器，有一个引用指向就加一，少一个就减一，当为0时则没有引用指向

两个缺陷：消耗额外的存储空间，如果对象较大浪费的空间还好，如果对象较小空间占用就多了

存在循环引用问题：

当代码执行到这里时，两个对象的引用都为1；

此时因为引用的成员变量指向了两个对象，所以此时计数都为2

此时将a和b都置为空，计数器都减为了1，但这个时候已经没有引用指向这两个对象也就是我们无法使用这两个对象，但它们的程序计数器却不为空，不能释放

（2）可达性分析

解决了空间问题也解决了循环引用的问题，但付出了很多时间

JVM把对象之间的引用关系理解成树形结构，JVM会不停访问遍历这样结构，能够遍历到的对象标记为可达，剩下的就是不可达。比如说遍历二叉树时，只要有一个根节点就可以遍历到所有的节点，如果将根节点的左子树节点置为空，那么左子树底下的所有节点都会被标记为不可达。

写代码时把类创建好，把对象实例化好，这样的结构就已经存在了

GC会将Java代码中所有的：栈上的局部变量/常量池的引用对象/方法区的静态成员确定为GC roots

释放垃圾的策略

1、标记清除：直接把标为垃圾的对象对应的内存释放掉，这样做造成内存碎片化问题（空闲内存被分为一个一个碎片，后续很难申请到大的连续的空间）

2、复制算法

比如要释放掉135的内存，不会直接将135释放，而是将246先拷贝到另一块空间后将左边全部释放。解决了内存碎片问题，但是空间浪费太多

3、标记整理

能够解决空间碎片化问题也能解决空间浪费问题

释放246，将246的位置被要保留的元素直接覆盖，类似于顺序表删除中间元素的搬运，缺点是消耗的时间更大。

JVM实际的方案是上述三种的结合版——分代回收（分情况讨论，根据不同的场景和特点选择合适的方案）这里就是根据对象的年龄来讨论：GC有一组线程周期性扫描，如果经历一轮GC还是存在，那么对象的年龄+1

分代回收的基本逻辑：

新创建的对象放入伊甸区（Eden），伊甸区的大部分对象生命周期较短，第一轮GC就会称为垃圾，只有少数会活过第一轮GC，伊甸区->生存区（S0）（通过复制算法）

生存区到另一个生存区（S1）（复制算法）

每经过一轮GC生存区都会淘汰掉一批对象，剩下的通过复制算法进入另一个生存区，存活下来的年龄+1

生存区->老代区（Old）某些对象经历很多轮GC都没有被淘汰就会进入老代区，老代区的生命周期都较长，可以降低GC扫描频率。

感谢观看

道阻且长，行则将至