JVM【八股文】

JVM内存区域划分

程序计数器
栈
堆
方法区

一块大的区域，需要根据功能，来划分不同的小区域。

JVM内存是从操作系统里申请来的，之后堆这部分区域进行了划分。

1.程序计数器

内存中最小的区域，保存了下一条要执行指令的地址~~

指令 => 字节码~

程序要想运行，JVM就得把字节码加载起来，放到内存中_{，程序就会一条一条把指令从内存中取出来，放到CPU上执行，此时也就需要随时记住，当前执行到哪一条了}~

CPU是并发式的执行程序，CPU不是只给你一个进程提供服务。

也正因此，操作系统以线程为单位进行调度，每个线程都得记录自己的执行位置，每个线程就都会有一个程序计数器。

2.栈

局部变量和方法调用信息

方法调用的时候，每次调用一个新的方法，就会涉及“入栈”操作，每次执行完一个方法，就会涉及到“出栈”操作。

每个线程有一个栈

3.堆

内存中空间最大的区域

new出来的对象+对象的成员变量在其中。

一个进程一个堆

多个线程共用一个堆

局部变量在栈上；成员变量和new对象，在堆上。

4.方法区

类对象

方法区的作用：用来存储被虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码等数据
的。

JVM类加载机制

1.类加载是要干啥？

把.class文件，加载到内存中，构成类对象

在这里插入图片描述

加载

先找到对应的 .class文件，然后打开并读取.class文件，同时初步生成一个类对象

Loading中的一个关键环节，会把读取并解析到的信息，初步的填写到类对象中。
连接
1. 验证
2. 准备 ->给静态变量分配内存，并且设置上0值
3. 解析
初始化

真正的对类对象进行初始化，尤其是针对静态成员

2.典型面试题

在这里插入图片描述

大的原则：

类加载阶段会进行静态代码块的执行。要想创建实例，势必要先进行类加载。
静态代码块代码块只是在类加载阶段执行一次。
构造方法和构造代码块，每次实例化都会执行，构造代码块在构造方法前面。
父类执行在前子类执行在后

在这里插入图片描述

注意：只要这个类被调用到，就会先对这个类进行类加载（实例化、调用方法、调用静态方法、被继承等）

3.关于“双亲委派模型”

它是类加载中的一个环节

这个环节处于 Loading 阶段的

双亲委派模型，描述的就是JVM中的类加载器，如何根据类的全限定名（java.lang.String）找到.class文件的过程
类加载器：JVM提供了专门的对象，叫做类加载器，负责进行类加载，当然找到文件的过程也是类加载来负责
.class文件，可能放在的位置有好多，有的在JJDK目录中，有的在项目目录中，还有的在其他指定位置，因此JVM里面提供了多个类加载器，每个类加载器负责一个片区
默认的类加载器有三个：
- (1): 引导类加载器(Bootstrap类加载器)
  它是由本地代码(c/c++)实现的，你根本拿不到他的引用，但是他实际存在，并且加载一些重要的类，它加载(%JAVA_HOME%\jre\lib),如rt.jar(runtime)、i18n.jar等，这些是Java的核心类。他是用原生代码来实现的，并不继承自 java.lang.ClassLoader。
- (2): 扩展类加载器(Extension类加载器)
  虽说能拿到，但是我们在实践中很少用到它，它主要加载扩展目录下的jar包， %JAVA_HOME%\lib\ext
- (3): 系统类加载器(System类加载器)
  它主要加载我们应用程序中的类，如Test,或者用到的第三方包,如jdbc驱动包等。
  这里的父类加载器与类中继承概念要区分，它们在class定义上是没有父子关系的。

双亲委派模型，就是描述这个找目录过程，也就是上述类加载器是如何配合的？

AppClassLoader 在加载一个未知的类名时，它并不是立即去搜寻 Classpath，它会首先将这个类名称交给 ExtensionClassLoader 来加载，如果 ExtensionClassLoader 可以加载，那么 AppClassLoader 就不用麻烦了。否则它就会搜索 Classpath 。

而 ExtensionClassLoader 在加载一个未知的类名时，它也并不是立即搜寻 ext 路径，它会首先将类名称交给 BootstrapClassLoader 来加载，如果 BootstrapClassLoader 可以加载，那么 ExtensionClassLoader 也就不用麻烦了。否则它就会搜索 ext 路径下的 jar 包。

JVM的垃圾回收【重点】

JVM中的垃圾回收机制（GC）

申请内存的时机一般都是明确的（需要保存某个数据，就需要申请内存），

但是释放内存的时间，则是不清楚的。

代码里，创建一个变量（申请一个内存），这个变量啥时候不再使用了？也不是那么容易能确定的

如果内存释放的时机有问题（内存还想要用，结果就被丢了），此时就很难受了

上面是内存释放太早了

要是我迟一点释放行不行呢？就像图书馆，占座~~

所以内存的释放，早了也不行，晚了也不行，需要恰到好处。

垃圾回收的劣势：

消耗额外的开销
可能会影响程序的流畅运行（垃圾回收经常会引入STW问题）

垃圾回收要回收些啥？

程序计数器：固定大小，不涉及到释放，也就不需要GC
栈：函数执行完毕，对应的栈帧就自动释放了，也不需要GC
堆：需要GC，代码中大量的内存都在堆上
方法区：类对象，类加载来的~~ 进行“类卸载”就需要释放内存，卸载其实是一个非常低频的操作。

垃圾回收具体咋回收？

第一阶段：找垃圾/判断垃圾

1. 基于引用计数（不是Java）
  
  简单可靠高效，但是有两个致命缺陷！
  - 空间利用率比较低
  - 会有循环引用问题
2. 基于可达性分析（Java）
  
  起始位置GCroot
  - 栈上的局部变量
  - 常量池中的引用指向的对象
  - 方法区中的静态成员指向的对象
  优点：
  - 克服了引用计数的两个缺点：空间利用率低，循环引用
  自身缺点:
  - 系统开销大，遍历一次可能比较慢

第二阶段：释放垃圾

明确了谁是垃圾之后，接下来就是回收（释放）垃圾了

回收垃圾（释放垃圾）的三种基本策略：

标记-清除

标记就是可达性分析的过程

此时如果直接放掉，虽然内存还是还给了系统，但是被释放的内存是离散的（不是连续的）

这个问题非常影响程序的执行
复制算法

为了解决内存碎片，引入复制算法

直接把不是垃圾的，拷贝，把原本的空间整体释放

此时内存碎片问题迎刃而解

复制算法的问题：
- 内存空间利用率低
- 如果要保留的对象多，要释放的对象少，此时复制的开销很大
标记-整理

针对复制算法，再进行改进。

类似于顺序表删除中间元素

这个方案空间利用率是高了，但是仍然没有解决复制/搬运元素的开销。