JVM--垃圾回收

作者: zhemehao819 | 来源:发表于2021-09-23 21:24 被阅读0次

三、垃圾回收

1、如何判断对象可以回收

引用计数法

弊端：循环引用时，两个对象的计数都为1，导致两个对象都无法被释放

可达性分析算法

JVM中的垃圾回收器通过可达性分析来探索所有存活的对象
扫描堆中的对象，看能否沿着GC Root对象为起点的引用链找到该对象，如果找不到，则表示可以回收
可以作为GC Root的对象
-- 虚拟机栈（栈帧中的本地变量表）中引用的对象。　
-- 方法区中类静态属性引用的对象
-- 方法区中常量引用的对象
-- 本地方法栈中JNI（即一般说的Native方法）引用的对象

分析方法：
jps查看进程id
抓取当前堆内存：(b表示二进制文件，live只抓取存活对象并进行一次垃圾回收)
jmap -dump:format=b,live,file=1.bin [进程id]
二进制文件可以用Eclipse Memory Analyer进行分析

五种引用

强引用

只有GC Root都不引用该对象时，才会回收强引用对象
如上图B、C对象都不引用A1对象时，A1对象才会被回收

软引用

当GC Root指向软引用对象时，在内存不足时，会回收软引用所引用的对象
如上图如果B对象不再引用A2对象且内存不足时，软引用所引用的A2对象就会被回收

软引用的使用：

public class Demo1 {
    public static void main(String[] args) {
        final int _4M = 4*1024*1024;
        //使用软引用对象 list和SoftReference是强引用，而SoftReference和byte数组则是软引用
        List<SoftReference<byte[]>> list = new ArrayList<>();
        SoftReference<byte[]> ref= new SoftReference<>(new byte[_4M]);
    }
}

如果在垃圾回收时发现内存不足，在回收软引用所指向的对象时，软引用本身不会被清理
如果想要清理软引用，需要使用引用队列

public class Demo1 {
    public static void main(String[] args) {
        final int _4M = 4*1024*1024;
        List<SoftReference<byte[]>> list = new ArrayList<>();

        //使用引用队列，用于移除引用为空的软引用对象
        ReferenceQueue<byte[]> queue = new ReferenceQueue<>();
        for(int i=0; i<5;i++) {
          //关联了引用队列，当软引用所关联的byte[]被回收时，软引用自己会加入到引用队列中去
          SoftReference<byte[]> ref= new SoftReference<>(new byte[_4M], queue);
          list.add(ref);
        }
        
        //遍历引用队列，如果有元素（说明软引用对象已回收），则移除
        Reference<? extends byte[]> poll = queue.poll();
        while(poll != null) {
            //引用队列不为空，则从集合中移除该元素
            list.remove(poll);
            //移动到引用队列中的下一个元素
            poll = queue.poll();
        }
    }
}

大概思路为：查看引用队列中有无软引用，如果有，则将该软引用从存放它的集合中移除（这里为一个list集合）

弱引用

只有弱引用引用该对象时，在垃圾回收时，无论内存是否充足，都会回收弱引用所引用的对象
如上图如果B对象不再引用A3对象，则A3对象会被回收
弱引用的使用和软引用类似，只是将 SoftReference 换为了 WeakReference

虚引用

当虚引用对象所引用的对象被回收以后，虚引用对象就会被放入引用队列中，调用虚引用的方法

虚引用的一个体现是释放直接内存所分配的内存，当引用的对象ByteBuffer被垃圾回收以后，虚引用对象Cleaner就会被放入引用队列中，然后调用Cleaner的clean方法来释放直接内存
如上图，B对象不再引用ByteBuffer对象，ByteBuffer就会被回收。但是直接内存中的内存还未被回收。这时需要将虚引用对象Cleaner放入引用队列中，然后调用它的clean方法来释放直接内存

终结器引用

所有的类都继承自Object类，Object类有一个finalize方法。当某个对象不再被其他的对象所引用时，会先将终结器引用对象放入引用队列中，然后根据终结器引用对象找到它所引用的对象，然后调用该对象的finalize方法。调用以后，该对象就可以被垃圾回收了

如上图，B对象不再引用A4对象。这是终结器对象就会被放入引用队列中，引用队列会根据它，找到它所引用的对象。然后调用被引用对象的finalize方法。调用以后，该对象就可以被垃圾回收了

引用队列

软引用和弱引用可以配合引用队列
-- 在弱引用和虚引用所引用的对象被回收以后，会将这些引用放入引用队列中，方便一起回收这些软/弱引用对象
虚引用和终结器引用必须配合引用队列
-- 虚引用和终结器引用在使用时会关联一个引用队列

2、垃圾回收算法

标记-清除

定义：

