JVM虚拟机与 GC 垃圾回收

港控/mmm° 2023-07-04 14:14 20阅读 0赞

## 个人博客网：[https://wushaopei.github.io/][https_wushaopei.github.io]    (你想要这里多有) ##

## 一、JVM体系结构概述 ##

### **1、JVM 与系统、硬件** ###

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjQwNTY3MA_size_16_color_FFFFFF_t_70][]

**JVM**是运行在操作系统之上的，它与硬件没有直接的交互

### **2、JVM 体系结构概览** ###

![20200211211323753.png][]

### **3、类装载器ClassLoader 执行原理** ###

负责加载class文件，class文件在文件开头有特定的文件标示，并且ClassLoader只负责class文件的加载，至于它是否可以运行，则由Execution Engine决定

![20200211211521670.png][]

### **4、类装载器ClassLoader装载流程（双亲委派）** ###

![20200211211624374.png][]

*  虚拟机自带的加载器
 *  启动类加载器（Bootstrap）C++
 *  扩展类加载器（Extension）Java
 *  应用程序类加载器（AppClassLoader）Java                                                                                                                            也叫系统类加载器，加载当前应用的classpath的所有类
 *  用户自定义加载器                                                                                                                                                        Java.lang.ClassLoader的子类，用户可以定制类的加载方式

**注**：Execution Engine执行引擎负责解释命令，提交操作系统执行。

--------------------

![20200211211323753.png][]

--------------------

### **5、Native Interface本地接口** ###

本地接口的作用是融合不同的编程语言为 Java 所用，它的初衷是融合 C/C++程序，Java 诞生的时候是 C/C++横行的时候，要想立足，必须有调用 C/C++程序，于是就在内存中专门开辟了一块区域处理标记为native的代码，它的具体做法是 Native Method Stack中登记 native方法，在Execution Engine 执行时加载native libraies。

目前该方法使用的越来越少了，除非是与硬件有关的应用，比如通过Java程序驱动打印机或者Java系统管理生产设备，在企业级应用中已经比较少见。因为现在的异构领域间的通信很发达，比如可以使用 Socket通信，也可以使用Web Service等等，不多做介绍。

### **6、Native Method Stack（本地方法栈）** ###

它的具体做法是Native Method Stack中登记native方法，在Execution Engine 执行时加载本地方法库。

### **7、PC寄存器** ###

每个线程都有一个程序计数器，是线程私有的,就是一个指针，指向方法区中的方法字节码（用来存储指向下一条指令的地址,也即将要执行的指令代码），由执行引擎读取下一条指令，是一个非常小的内存空间，几乎可以忽略不记。

这块内存区域很小，它是当前线程所执行的字节码的行号指示器，字节码解释器通过改变这个计数器的值来选取下一条需要执行的字节码指令。

如果执行的是一个Native方法，那这个计数器是空的。

用以完成分支、循环、跳转、异常处理、线程恢复等基础功能。不会发生内存溢出(OutOfMemory=OOM)错误

### **8、 Method Area 方法区** ###

方法区是被所有线程共享，所有字段和方法字节码，以及一些特殊方法如构造函数，接口代码也在此定义。简单说，所有定义的方法的信息都保存在该区域，此区属于共享区间。  
静态变量+常量+类信息(构造方法/接口定义)+运行时常量池存在方法区中

But  
实例变量存在堆内存中,和方法区无关

### **9、Stack 栈** ###

栈也叫栈内存，主管Java程序的运行，是在线程创建时创建，它的生命期是跟随线程的生命期，线程结束栈内存也就释放，对于栈来说不存在垃圾回收问题，只要线程一结束该栈就Over，生命周期和线程一致，是线程私有的。8种基本类型的变量+对象的引用变量+实例方法都是在函数的栈内存中分配。

9.1 栈存储什么？

栈帧中主要保存3 类数据：

*  本地变量（Local Variables）:输入参数和输出参数以及方法内的变量；
 *  栈操作（Operand Stack）:记录出栈、入栈的操作；
 *  栈帧数据（Frame Data）:包括类文件、方法等等。

