JVM基础之垃圾回收

垃圾回收

1. Base

内存泄漏：不再使用的对象在系统中未被回收

内存溢出：内存泄漏的积累

手动触发垃圾回收：System.gc(),该方法不一定会立即回收垃圾，仅仅是向JVM发送一个垃圾回收请求，具体是否需要垃圾回收由JVM自行判断

哪些需要进行垃圾回收？哪些不需要进行垃圾回收？

线程不共享的地方，都是伴随着线程的创建而创建，线程的销毁而销毁，而方法的栈帧在执行完方法后就会自动弹出栈并释放掉内存，所以该区域不需要进行垃圾回收。

线程共享的地方，需要进行垃圾回收。

2. 方法区的回收

由于方法区中保存的均是与Class相关的内容，即InstanceKlass内容，该区域能回收的内容主要就是不再使用的类，需要满足以下条件：

此类所有实例对象都已经被回收，在堆中不存在任何该类的实例对象以及子类对象。
加载该类的类加载器已经被回收。
该类对应的 java.lang.Class 对象没有在任何地方被引用。

开发场景使用较少，更多使用是在热部署等应用场景，每个jsp文件对应一个唯一的类加载器，当一个jsp文件修改了，就直接卸载这个jsp类加载器。重新创建类加载器，重新加载jsp文件。所以此处不再赘述。

3. 堆回收

3.1 引用计数法和可达性计数法

3.1.1 引用计数法

引用计数法会为每个对象维护一个引用计数器，当对象被引用时加1，取消引用时减1。

优点

实现简单

缺点

每次引用和取消引用都需要维护引用计数器，有性能影响
无法解决循环引用问题

3.1.2 可达性计数法

该分析法会将对象分为两类：GC Roots对象和普通对象

如果一个对象至GC Roots是可达的，那么该对象就不能被回收。

可达性分析算法

哪些可以为GC Roots对象？

虚拟机中引用的对象（各个线程使用到的参数、局部变量等）
本地方法栈内JNI（常说的本地方法）引用的对象
方法区中静态属性引用的对象（public static User user = new User()）
方法区中常量引用的对象（主要是指String Table，public static final String s = "str"）
所有被同步锁synchronized持有的对象
虚拟机内部的引用

3.2 五种对象引用

3.2.1 强引用

即是GCRoot对象对普通对象有引用关系，只要这层关系存在，普通对象就不会被回收。即可达性分析算法中的引用

3.2.2 软引用

软引用相对于强引用是一种比较弱的引用关系，如果一个对象只有软引用关联到它，当程序内存不足时，就会将软引用中的数据进行回收。在JDK 1.2版之后提供了SoftReference类来实现软引用，软引用常用于缓存中。

执行过程

将对象使用软引用包装起来，new SoftReference<对象类型>(对象)。
内存不足时，虚拟机尝试进行垃圾回收。
如果垃圾回收仍不能解决内存不足的问题，回收软引用中的对象。
如果依然内存不足，抛出OutOfMemory异常。