标记清除算法顾名思义，是指在虚拟机执行垃圾回收的过程中，先采用标记算法确定可回收对象，然后垃圾收集器根据标识清除相应的内容，给堆内存腾出相应的空间

这里的腾出内存空间并不是将内存空间的字节清0，而是记录下这段内存的起始结束地址，下次分配内存的时候，会直接覆盖这段内存
缺点：容易产生大量的内存碎片，可能无法满足大对象的内存分配。
优点：这种算法速度快。

标记-整理

标记-整理会将不被GC Root引用的对象回收，清楚其占用的内存空间。然后整理剩余的对象，可以有效避免因内存碎片而导致的问题，但是因为整理需要消耗一定的时间，所以缺点是效率较低，优点是没有内存碎片。

复制

将内存分为相等大小的两个区域，FROM和TO（TO中为空）。先将被GC Root引用的对象从FROM放入TO中，再回收不被GC Root引用的对象。然后交换FROM和TO。这样也可以避免内存碎片的问题，但是会占用双倍的内存空间。

3、分代回收

回收流程

新创建的对象首先分配在新生代的伊甸园区

当伊甸园中的内存不足时，就会进行一次垃圾回收（Minor GC）
Minor GC 会将伊甸园和幸存区FROM存活的对象先复制到幸存区TO中，并让其寿命加1，再交换两个幸存区；

再次创建对象，若新生代的伊甸园又满了，则会再次触发 Minor GC，这时不仅会回收伊甸园中的垃圾，还会回收幸存区中的垃圾，再将活跃对象复制到幸存区TO中。回收以后会交换两个幸存区，并让幸存区中的对象寿命加1

如果幸存区中的对象的寿命超过某个阈值（最大为15，4bit），就会晋升到老年代中

如果新生代和老年代中的内存都满了，就会先触发Minor GC，此时如果老年代也满了就会再触发Full GC。

注：
1.新生代的垃圾回收称为Minor GC；
2.老年代的垃圾回收称为Full GC；
3.Minor GC：会触发 stop the world，暂停其他用户线程，等垃圾回收结束后用户线程才恢复运行，时间较短；
4.Full GC：也会STW，但时间较长。

GC 分析

大对象处理策略

当遇到一个较大的对象时，就算新生代的伊甸园为空，也无法容纳该对象时，会将该对象直接晋升为老年代

线程内存溢出

某个线程的内存溢出了而抛异常（out of memory），不会让其他的线程结束运行。
这是因为当一个线程抛出OOM异常后，它所占据的内存资源会全部被释放掉，从而不会影响其他线程的运行，进程依然正常

4、垃圾回收器

4.1 串行

单线程
堆内存较小，适合个人电脑（CPU核数较少）

安全点：让其他线程都在这个点停下来，以免垃圾回收时移动对象地址，使得其他线程找不到被移动的对象。
因为是串行的，所以只有一个垃圾回收线程。且在该线程执行回收工作时，其他线程进入阻塞状态。

4.2 吞吐量优先

多线程
堆内存较大，多核CPU
让单位时间内，STW时间最短
JDK1.8默认使用的垃圾回收器

4.3 响应时间优先

多线程
堆内存较大，多核CPU
尽可能让单次STW时间短（尽量不影响其他线程运行）

4.4 G1

定义：Garbage First

JDK 9以后默认使用，而且替代了CMS 收集器

适用场景

同时注重吞吐量和低延迟，默认暂停目标是200ms
超大堆内存，会将堆内存划分为多个大小相等的区域
整体上是标记-整理算法，两个区域之间是复制算法

相关参数：JDK8 并不是默认开启的，所需要参数开启

G1垃圾回收阶段

新生代伊甸园垃圾回收—–>内存不足，新生代回收+并发标记—–>回收新生代伊甸园、幸存区、老年代内存——>新生代伊甸园垃圾回收(重新开始)

Young Collection

分代是按对象的生命周期划分，分区则是将堆空间划分连续几个不同小区间，每一个小区间独立回收，可以控制一次回收多少个小区间，方便控制 GC 产生的停顿时间

E：伊甸园 S：幸存区 O：老年代

会STW

Young Collection + CM

CM：并发标记

在 Young GC 时会对 GC Root 进行初始标记
在老年代占用堆内存的比例达到阈值时，对进行并发标记（不会STW），阈值可以根据jvm参数进行设定（默认45%）

Mixed Collection

会对E、S、O 进行全面的回收

最终标记，会STW
拷贝存活E，会STW

-XX:MaxGCPauseMills:xxx 用于指定最长的停顿时间

问：为什么有的老年代被拷贝了，有的没拷贝？
因为指定了最大停顿时间，如果对所有老年代都进行回收，耗时可能过高。为了保证时间不超过设定的停顿时间，会回收最有价值的老年代（回收后，能够得到更多内存）--回收垃圾最多的老年代区。