9.2 栈运行原理

栈中的数据都是以栈帧（Stack Frame）的格式存在，栈帧是一个内存区块，是一个数据集，是一个有关方法(Method)和运行期数据的数据集，当一个方法A被调用时就产生了一个栈帧 F1，并被压入到栈中，  
A方法又调用了 B方法，于是产生栈帧 F2 也被压入栈，  
B方法又调用了 C方法，于是产生栈帧 F3 也被压入栈，  
……  
执行完毕后，先弹出F3栈帧，再弹出F2栈帧，再弹出F1栈帧……

遵循“先进后出”/“后进先出”原则。

每个方法执行的同时都会创建一个栈帧，用于存储局部变量表、操作数栈、动态链接、方法出口等信息，每一个方法从调用直至执行完毕的过程，就对应着一个栈帧在虚拟机中入栈到出栈的过程。栈的大小和具体JVM的实现有关，通常在256K~756K之间。

![20200211213639604.png][]

图示在一个栈中有两个栈帧：

*  栈帧 2是最先被调用的方法，先入栈，
 *  然后方法 2 又调用了方法1，栈帧 1处于栈顶的位置，
 *  栈帧 2 处于栈底，执行完毕后，依次弹出栈帧 1和栈帧 2，
 *  线程结束，栈释放。

每执行一个方法都会产生一个栈帧，保存到栈(后进先出)的顶部，顶部栈就是当前的方法，该方法执行完毕 后会自动将此栈帧出栈。

![20200211213748644.png][]

### **10、栈+堆+方法区的交互关系** ###

![20200211213855693.png][]

**HotSpot**是使用**指针的方式**来访问对象：  
        Java堆中会存放访问类元数据的地址，reference存储的就直接是对象的地址

三种JVM：

*  Sun公司的HotSpot
 *  BEA公司的JRockit
 *  IBM公司的J9 VM

## 二、堆体系结构概述 ##

--------------------

![20200211211323753.png][]

--------------------

### 1、Heap堆(Java7之前) ###

一个JVM实例只存在一个堆内存，堆内存的大小是可以调节的。类加载器读取了类文件后，需要把类、方法、常变量放到堆内存中，保存所有引用类型的真实信息，以方便执行器执行。  
            **堆内存逻辑上分为三部分：新生+养老+永久**

![20200211214243338.png][]

**新生区**  
    新生区是类的诞生、成长、消亡的区域，一个类在这里产生，应用，最后被垃圾回收器收集，结束生命。新生区又分为两部分： 伊甸区（Eden space）和幸存者区（Survivor pace） ，所有的类都是在伊甸区被new出来的。幸存区有两个： 0区（Survivor 0 space）和1区（Survivor 1 space）。当伊甸园的空间用完时，程序又需要创建对象，JVM的垃圾回收器将对伊甸园区进行垃圾回收(Minor GC)，将伊甸园区中的不再被其他对象所引用的对象进行销毁。然后将伊甸园中的剩余对象移动到幸存 0区。若幸存 0区也满了，再对该区进行垃圾回收，然后移动到 1 区。那如果1 区也满了呢？再移动到养老区。若养老区也满了，那么这个时候将产生MajorGC（FullGC），进行养老区的内存清理。若养老区执行了Full GC之后发现依然无法进行对象的保存，就会产生OOM异常“OutOfMemoryError”。

如果出现java.lang.OutOfMemoryError: Java heap space异常，说明Java虚拟机的堆内存不够。原因有二：  
（1）Java虚拟机的堆内存设置不够，可以通过参数-Xms、-Xmx来调整。

（2）代码中创建了大量大对象，并且长时间不能被垃圾收集器收集（存在被引用）。

![2020021121442260.png][]

![2020021121455531.png][]

![20200211214700415.png][]

