JVM之垃圾收集

Bertha 。 2022-12-04 07:37 17阅读 0赞

### 文章目录 ###

*  垃圾收集
 *   *  OutOfMemoryError异常
     *   *  内存溢出&内存泄漏
         *  示例
     *  垃圾收集
     *   *  引用计数算法
         *  可达性分析算法
         *   *  什么是GC Roots？
         *  引用
         *  垃圾收集算法
         *   *  分代收集理论
             *  标记-清除算法
             *  标记-复制算法
             *   *  分配担保机制
                 *  大对象直接进入老年代
                 *  长期存活的对象进入老年代
             *  标记-整理算法

# 垃圾收集 #

## OutOfMemoryError异常 ##

在JVM虚拟机内存模型中有一些内存空间会出现OutOfMemoryError异常(简称OOM)，这些内存空间分别为**堆、方法区、虚拟机栈、本地方法栈以及本地内存**。

### 内存溢出&内存泄漏 ###

首先需要区分两个概念：内存溢出和内存泄漏

**概念**

内存溢出：程序申请内存是没有足够内存供申请者使用  
内存泄漏：程序申请内存后无法释放已申请的内存空间，可能会造成内存泄漏

**原因**

内存溢出

*  内存中存储的数据量过大，超出内存最大限制
 *  代码存在死循环或者产生大量数据存储到内存中（一般不会出现，在开发过程中或者测试阶段就会暴露）
 *  启动参数设置内存太小

内存泄漏

*  大量对象被引用无法回收

**解决方式**

*  修改启动参数，调整内存大小参数
 *  通过分析工具分析内存日志，查询异常出现的位置
 *  检查代码是否有死循环
 *  重启服务（应急方案，没有根本解决问题，需要分析dump文件）

### 示例 ###

通过一个demo模拟一个内存溢出的现象，创建OomDemo类，在主方法中创建一个集合，通过死循环不断添加随机数到集合中，设置启动参数-Xms2m -Xmx2m -XX:+HeapDumpOnOutOfMemoryError

/**
    *启动参数：-Xms2m -Xmx2m -XX:+HeapDumpOnOutOfMemoryError
    */
    public class OomDemo {
    
        public static void main(String[] args) {
            List<String> list = new ArrayList();
            while (true){
                String replace = UUID.randomUUID().toString().replace("-", "");
                System.out.println(replace);
                list.add(replace);
            }
        }
    }
    
    运行后控制台就会抛出异常：
    ......
    2b38fc0b90bb46769e4b103e5bb4666d
    ec37f5deaeb64e8e8f1ac09db8391320
    java.lang.OutOfMemoryError: GC overhead limit exceeded
    Dumping heap to java_pid20860.hprof ...
    Exception in thread "main" Heap dump file created [2055145 bytes in 0.013 secs]
    java.lang.OutOfMemoryError: GC overhead limit exceeded
    	at java.lang.AbstractStringBuilder.<init>(AbstractStringBuilder.java:68)
    	at java.lang.StringBuffer.<init>(StringBuffer.java:116)
    	at java.util.regex.Matcher.replaceAll(Matcher.java:953)
    	at java.lang.String.replace(String.java:2240)
    	at com.cxd.demo.jvm.demo.OOMDemo.main(OOMDemo.java:20)

通过控制台异常能看到具体哪块代码有问题，或者通过分析工具分析dump文件，此文件在项目根目录，如下图  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkxNTgwOA_size_16_color_FFFFFF_t_70_pic_center]

通过jvisualvm分析查看如下  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkxNTgwOA_size_16_color_FFFFFF_t_70_pic_center 1]  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkxNTgwOA_size_16_color_FFFFFF_t_70_pic_center 2]  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkxNTgwOA_size_16_color_FFFFFF_t_70_pic_center 3]

## 垃圾收集 ##

程序在运行过程会产生各种对象，而程序所使用的内存空间大小有限制的，如上面提到了超出了限制就会抛出异常，那么为什么一个优秀的程序运行特别长的时间仍然可以正常运行，内存不会超出限制呢？