// -Xms200M -Xmx200M    
public static void main(String[] args) {Byte[] bytes = new Byte[1024 * 1024 * 100];SoftReference<Byte[]> softReference = new SoftReference<>(bytes);// 将软引用包裹的对象置空, 这样原始数据就没有强引用指向bytes。bytes = null;System.out.println(softReference.get()); //输出 [Ljava.lang.Byte;@707f7052Byte[] bytes2 = new Byte[1024 * 1024 * 100];System.out.println(softReference.get()); // 输出 null}

怎么回收SoftReference对象本身？

内存不足的情况下，也需要回收SoftReference对象本身，这个时候就可以使用SoftReference的另外一个构造器，创建时将队列同步传入。流程如下：

软引用创建时，通过构造器传入引用队列
在软引用中包含的对象被回收时，该软引用对象会被放入引用队列
通过代码遍历引用队列，将SoftReference的强引用删除

3.2.3 弱引用

弱引用的整体机制和软引用基本一致，区别在于弱引用包含的对象在垃圾回收时，不管内存够不够都会直接被回收。在JDK 1.2版之后提供了WeakReference类来实现弱引用，弱引用主要在ThreadLocal中使用。弱引用对象本身也可以使用引用队列进行回收。

3.2.4 虚引用

虚引用也叫幽灵引用/幻影引用，不能通过虚引用对象获取到包含的对象。虚引用唯一的用途是当对象被垃圾回收器回收时可以接收到对应的通知。Java中使用PhantomReference实现了虚引用，直接内存中为了及时知道直接内存对象不再使用，从而回收内存，使用了虚引用来实现。

3.2.5 终结器引用

终结器引用指的是在对象需要被回收时，终结器引用会关联对象并放置在Finalizer类中的引用队列中，在稍后由一条由FinalizerThread线程从队列中获取对象，然后执行对象的finalize方法，在对象第二次被回收时，该对象才真正的被回收。在这个过程中可以在finalize方法中再将自身对象使用强引用关联上，但是不建议这样做。

3.3 垃圾回收算法

3.3.1 垃圾回收算法的评价标准

Java垃圾回收过程会通过单独的GC线程来完成，但是不管使用哪一种GC算法，都会有部分阶段需要停止所有的用户线程。这个过程被称之为Stop The World简称STW，如果STW时间过长则会影响用户的使用。

吞吐量

吞吐量指的是 CPU 用于执行用户代码的时间与 CPU 总执行时间的比值，即吞吐量 = 执行用户代码时间 / （执行用户代码时间 + GC时间）。吞吐量数值越高，垃圾回收的效率就越高。

最大暂停时间

最大暂停时间指的是所有在垃圾回收过程中的STW[Stop The World]时间最大值。

堆使用效率

堆空间的使用

3.3.2 标记清除算法

1.标记阶段：根据可达性分析算法，从GC Roots开始通过引用链遍历出所有的存活对象。

2.清除阶段：从内存中删除没有被标记的对象。

标记清除算法

优点

操作比较简单

缺点

碎片化问题：由于内存是连续的，所以在对象被删除之后，内存中会出现很多细小的可用内存单元。如果我们需要的是一个比较大的空间，很有可能这些内存单元的大小过小无法进行分配。
分配速度慢：由于内存碎片的存在，需要维护一个空闲链表，极有可能发生每次需要遍历到链表的最后才能获得合适的内存空间。

3.3.3 复制算法

1.将对空间分为两个区间，分别为From和To区，创建对象并将对象放入From区。

2.GC阶段开始，将GC Roots对象移至To区，并且将与GC Root关联的对象移至To区。

3.清空From区，并且两个区间名称进行互换。

复制算法

优点

吞吐量高：复制算法只需要遍历一次存活对象复制到To空间即可，比标记-整理算法少了一次遍历的过程，因而性能较好，但是不如标记-清除算法，因为标记清除算法不需要进行对象的移动
不会存在碎片化：复制算法在复制之后就会将对象按顺序放入To空间中，所以对象以外的区域都是可用空间，不存在碎片化内存空间。

缺点

每次只能让一半的内存空间来为创建对象使用

3.3.4 标记整理(压缩)算法

1.标记阶段：将所有存活的对象进行标记。Java中使用可达性分析算法，从GC Root开始通过引用链遍历出所有存活对象。

2.整理阶段：将存活对象移动到堆的一段，清理掉其他空间。

在这里插入图片描述

优点

内存使用效率高：整个堆内存都可以使用，不会像复制算法只能使用半个堆内存

不会发生碎片化：在整理阶段可以将对象往内存的一侧进行移动，剩下的空间都是可以分配对象的有效空间

缺点

整理阶段效率不高

3.3.5 分代垃圾回收算法

分代垃圾回收算法会将区域分为：年轻代和老年代，其中年轻代又分为：Eden区（伊甸园区），幸存区（有2块）

默认情况下，伊甸园区：幸存区(1块) = 8：1

1.新创建的对象首先放入Eden区。

2.随着Eden区的对象越来越多，直至新来的对象在Eden区放不下，就会触发Young GC，此时根据可达性分析算法将Eden区和S0区(From区)将于Gc Root有关联的对象放入S1区(To区)。同时S1区变更为From区，S0区变更为To区。（每次Young GC会记录对象的年龄 +1，初始值为0）

3.当Eden区的对象再次满的时候，会将Eden区与S1区的对象进行回收，重复2过程。

4.当新生代中的对象年龄达到阈值(默认为15，默认值与垃圾回收器有关)，对象就会晋升为老年代。

5.当再次进来一个新的对象时，此时Young和Old区域都已经满了的时候，会优先先进行一次Young GC，如果Young GC之后空间还是不足的话，就会进行Full GC，Full GC会对整个堆空间进行回收。如果Full GC不能回收掉老年代的对象，此时就会抛出OOM

分代GC算法

3.4 垃圾回收器

垃圾回收器是垃圾回收算法的具体实现。关系图如下：
垃圾回收器调用关系

3.4.1 新生代垃圾回收器

Serial

Serial是是一种单线程串行回收年轻代的垃圾回收器。开启：-XX:+UseSerialGC

算法	优点	缺点	使用场景
复制算法	单CPU处理器下吞吐量非常出色	多CPU下吞吐量不如其他垃圾回收器，堆如果偏大会让用户线程处于长时间的等待	Java编写的客户端程序或者硬件配置有限的场景

Serial垃圾执行流程

ParNew

ParNew垃圾回收器本质上是对Serial在多 CPU下的优化，使用多线程进行垃圾回收 -XX:+UseParNewGC

算法	优点	缺点	使用场景
复制算法	多CPU处理器下停顿时间较短	吞吐量和停顿时间不如G1，所以在JDK9之后不建议使用	JDK8及之前的版本中，与CMS 老年代垃圾回收器搭配使用

PairNew执行流程

Parallel Scavenge

Parallel Scavenge是JDK8默认的年轻代垃圾回收器，多线程并行回收，关注的是系统的吞吐量。具备自动调整堆内存大小的特点。

停顿时间越短就越适合需要与用户交互的程序，良好的响应速度能提升用户体验。而高吞吐量则可以高效率地利用CPU时间，尽快完成程序的运算任务，主要适合在后台运算而不需要太多交互的任务。

参数-XX:+UseAdaptiveSizePolicy，这是一个开关参数，打开参数后，就不需要手工指定新生代的大小（-Xmn）、Eden和Survivor区的比例（-XX:SurvivorRatio）、晋升老年代对象年龄（-XX:PretenureSizeThreshold）等细节参数了。

算法	优点	缺点	使用场景
复制算法	吞吐量高，而且手动可控。为了提高吞吐量，虚拟机会动态调整堆的参数	不能保证单次的停顿时间	后台任务，不需要与用户交互，并且容易产生大量的对象比如：大数据的处理，大文件导出

Paraller Scavenge执行流程

3.4.2 老年代垃圾回收器

Serial Old

Serial Old是Serial垃圾回收器的老年代版本，采用单线程串行回收

算法	优点	缺点	使用场景
标记-整理算法(Mark-Compact)	单CPU处理器下吞吐量非常出色	多CPU下吞吐量不如其他垃圾回收器，堆如果偏大会让用户线程处于长时间的等待	与Serial垃圾回收器搭配使用，或者在CMS特殊情况下使用

Serial Old执行流程

Parallel Old

Parallel Old是为Parallel Scavenge收集器设计的老年代版本，利用多线程并发收集。

算法	优点	缺点	使用场景
标记-整理算法(Mark-Compact)	并发收集，在多核CPU下效率较高	暂停时间会比较长	与Parallel Scavenge配套使用

Parallel Old执行流程

CMS垃圾回收器关注的是系统的暂停时间，允许用户线程和垃圾回收线程在某些步骤中同时执行，减少了用户线程的等待时间。参数：XX:+UseConcMarkSweepGC

CMS执行流程

执行步骤：

1.初始标记：用极短的时间标记出GC Roots能够直接关联的对象，此时需要STW。

2.并发标记：标记所有的对象，用户线程不需要暂停。

3.重新标记：由于并发标记阶段有些对象会发生了变化，存在错标、漏标等情况，需要重新标记。

4.并发清理：清理死亡的对象，用户线程不需要暂停。

缺点

1.CMS使用了标记-清除算法，在垃圾收集结束之后会出现大量的内存碎片，CMS会在Full GC时进行碎片的整理。这样会导致用户线程暂停，可以使用-XX:CMSFullGCsBeforeCompaction=N 参数（默认0）调整N次Full GC之后再整理。

2.无法处理在并发清理过程中产生的“浮动垃圾”，不能做到完全的垃圾回收。只能依赖下一次GC清理

3.如果老年代内存不足无法分配对象，CMS就会退化成Serial Old单线程回收老年代。

CMS的线程资源抢夺问题：

1.在CMS中并发阶段运行时的线程数可以通过-XX:ConcGCThreads参数设置，默认值为0，由系统计算得出。

2.计算公式为(-XX:ParallelGCThreads定义的线程数 + 3) / 4， ParallelGCThreads是STW停顿之后的并行线程数

3.ParallelGCThreads是由处理器核数决定的：

3.1 当cpu核数小于8时，ParallelGCThreads = CPU核数

3.2 否则 ParallelGCThreads = 8 + (CPU核数 – 8 )*5/8

CMS总结：

算法	优点	缺点	使用场景
标记-清除算法	系统由于垃圾回收出现的停顿时间较短，用户体验好	见上面分析	大型的互联网系统中用户请求数据量大、频率高的场景比如订单接口、商品接口等

3.4.3 G1垃圾回收器

G1（Garbage-First Garbage Collector）在 JDK 1.7 时引入，在 JDK 9 时取代 CMS 成为了默认的垃圾收集器

内存结构

G1的整个堆会被划分成多个大小相等的区域，称之为区Region，区域不要求是连续的。分为Eden、Survivor、 Old区。Region的大小通过堆空间大小/2048计算得到，也可以通过参数-XX:G1HeapRegionSize=32m指定(其中32m指定region大小为32M)，Region size必须是2的指数幂，取值范围从1M到32M。

G1内存结构

Young GC（年轻代GC）

回收Eden区和Survivor区中不用的对象。会导致STW，G1中可以通过参数 -XX:MaxGCPauseMillis=n（默认200）设置每次垃圾回收时的最大暂停时间毫秒数，G1垃圾回收器会尽可能地保证暂停时间。

1.新创建的对象放入Eden区，当G1判断年轻代不足时(默认为 60%)，无法分配对象时触发Young GC

2.标记出Eden和Survivor区域中的存活对象。

3.根据配置的最大暂停时间选择某些区域将存活对象复制到一个新的Survivor区中（年龄+1），清空这些区域。（G1在进行Young GC的过程中会去记录每次垃圾回收时每个Eden区和Survivor区的平均耗时，以作为下次回收时的参考依据。这样就可以根据配置的最大暂停时间计算出本次回收时最多能回收多少个Region区域了。比如 -XX:MaxGCPauseMillis=n（默认200），每个Region回收耗时40ms，那么这次回收最多只能回收4个Region。）

4.后续Young GC时与之前一致，只不过Survivor区域中的对象会被搬运至另外一个Survivor区域

5.某个对象年龄达到阈值放入老年代

6.部分对象如果大小超过Region的一半，会直接放入老年代，这类老年代被称为Humongous区。比如堆内存是4G，每个Region是2M，只要一个大对象超过了1M就被放入Humongous区，如果对象过大会横跨多个Region。

7.多次回收之后，会出现很多Old老年代区，此时总堆占有率达到阈值时（-XX:InitiatingHeapOccupancyPercent默认45%）会触发混合回收MixedGC。回收所有年轻代和部分老年代的对象以及大对象区。采用复制算法来完成。