**永久区**  
    永久存储区是一个常驻内存区域，用于存放JDK自身所携带的 Class,Interface 的元数据，也就是说它存储的是运行环境必须的类信息，被装载进此区域的数据是不会被垃圾回收器回收掉的，关闭 JVM 才会释放此区域所占用的内存。

如果出现java.lang.OutOfMemoryError: PermGen space，说明是Java虚拟机对永久代Perm内存设置不够。一般出现这种情况，都是程序启动需要加载大量的第三方jar包。例如：在一个Tomcat下部署了太多的应用。或者大量动态反射生成的类不断被加载，最终导致Perm区被占满。

Jdk1.6及之前： 有永久代, 常量池1.6在方法区  
Jdk1.7：       有永久代，但已经逐步“去永久代”，常量池1.7在堆  
Jdk1.8及之后： 无永久代，常量池1.8在元空间

**了解三区结构后方可了解-JVM垃圾收集**

实际而言，方法区（Method Area）和堆一样，是各个线程共享的内存区域，它用于存储虚拟机加载的：类信息+普通常量+静态常量+编译器编译后的代码等等，虽然JVM规范将方法区描述为堆的一个逻辑部分，但它却还有一个别名叫做Non-Heap(非堆)，目的就是要和堆分开。  
      
    对于HotSpot虚拟机，很多开发者习惯将方法区称之为“永久代(Parmanent Gen)” ，但严格本质上说两者不同，或者说使用永久代来实现方法区而已，永久代是方法区(相当于是一个接口interface)的一个实现，jdk1.7的版本中，已经将原本放在永久代的字符串常量池移走。

![20200211214946308.png][]

## 三、堆参数微调优入门 ##

> **JVM**垃圾收集(**Java Garbage Collection** )

这里均以**JDK1.8+HotSpot**为例

### **1、Java 7**  ###

![20200212105143414.png][]

### **2、Java 8**  ###

![20200212105217566.png][]

### **3、堆内存调优简介01** ###

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjQwNTY3MA_size_16_color_FFFFFF_t_70 1][]

### **4、堆内存调优简介02** ###

![2020021210532183.png][]

### **5、堆内存调优简介03**  ###

此图为java7，演示为8

![20200212105619791.png][]

### **6、堆内存调优简介04** ###

![20200212105651272.png][]

--------------------

### GC 内存回收机制 ###

![20200212111439930.png][]

--------------------

## 四、GC垃圾回收 ##

### **1、GC是什么** ###

定义： 分代收集算法

*  次数上频繁收集Young区
 *  次数上较少收集Old区
 *  基本不动Perm区

**GC4大算法**

### **2、GC算法总体概述** ###

![20200212114027564.png][]

JVM在进行GC时，并非每次都对上面三个内存区域一起回收的，大部分时候回收的都是指新生代。

因此GC按照回收的区域又分了两种类型，一种是普通GC（minor GC），一种是全局GC（major GC or Full GC）  
   
**Minor GC和Full GC的区别**

普通GC（minor GC）：只针对新生代区域的GC,指发生在新生代的垃圾收集动作，因为大多数Java对象存活率都不高，所以Minor GC非常频繁，一般回收速度也比较快。

全局GC（major GC or Full GC）：指发生在老年代的垃圾收集动作，出现了Major GC，经常会伴随至少一次的Minor GC（但并不是绝对的）。Major GC的速度一般要比Minor GC慢上10倍以上

### **3 四种算法** ###

3.1 引用计数法

![20200212114223558.png][]

**Code**演示：

package com.atguigu.jvm;
     
    /**@Description:-verbose:gc*/
    public class RefCountGC {
      private byte[] bigSize = new byte[2 * 1024 * 1024];//这个成员属性唯一的作用就是占用一点内存
      Object instance = null;
     
      public static void main(String[] args) {
        RefCountGC objectA = new RefCountGC();
        RefCountGC objectB = new RefCountGC();
        objectA.instance = objectB;
        objectB.instance = objectA;
        objectA = null;
        objectB = null;
     
        System.gc();
      }
    }

3.2 复制算法(Copying)