原因就是因为JVM中有垃圾回收器对垃圾进行收集（Garbage Collection，简称GC），这就好比我们生活中会产生大量的垃圾，如果不及时处理那么就会超出垃圾桶的限制溢出来，因此需要清洁工处理垃圾，才能保证生活环境不被垃圾围堵。

### 引用计数算法 ###

在对象中添加一个引用计数器，每当一个地方引用它时，计数器值就加一；当引用失效时，计数器值就减一；任何时刻计数器为零的对象就是不可能再被使用的。

优点：原理简单，判定效率高

缺点：占用一些内存，有很多例外情况，需要配合额外处理才能正确工作，比如单纯的引用计数算法无法解决互相循环引用的问题。

### 可达性分析算法 ###

这个算法的基本思路就是通过一系列称为“GC Roots”的根对象作为起始节点集，从这些节点开始，根据引用关系向下搜索，搜索过程所走过的路径称为“引用链”，如果某个独享到GC Roots间没有任何引用链相连，或者用图论的话来说就是从GC Roots到这个对象不可达时，则证明此对象是不可能再被使用的。

示例  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkxNTgwOA_size_16_color_FFFFFF_t_70_pic_center 4]

#### 什么是GC Roots？ ####

*  在虚拟机栈(栈帧中的本地变量表)中引用的对象，譬如各个线程被调用的方法堆栈中使用到的参数、局部变量、临时变量等
 *  在方法区中类静态属性引用的对象，譬如java类的引用类型静态变量
 *  在方法区中常量引用的对象，譬如字符串常量池里的引用
 *  在本地方法栈中引用的对象
 *  java虚拟机内部引用，如基本数据类型对应的Class对象，一些常驻的异常对象等，还有系统类加载器
 *  所有被同步锁(synchronized关键字)持有的对象
 *  反应java虚拟机内部情况的JMXBean、JVMTI中注册的回调、本地代码缓存

### 引用 ###

不论是引用计算法还是可达性分析算法都与引用有关。引用分为：**强引用、软引用、弱引用、虚引用**。

**强引用**：程序中普遍存在的引用赋值，类似“Object obj = new Object()”，无论在什么情况下，垃圾回收器都不会回收被引用的对象，如果强引用对象达到内存上限就会出现OOM异常。

**软引用**：用来描述一些还有用，但非必须的对象，只被软引用关联着的对象，在系统将要发生内存溢出异常前，会把这些对象列进回收范围之中进行第二次回收，如果这次回收还没有足够的内存，才会抛出内存溢出异常。在JDK1.2后提供了SoftReference类来实现软引用，比如缓存中的数据，一般缓存是为了提高性能，获取数据先从缓存中获取，如果缓存中没有才会查询数据库，所以当即将发生OOM异常前，通过回收缓存中的数据未尝不是一个办法。

**弱引用**：用来秒速那些非必要对象，但是它的强度比软引用还要弱一些，被弱引用的对象只能生存到下一次垃圾回收发生为止。当垃圾回收器开始工作，无论当前内存是否足够，都会回收掉只被弱引用关联的对象，在JDK1.2后提供了WeakReference类来实现弱引用；

**虚引用**：也叫幻影引用，它是最弱的一种引用关系。一个对象是否有虚引用的存在，完全不会对其生产时间构成影响，也无法通过虚引用来取得一个对象实例。为一个对象设置虚引用关联的唯一目的只是为了能在对象被收集器回收时收到一个系统通知。在JDK1.2之后提供了PhantomReference类实现虚引用。

### 垃圾收集算法 ###

垃圾收集算法分为：引用计数式垃圾收集、追踪式垃圾收集

#### 分代收集理论 ####

当前商业虚拟机的垃圾收集器，大多数都遵循“分代收集”的理论进行设计，分代收集名为理论，实则是一套符合大多数程序运行实际情况的经验法则，它建立在分代假说之上：

1）弱分代假说：绝大多数对象都是朝生夕灭的