Full GC

G1在老年代内存不足时

如果垃圾产生速度慢于垃圾回收速度，不会触发Full GC，还是并发地进行清理
如果垃圾产生速度快于垃圾回收速度，便会触发Full GC

跨代引用

新生代回收的跨代引用（老年代引用新生代）问题

卡表与Remembered Set

回收新生代时，会找新生代对象gc root对象，但有一部分gc root对象来自于老年代，老年代的对象比较多，这时候利用卡表技术的脏卡标记。

Remembered Set 存在于E中，用于保存新生代对象对应的脏卡，之后就会到这些脏卡处遍历gc root，减少遍历时间。

脏卡：O被划分为多个区域（一个区域512K），如果该区域引用了新生代对象，则该区域被称为脏卡

在引用变更时通过post-write barried + dirty card queue
concurrent refinement threads 更新 Remembered Set

Remark

重新标记阶段
在垃圾回收时，收集器处理对象的过程中
黑色：已被处理，需要保留的灰色：正在处理中的白色：还未处理的

但是在并发标记过程中，有可能A被处理了以后未引用C，但该处理过程还未结束，在处理过程结束之前A引用了C，这时就会用到remark

过程如下：

之前C未被引用，这时A引用了C，就会给C加一个写屏障，写屏障的指令会被执行，将C放入一个队列当中，并将C变为处理中状态
在并发标记阶段结束以后，重新标记阶段会STW，然后将放在该队列中的对象重新处理，发现有强引用引用它，就会处理它

JDK 8u20 字符串去重

过程：

将所有新分配的字符串（底层是char[]）放入一个队列
当新生代回收时，G1并发检查是否有重复的字符串
如果字符串的值一样，就让他们引用同一个字符串对象
注意，其与String.intern的区别
-intern关注的是字符串对象
-字符串去重关注的是char[]
-在JVM内部，使用了不同的字符串标

优点与缺点

节省了大量内存
新生代回收时间略微增加，导致略微多占用CPU

-XX:+UseStringDeduplication

JDK 8u40 并发标记类卸载

在并发标记阶段结束以后，就能知道哪些类不再被使用。如果一个类加载器的所有类都不在使用，则卸载它所加载的所有类

JDK 8u60 回收巨型对象

一个对象大于region的一半时，就称为巨型对象
G1不会对巨型对象进行拷贝
回收时被优先考虑
G1会跟踪老年代所有incoming引用，如果老年代incoming引用为0的巨型对象就可以在新生代垃圾回收时处理掉

JDK 9 并发标记起始时间的调整

并发标记必须在堆空间占满前完成，否则退化为 FulGC
JDK 9 之前需要使用 -XX:InitiatingHeapOccupancyPercent
JDK 9 可以动态调整
--XX:InitiatingHeapOccupancyPercent 用来设置初始值
-进行数据采样并动态调整
-总会添加一个安全的空挡空间

GC 调优

查看虚拟机参数命令

"F:\JAVA\JDK8.0\bin\java" -XX:+PrintFlagsFinal -version | findstr "GC"

可以根据参数去查询具体的信息

调优领域

内存
锁竞争
CPU占用
IO

确定目标

低延迟/高吞吐量？选择合适的GC

CMS G1 ZGC
ParallelGC
Zing

最快的GC是不发生GC

首先排除减少因为自身编写的代码而引发的内存问题

查看Full GC前后的内存占用，考虑以下几个问题
- 数据是不是太多？
- 数据表示是否太臃肿
  - 对象图
  - 对象大小
- 是否存在内存泄漏

新生代调优

新生代的特点
- 所有的new操作分配内存都是非常廉价的
  - TLAB
- 死亡对象回收零代价
- 大部分对象用过即死（朝生夕死）
- MInor GC 所用时间远小于Full GC
新生代内存越大越好么？
- 不是
  - 新生代内存太小：频繁触发Minor GC，会STW，会使得吞吐量下降
  - 新生代内存太大：老年代内存占比有所降低，会更频繁地触发Full GC。而且触发Minor GC时，清理新生代所花费的时间会更长
- 新生代内存设置为内容纳[并发量*(请求-响应)]的数据为宜

幸存区调优

幸存区需要能够保存 当前活跃对象+需要晋升的对象
晋升阈值配置得当，让长时间存活的对象尽快晋升
短时间的对象要尽快回收，不要晋升到老年代，导致只有full gc才能回收这个对象

老年代调优

以CMS 为例

CMS 的老年代内存越大越好
先尝试不做调优，如果没有 Full GC 那么已经…，否则先尝试调优新生代
观察发生 Full GC 时老年代内存占用，将老年代内存预设调大 1/4~ 1/3

-XX:CMSInitiatingOccupancyFraction=percent