**（1）定义**：年轻代中使用的是Minor GC，这种GC算法采用的是复制算法(Copying)

**（2）原理**：

![20200212114457505.png][]

Minor GC会把Eden中的所有活的对象都移到Survivor区域中，如果Survivor区中放不下，那么剩下的活的对象就被移到Old  generation中，也即一旦收集后，Eden是就变成空的了。

当对象在 Eden ( 包括一个 Survivor 区域，这里假设是 from 区域 ) 出生后，在经过一次 Minor GC 后，如果对象还存活，并且能够被另外一块 Survivor 区域所容纳( 上面已经假设为 from 区域，这里应为 to 区域，即 to 区域有足够的内存空间来存储 Eden 和 from 区域中存活的对象 )，则使用复制算法将这些仍然还存活的对象复制到另外一块 Survivor 区域 ( 即 to 区域 ) 中，然后清理所使用过的 Eden 以及 Survivor 区域 ( 即 from 区域 )，并且将这些对象的年龄设置为1，以后对象在 Survivor 区每熬过一次 Minor GC，就将对象的年龄 + 1，当对象的年龄达到某个值时 ( 默认是 15 岁，通过-XX:MaxTenuringThreshold 来设定参数)，这些对象就会成为老年代。  
   
\-XX:MaxTenuringThreshold — 设置对象在新生代中存活的次数  
   
 （3）**动态演示：**

在GC开始的时候，对象只会存在于Eden区和名为“From”的Survivor区，Survivor区“To”是空的。紧接着进行GC，Eden区中所有存活的对象都会被复制到“To”，而在“From”区中，仍存活的对象会根据他们的年龄值来决定去向。年龄达到一定值(年龄阈值，可以通过-XX:MaxTenuringThreshold来设置)的对象会被移动到年老代中，没有达到阈值的对象会被复制到“To”区域。经过这次GC后，Eden区和From区已经被清空。这个时候，“From”和“To”会交换他们的角色，也就是新的“To”就是上次GC前的“From”，新的“From”就是上次GC前的“To”。不管怎样，都会保证名为To的Survivor区域是空的。Minor GC会一直重复这样的过程，直到“To”区被填满，“To”区被填满之后，会将所有对象移动到年老代中。

![20200212114824617.png][]

因为Eden区对象一般存活率较低，一般的，使用两块10%的内存作为空闲和活动区间，而另外80%的内存，则是用来给新建对象分配内存的。一旦发生GC，将10%的from活动区间与另外80%中存活的eden对象转移到10%的to空闲区间，接下来，将之前90%的内存全部释放，以此类推。

**（4）动态：**

![20200212154413114.gif][]

劣势：

复制算法它的缺点也是相当明显的。

1.  它浪费了一半的内存，这太要命了。
2.  如果对象的存活率很高，我们可以极端一点，假设是100%存活，那么我们需要将所有对象都复制一遍，并将所有引用地址重置一遍。复制这一工作所花费的时间，在对象存活率达到一定程度时，将会变的不可忽视。 所以从以上描述不难看出，复制算法要想使用，最起码对象的存活率要非常低才行，而且最重要的是，我们必须要克服50%内存的浪费。

3.3 标记清除(Mark-Sweep)

（1）老年代一般是由标记清除或者是标记清除与标记整理的混合实现

（2）原理：

![20200212152545893.png][]

当堆中的有效内存空间（available memory）被耗尽的时候，就会停止整个程序（也被称为stop the world），然后进行两项工作，第一项则是标记，第二项则是清除。

** 标记：**从引用根节点开始标记所有被引用的对象。标记的过程其实就是遍历所有的GC Roots，然后将所有GC Roots可达的对象      标记为存活的对象。  
** 清除：**遍历整个堆，把未标记的对象清除。  
 **缺点**：此算法需要暂停整个应用，会产生内存碎片  
   
用通俗的话解释一下标记/清除算法，就是当程序运行期间，若可以使用的内存被耗尽的时候，GC线程就会被触发并将程序暂停，随后将依旧存活的对象标记一遍，最终再将堆中所有没被标记的对象全部清除掉，接下来便让程序恢复运行。