2）强分代假说：熬过越多次垃圾收集过程的对象就越难以消灭

3）跨代引用假说：跨代引用相对于同代引用来说仅占极少数

垃圾收集最频繁的内存区域就是堆，在虚拟机中会通过划分区域进行垃圾收集，那么将堆划分为**新生代，年老代**，我们常说的还有一个**永久代**，其实永久代并非在堆中，因为方法区是基于永久代实现的，所以永久代其实在方法区中。

根据不同区域的回收因而有了**Minor GC、Major GC、Full GC**也就是新生代垃圾收集、年老代垃圾收集、整堆收集，一下是具体的定义：

部分收集(Partial GC)：指目标不是完整收集整个Java堆的垃圾收集

*  新生代收集(Minor GC/Young GC)：指目标只是新生代的垃圾收集
 *  年老代收集(Major GC/Old GC)：指目标只是老年代的垃圾收集
 *  混合收集(Mixed GC)：指目标是整个新生代以及部分年老代的垃圾收集。目前只有G1收集器会有这种行为。

整堆收集(Full GC)：收集整个Java堆和方法区的垃圾收集

#### 标记-清除算法 ####

标记-清除算法是最早也是最基础的垃圾收集算法，分为“标记”和“清除”两个阶段

标记：标记所有需要回收的对象，或者表示存活的对象

清除：根据标记的对象清除回收对象

示例如下：  
![在这里插入图片描述][20200906115636983.png_pic_center]![在这里插入图片描述][20200906115655784.png_pic_center]  
缺点

1.  通过图示会发现清除以后留下的内存空间碎片太多，整体剩余空间有一半以上，但是如果存储一个稍微大点的对象，可能会存储不下，因为没有连续的足够的内存空间；
2.  如果可以回收的对象很多，那么就需要大量标记和清除影响效率

#### 标记-复制算法 ####

标记-复制算法可以解决标记-清除算法效率低的问题，首先将内存空间进行1:1分隔，只使用一半内存空间，另一半空闲，在使用的那一半空间中，标记可回收对象，存活对象，当内存用完以后将存活的对象复制到未使用的内存空间中，使用的空间清空。*（此时的内存空间针对的是新生代内存空间）*

示例如下：  
![在这里插入图片描述][20200906115735728.png_pic_center]![在这里插入图片描述][20200906115752918.png_pic_center]  
以上标记复制算法虽然解决了标记-清除算法的碎片化问题，但是显而易见，标记-复制算法将内存一分为二，减小了可用内存大小，而且如果存活对象多的话，复制也有开销。

后来Andrew Appel针对朝生夕灭特点的对象，提出了一种更优化的半区复制策略，即“Appel 回收”。将新生代内存空间按照8:1:1分成一块Eden区、两块Survivor区()。（内存空间分配比例可以通过参数-XX:SurvivorRatio设置，默认-XX:SurvivorRatio=8）

分代示例如下：  
![在这里插入图片描述][20200906115842658.png_pic_center]  
垃圾收集示例如下：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkxNTgwOA_size_16_color_FFFFFF_t_70_pic_center 5]  
对象优先被分配到了Eden区，Eden区会将一些对象存储到From Survivor区，当Eden和From Survivor区空间满了以后会发生Minor GC，将存活对象都复制到To Survivor区，并清空Eden区和From Survivor区，此时原来的From Survivor和To Survivor就会调换功能，也就是空闲的Survivor就是To Survivor。

当To Survivor区空间无法满足Eden区和From Survivor区存活的对象时那么就会通过分配担保机制将对象提前转移到年老代。

##### 分配担保机制 #####

在发生Minor GC之前，虚拟机必须先检查年老代最大可用的连续空间是否大于新生代所有对象空间，如果这个条件成立，那么这次Minor GC可以确保安全；如果不成立，则虚拟机会查看参数-XX:HandlePromotionFailure参数的设置值是否允许担保失败；如果允许，那么会继续检查年老代最大可用的连续空间是否大于历次晋升到年老代对象的平均大小，如果大于，将尝试进行Minor GC，尽管这次Minor GC是由风险的；如果小于，或者-XX:HandlePromotionFailure设置不允许冒险，那么这时就要改为Full GC。

