垃圾回收

stay_foolish
402 阅读11分钟

1. 如何定位垃圾

1. 引用计数法；
2. 根可达算法

2. 常见的垃圾回收算法

1. 标记清除 - 位置不连续 产生碎片
2. 拷贝算法 - 没有碎片，浪费空间
3. 标记压缩 - 没有碎片，效率偏低

3. JVM内存分代模型（用于分代垃圾回收算法）

1. 部分垃圾回收器使用的模型；
2. 新生代 + 老年代 + 永久代（1.7）/元数据区（1.8）Metaspace（不在堆，操作系统管理）
    1. 永久代 元数据 - class
    2. 永久代必须指定大小限制，元数据可以设置也可以不设置，无上限（受限于物理内存）
    3. 字符串常量 1.7-永久代 1.8-堆
    4. MethodArea逻辑概念 - 永久代 元数据
3. 新生代 = Eden + 2个suvivor区  
    1. YGC回收之后，大多数的对象会被回收，活着的进入s0;
    2. 再次YGC，eden + s1 -> s0;
    3. 再次YGC，eden + s0 -> s1;
    4. 年龄足够 -> 老年代
    5. s区装不下 -〉老年代
4. 老年代
    1. 老年代满了FGC Full GC
5. GC Tuning
    1. 尽量减少FGC；
    2. MinoreGC = YGC
    3. MajorGC = FGC

image.png

4. 常见的垃圾回收器

image.png 分类

年轻代GC
    UserSerialGC：串行垃圾收集器
    UserParallelGC：并行垃圾收集器
    UseParNewGC：年轻代的并行垃圾回收器
老年代GC
    UserSerialOldGC：串行老年代垃圾收集器（已经被移除）
    UseParallelOldGC：老年代的并行垃圾回收器
    UseConcMarkSweepGC：（CMS）并发标记清除
通用
    UseG1GC：G1垃圾收集器
4.1 Serial收集器

一个单线程的收集器.STW

对于限定单个CPU环境来说，没有线程交互的开销可以获得最高的单线程垃圾收集效率，因此Serial垃圾收集器依然是java虚拟机运行在Client模式下默认的新生代垃圾收集器。

对应JVM参数是：-XX:+UseSerialGC
开启后会使用：Serial(Young区用) + Serial Old(Old区用)的收集器组合
表示：新生代、老年代都会使用串行回收收集器，新生代使用复制算法，老年代使用标记-整理算法
4.2 ParNew收集器

使用多线程进行垃圾回收，在垃圾收集时，会Stop-The-World暂停其他所有的工作线程直到它收集结束。

它就是Serial收集器新生代的并行多线程版本，最常见的应用场景是配合老年代的CMS GC工作，其余的行为和Seria收集器完全一样，ParNew垃圾收集器在垃圾收集过程中同样也要暂停所有其他的工作线程。它是很多Java虚拟机运行在Server模式下新生代的默认垃圾收集器。

常用对应JVM参数：-XX:+UseParNewGC启用ParNew收集器，只影响新生代的收集，不影响老年代。
开启上述参数后，会使用：ParNew(Young区)+ Serial Old的收集器组合，新生代使用复制算法，老年代采用标记-整理算法
4.3 Parallel收集器

Parallel Scavenge收集器类似ParNew，也是一个新生代垃圾收集器，使用复制算法，也是一个并行的多线程的垃圾收集器，俗称吞吐量优先收集器。一句话：串行收集器在新生代和老年代的并行化。

它重点关注的是：

可控制的吞吐量(Thoughput=运行用户代码时间(运行用户代码时间+垃圾收集时间),也即比如程序运行100分钟，垃圾收集时间1分钟，吞吐量就是99% )。高吞吐量意味着高效利用CPU的时间，它多用于在后台运算而不需要太多交互的任务。

自适应调节策略也是ParallelScavenge收集器与ParNew收集器的一个重要区别。(自适应调节策略:虚拟机会根据当前系统的运行情况收集性能监控信息，动态调整这些参数以提供最合适的停顿时间（-XX:MaxGCPauseMillis）或最大的吞吐量。

常用JVM参数：-XX:+UseParallelGC或-XX:+UseParallelOldGC（可互相激活）使用Parallel Scanvenge收集器。
开启该参数后：新生代使用复制算法，老年代使用标记-整理算法。
多说一句：-XX:ParallelGCThreads=数字N 表示启动多少个GC线程
cpu>8 N= 5/8
cpu<8 N=实际个数
4.4 ParallelOld收集器

Parallel Old收集器是Parallel Scavenge的老年代版本，使用多线程的标记-整理算法，Parallel Old收集器在JDK1.6才开始提供。

在JDK1.6之前，新生代使用ParallelScavenge收集器只能搭配年老代的Serial Old收集器，只能保证新生代的吞吐量优先，无法保证整体的吞吐量。在JDK1.6之前（Parallel Scavenge + Serial Old )