（3）动态演示

**动图：**

![20200212154339710.gif][]

*  回收时,对需要存活的对象进行标记
 *  回收不是绿色的对象

（4）劣势

1.  首先，它的缺点就是效率比较低（递归与全堆对象遍历），而且在进行GC的时候，需要停止应用程序，这会导致用户体验非常差劲
2.  其次，主要的缺点则是这种方式清理出来的空闲内存是不连续的，这点不难理解，我们的死亡对象都是随即的出现在内存的各个角落的，现在把它们清除之后，内存的布局自然会乱七八糟。而为了应付这一点，JVM就不得不维持一个内存的空闲列表，这又是一种开销。而且在分配数组对象的时候，寻找连续的内存空间会不太好找。

![2020021215390965.png][]

3.4 标记压缩(Mark-Compact)

（1）定义：老年代一般是由标记清除或者是标记清除与标记整理的混合实现

（2）原理：

![20200212154003926.png][]

在整理压缩阶段，不再对标记的对像做回收，而是通过所有存活对像都向一端移动，然后直接清除边界以外的内存。  
可以看到，标记的存活对象将会被整理，按照内存地址依次排列，而未被标记的内存会被清理掉。如此一来，当我们需要给新对象分配内存时，JVM只需要持有一个内存的起始地址即可，这比维护一个空闲列表显然少了许多开销。

标记/整理算法不仅可以弥补标记/清除算法当中，内存区域分散的缺点，也消除了复制算法当中，内存减半的高额代价

（3）劣势

**标记/整理**算法唯一的缺点就是效率也不高，不仅要标记所有存活对象，还要整理所有存活对象的引用地址。从效率上来说，**标记/整理**算法要低于复制算法。

3.5 标记清除压缩(Mark-Sweep-Compact)

![20200212154158154.png][]

**动态演示**

![20200212154303957.gif][]

### **4、总结** ###

**内存效率**：    复制算法 **>** 标记清除算法 **>** 标记整理算法（此处的效率只是简单的对比时间复杂度，实际情况不一定如此）。  
**内存整齐度**：复制算法 **=** 标记整理算法 **>** 标记清除算法。  
**内存利用率**：标记整理算法 **=** 标记清除算法 **>** 复制算法。  
   
可以看出，效率上来说，复制算法是当之无愧的老大，但是却浪费了太多内存，而为了尽量兼顾上面所提到的三个指标，标记/整理算法相对来说更平滑一些，但效率上依然不尽如人意，它比复制算法多了一个标记的阶段，又比标记/清除多了一个整理内存的过程

###     **5、难道就没有一种最优算法吗？ 猜猜看，下面还有** ###

回答：无，没有最好的算法，只有最合适的算法。==========>分代收集算法。  
   
年轻代(**Young Gen**)    
   
年轻代特点是区域相对老年代较小，对像存活率低。  
   
这种情况复制算法的回收整理，速度是最快的。复制算法的效率只和当前存活对像大小有关，因而很适用于年轻代的回收。而复制算法内存利用率不高的问题，通过**hotspot**中的两个**survivor**的设计得到缓解。  
   
老年代(**Tenure Gen**)  
   
老年代的特点是区域较大，对像存活率高。x  
   
这种情况，存在大量存活率高的对像，复制算法明显变得不合适。一般是由标记清除或者是标记清除与标记整理的混合实现。  
   
**Mark**阶段的开销与存活对像的数量成正比，这点上说来，对于老年代，标记清除或者标记整理有一些不符，但可以通过多核/线程利用，对并发、并行的形式提标记效率。  
   
**Sweep**阶段的开销与所管理区域的大小形正相关，但**Sweep**“就地处决”的特点，回收的过程没有对像的移动。使其相对其它有对像移动步骤的回收算法，仍然是效率最好的。但是需要解决内存碎片问题。  
   