一般情况下-XX:HandlePromotionFailure都会开启，防治频繁Full GC，但是到了JDK 6Update 24之后，-XX:HandlePromotionFailure参数不在影响担保策略，只要年老代的连续空间大于新生代对象总大小或者历次晋升的平均大小，就会进行Minor GC，否则进行Full GC。

##### 大对象直接进入老年代 #####

大对象就是指需要大量连续内存空间的java对象，最典型的大对象便是那种很长的字符串，或者元素数量很庞大的数组。

HotSpot虚拟机-XX:PretenureSizeThreshold参数，指定大于该设置的对象直接在老年代分配，这样做的目的就是避免在Eden区以及两个Survivor区之间来回复制，产生大量内存复制操作。

##### 长期存活的对象进入老年代 #####

以上说到大对象可以直接进入老年代，或者通过担保机制将存活对象转移到年老代，还有一种情况就是经过多次Minor GC都存活的对象也会转移到老年代，那么要**经过多少次才会进入到老年代呢？**

对象在Survivor区中经过一次Minor GC，年龄就会增加1，默认达到15岁就会进入老年代，当然也可以通过参数-XX:MaxTenuringThreshold设置

**存活的对象必须达到参数-XX:MaxTenuringThreshold设置的年龄才会进入老年代吗?**

HotSpot虚拟机并不是必须要求对象的年龄达到-XX:MaxTenuringThreshold才能晋升到老年代，如果在Survivor空间中相同年龄所有对象的总和大于Survivor空间的一半，年龄大于或者等于该年龄的对象就可以直接进入老年代，无须等待达到-XX:MaxTenuringThreshold。

#### 标记-整理算法 ####

标记-复制算法如果对象存活率比较高的情况下，进行多次复制操作会降低效率。可以通过标记-整理算法，其实与上面的算法类似，标记回收对象和存活对象，将可回收对象清除以后，再将存活对象整理，就会避免空间碎片化。

示例如下：  
![在这里插入图片描述][20200906115954970.png_pic_center]  
![在这里插入图片描述][20200906120007494.png_pic_center]

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkxNTgwOA_size_16_color_FFFFFF_t_70_pic_center]: /images/20221123/147fc31058af423680c6ea042d61e7d7.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkxNTgwOA_size_16_color_FFFFFF_t_70_pic_center 1]: /images/20221123/9c8439fefaa74f43a2c9788312173fc8.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkxNTgwOA_size_16_color_FFFFFF_t_70_pic_center 2]: /images/20221123/1258a62fa6b1429dbe8c7bfad371b502.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkxNTgwOA_size_16_color_FFFFFF_t_70_pic_center 3]: /images/20221123/984716a9d83d4bb6b90dcc10214458e3.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkxNTgwOA_size_16_color_FFFFFF_t_70_pic_center 4]: /images/20221123/5555026ccb6f45bca22c93d2955d1f22.png
[20200906115636983.png_pic_center]: https://img-blog.csdnimg.cn/20200906115636983.png#pic_center
[20200906115655784.png_pic_center]: /images/20221123/5bca442eb3cb4bd48b459278575c98e5.png
[20200906115735728.png_pic_center]: https://img-blog.csdnimg.cn/20200906115735728.png#pic_center
[20200906115752918.png_pic_center]: /images/20221123/663a24f13b9c4c3c941099ed83c4490e.png
[20200906115842658.png_pic_center]: /images/20221123/5b1fdcbfedd347ffb4b057683fdbc8ae.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkxNTgwOA_size_16_color_FFFFFF_t_70_pic_center 5]: /images/20221123/322b762eae524601a2f475becf03d074.png
[20200906115954970.png_pic_center]: /images/20221123/37e5cc993d6d46858d9fcb54ae23b0b1.png
[20200906120007494.png_pic_center]: /images/20221123/3016bbdb8d364dea9e8192ea64807199.png