Parallel Old 正是为了在年老代同样提供吞吐量优先的垃圾收集器，如果系统对吞吐量要求比较高，JDK1.8后可以优先考虑新生代Parallel Scavenge和年老代Parallel Old收集器的搭配策略。在JDK1.8及后〈Parallel Scavenge + Parallel Old )

JVM常用参数：-XX:+UseParallelOldGC使用Parallel Old收集器，设置该参数后，新生代Parallel+老年代Parallel Old。
4.5 CMS收集器

CMS收集器(Concurrent Mark Sweep：并发标记清除）是一种以获取最短回收停顿时间为目标的收集器。

适合应用在互联网站或者B/S系统的服务器上，这类应用尤其重视服务器的响应速度，希望系统停顿时间最短。

CMS非常适合地内存大、CPU核数多的服务器端应用，也是G1出现之前大型应用的首选收集器。

image.png Concurrent Mark Sweep并发标记清除，并发收集低停顿,并发指的是与用户线程一起执行

JVM参数：-XX:+UseConcMarkSweepGC开启该参数后会自动将-XX:+UseParNewGC打开。
使用ParNew（Young区用）+ CMS（Old区用）+ Serial Old的收集器组合，Serial Old将作为CMS出错的后备收集器。

步骤如下：

1. 初始标记（CMS initial mark） - 只是标记一下GC Roots能直接关联的对象，速度很快，仍然需要暂停所有的工作线程。
2. 并发标记（CMS concurrent mark）和用户线程一起 - 进行GC Roots跟踪的过程，和用户线程一起工作，不需要暂停工作线程。主要标记过程，标记全部对象。
3. 重新标记（CMS remark）- 为了修正在并发标记期间，因用户程序继续运行而导致标记产生变动的那一部分对象的标记记录，仍然需要暂停所有的工作线程。由于并发标记时，用户线程依然运行，因此在正式清理前，再做修正。
4. 并发清除（CMS concurrent sweep） - 清除GCRoots不可达对象，和用户线程一起工作，不需要暂停工作线程。基于标记结果，直接清理对象，由于耗时最长的并发标记和并发清除过程中，垃圾收集线程可以和用户现在一起并发工作，所以总体上来看CMS 收集器的内存回收和用户线程是一起并发地执行。

优缺点：

优点：并发收集低停顿。
缺点：并发执行，对CPU资源压力大，采用的标记清除算法会导致大量碎片。

由于并发进行，CMS在收集与应用线程会同时会增加对堆内存的占用，也就是说，CMS必须要在老年代堆内存用尽之前完成垃圾回收，否则CMS回收失败时，将触发担保机制，串行老年代收集器将会以STW的方式进行一次GC，从而造成较大停顿时间。

标记清除算法无法整理空间碎片，老年代空间会随着应用时长被逐步耗尽，最后将不得不通过担保机制对堆内存进行压缩。

CMS也提供了参数-XX:CMSFullGCsBeForeCompaction(默认O，即每次都进行内存整理)来指定多少次CMS收集之后，进行一次压缩的Full GC。

4.6 SerialOld收集器

Serial Old是Serial垃圾收集器老年代版本，它同样是个单线程的收集器，使用标记-整理算法，这个收集器也主要是运行在 Client默认的java虚拟机默认的年老代垃圾收集器。

在Server模式下，主要有两个用途(了解，版本已经到8及以后):

在JDK1.5之前版本中与新生代的Parallel Scavenge 收集器搭配使用。(Parallel Scavenge + Serial Old )
作为老年代版中使用CMS收集器的后备垃圾收集方案。
4.7 G1收集器

G1是一种服务器端的垃圾收集器，应用在多处理器和大容量内存环境中，在实现高吞吐量的同时，尽可能的满足垃圾收集暂停时间的要求。另外，它还具有以下特性:

1. 和CMS收集器一样，能与应用程序线程并发执行。
2. 整理空闲空间更快。
3. 需要更多的时间来预测GC停顿时间。
4. 不希望牺牲大量的吞吐性能。
5. 不需要更大的Java Heap。

image.png G1收集器的设计目标是取代CMS收集器，它同CMS相比，在以下方面表现的更出色：

1. G1是一个有整理内存过程的垃圾收集器，不会产生很多内存碎片。
2. G1的Stop The World(STW)更可控，G1在停顿时间上添加了预测机制，用户可以指定期望停顿时间。
3. CMS垃圾收集器虽然减少了暂停应用程序的运行时间，但是它还是存在着内存碎片问题。于是，为了去除内存碎片问题，同时又保留CMS垃圾收集器低暂停时间的优点，JAVA7发布了一个新的垃圾收集器-G1垃圾收集器。
4. G1是在2012年才在jdk1.7u4中可用。oracle官方计划在JDK9中将G1变成默认的垃圾收集器以替代CMS。它是一款面向服务端应用的收集器，主要应用在多CPU和大内存服务器环境下，极大的减少垃圾收集的停顿时间，全面提升服务器的性能，逐步替换java8以前的CMS收集器。
5. 主要改变是Eden，Survivor和Tenured等内存区域不再是连续的了，而是变成了一个个大小一样的region ,每个region从1M到32M不等。一个region有可能属于Eden，Survivor或者Tenured内存区域。

特点：

1. G1能充分利用多CPU、多核环境硬件优势，尽量缩短STW。
2. G1整体上采用标记-整理算法，局部是通过复制算法，不会产生内存碎片。
3. 宏观上看G1之中不再区分年轻代和老年代。把内存划分成多个独立的子区域(Region)，可以近似理解为一个围棋的棋盘。
4. G1收集器里面讲整个的内存区都混合在一起了，但其本身依然在小范围内要进行年轻代和老年代的区分，保留了新生代和老年代，但它们不再是物理隔离的，而是一部分Region的集合且不需要Region是连续的，也就是说依然会采用不同的GC方式来处理不同的区域。
5. G1虽然也是分代收集器，但整个内存分区不存在物理上的年轻代与老年代的区别，也不需要完全独立的survivor(to space)堆做复制准备。G1只有逻辑上的分代概念，或者说每个分区都可能随G1的运行在不同代之间前后切换。
4.8 G1 与 CMS
-XX:+UseG1GC
-XX:G1HeapRegionSize=n：设置的G1区域的大小。值是2的幂，范围是1MB到32MB。目标是根据最小的Java堆大小划分出约2048个区域。
-XX:MaxGCPauseMillis=n：最大GC停顿时间，这是个软目标，JVM将尽可能（但不保证）停顿小于这个时间。
-XX:InitiatingHeapOccupancyPercent=n：堆占用了多少的时候就触发GC，默认为45。
-XX:ConcGCThreads=n：并发GC使用的线程数。
-XX:G1ReservePercent=n：设置作为空闲空间的预留内存百分比，以降低目标空间溢出的风险，默认值是10%。

开发人员仅仅需要声明以下参数即可：

三步归纳：开始G1+设置最大内存+设置最大停顿时间

-XX:+UseG1GC
-Xmx32g
-XX:MaxGCPauseMillis=100

文章参考链接： blog.csdn.net/u011863024/…

5. 三色标记

5.1 颜色分类

白色：尚未访问过；

灰色：本对象已访问过，本对象引用到的其他对象尚未全部访问完；

黑色：本对象已访问过，而且本对象引用到的其他对象也全部访问过了。

5.2 存在问题
5.2.1 漏标-浮动垃圾
已经被标记为黑色的对象，它有一个变量为E(灰色)，在下一刻工作线程将E置为null,则之前的E在该次垃圾回收的过程中不能被回收；
5.2.2 错标
本来应该是黑色的，标记为白色，进行了垃圾回收。

var G = objE.fieldG; // 1.读
objE.fieldG = null;  // 2.写
objD.fieldG = G;     // 3.写

解决方案：
CMS：写屏障 + 增量更新
    不要求保留原始快照，而是针对新增的引用，将其记录下来等待遍历，即增量更新
G1：写屏障 + SATB
    尝试保留开始时的对象图，即原始快照（Snapshot At The Beginning，SATB），当某个时刻 的 GC Roots 确定后，当时的对象图就已经确定了。
ZGC：读屏障
    读屏障是直接针对第一步：var G = objE.fieldG;，当读取成员变量时，一律记录下来：
avatar
文章
阅读
粉丝