**Compact**阶段的开销与存活对像的数据成开比，如上一条所描述，对于大量对像的移动是很大开销的，做为老年代的第一选择并不合适。  
   
基于上面的考虑，老年代一般是由标记清除或者是标记清除与标记整理的混合实现。以**hotspot**中的**CMS**回收器为例，CMS是基于**Mark-Sweep**实现的，对于对像的回收效率很高，而对于碎片问题，**CMS**采用基于**Mark-Compact**算法的**Serial Old**回收器做为补偿措施：当内存回收不佳（碎片导致的**Concurrent Mode Failure**时），将采用**Serial Old**执行**Full GC**以达到对老年代内存的整理。

##     五、面试题 ##

1.   JVM内存模型以及分区，需要详细到每个区放什么
2.  堆里面的分区：Eden，survival from to，老年代，各自的特点。
3.  GC的三种收集方法：标记清除、标记整理、复制算法的原理与特点，分别用在什么地方
4.  Minor GC与Full GC分别在什么时候发生

[https_wushaopei.github.io]: https://wushaopei.github.io/
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjQwNTY3MA_size_16_color_FFFFFF_t_70]: https://img-blog.csdnimg.cn/20200211211224994.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjQwNTY3MA==,size_16,color_FFFFFF,t_70
[20200211211323753.png]: https://img-blog.csdnimg.cn/20200211211323753.png
[20200211211521670.png]: https://img-blog.csdnimg.cn/20200211211521670.png
[20200211211624374.png]: https://img-blog.csdnimg.cn/20200211211624374.png
[20200211213639604.png]: https://img-blog.csdnimg.cn/20200211213639604.png
[20200211213748644.png]: https://img-blog.csdnimg.cn/20200211213748644.png
[20200211213855693.png]: https://img-blog.csdnimg.cn/20200211213855693.png
[20200211214243338.png]: https://img-blog.csdnimg.cn/20200211214243338.png
[2020021121442260.png]: https://img-blog.csdnimg.cn/2020021121442260.png
[2020021121455531.png]: https://img-blog.csdnimg.cn/2020021121455531.png
[20200211214700415.png]: https://img-blog.csdnimg.cn/20200211214700415.png
[20200211214946308.png]: https://img-blog.csdnimg.cn/20200211214946308.png
[20200212105143414.png]: https://img-blog.csdnimg.cn/20200212105143414.png
[20200212105217566.png]: https://img-blog.csdnimg.cn/20200212105217566.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjQwNTY3MA_size_16_color_FFFFFF_t_70 1]: https://img-blog.csdnimg.cn/20200212105246873.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjQwNTY3MA==,size_16,color_FFFFFF,t_70
[2020021210532183.png]: https://img-blog.csdnimg.cn/2020021210532183.png
[20200212105619791.png]: https://img-blog.csdnimg.cn/20200212105619791.png
[20200212105651272.png]: https://img-blog.csdnimg.cn/20200212105651272.png
[20200212111439930.png]: https://img-blog.csdnimg.cn/20200212111439930.png
[20200212114027564.png]: https://img-blog.csdnimg.cn/20200212114027564.png
[20200212114223558.png]: https://img-blog.csdnimg.cn/20200212114223558.png
[20200212114457505.png]: https://img-blog.csdnimg.cn/20200212114457505.png
[20200212114824617.png]: https://img-blog.csdnimg.cn/20200212114824617.png
[20200212154413114.gif]: https://img-blog.csdnimg.cn/20200212154413114.gif
[20200212152545893.png]: https://img-blog.csdnimg.cn/20200212152545893.png
[20200212154339710.gif]: https://img-blog.csdnimg.cn/20200212154339710.gif
[2020021215390965.png]: https://img-blog.csdnimg.cn/2020021215390965.png
[20200212154003926.png]: https://img-blog.csdnimg.cn/20200212154003926.png
[20200212154158154.png]: https://img-blog.csdnimg.cn/20200212154158154.png
[20200212154303957.gif]: https://img-blog.csdnimg.cn/20200212154303957.gif