GC Garbage Collectors

本质

一、算法

---

1、哪些是垃圾？

引用计数法：reference count

Python中使用了。

个对象如果没有任何与之关联的引用，即他们的引用计数都不为 0，则说明对象不太可能再被用到，那么这个对象就是可回收对象。

漏洞：循环引用

根可达性算法：Root Searching

如果在“GC roots”和一个对象之间没有可达路径，则称该对象是不可达的。要注意的是，不可达对象不等价于可回收对象，不可达对象变为可回收对象至少要经过两次标记过程。两次标记后仍然是可回收对象，则将面临回收。

例：main函数中的成员变量，顺着引用开始找，找不到的都是垃圾

2、什么时候清除？

3、用什么方式清除？

标记清除 Mark-Sweep：

缺陷：内存碎片化，泄漏

拷贝 Copying：

漏洞：浪费内存

标记整理 Mark-Compact：

漏洞：性能低

分代算法：

堆内存逻辑分区

二、垃圾收集器

---

三种算法都有毛病，三种的综合应用，诞生了各种各样的垃圾回收器

MinGC YGC

MaGC FullGC

垃圾收集器随着内存大小的不断增长而演进

内存分代：

JDK1.8之前使用分代模型

新生代采用复制算法，老年代使用标记清除和标记整理算法。

Serial + Serial Old：

针对几兆-几十兆

STW：a stop-the-world，copying collector which uses a single GC thread

Serial单线程STW垃圾回收 年青代 老年代

Parallel Scavenge + Parallel Old：（ps+po）：jdk1.8默认垃圾回收器

几十兆-上百兆1G

Parallel并行多线程

Concurrent GC：

GC线程和业务线程同时运行

初始标记（需要STW）：只需要找到根root上的对象

并发标记：业务GC并行（一定会有标错）

重新标记（需要STW）：清理上一步标错的

并发清理：清除上一步标错的

三色标记法算法：

ParNew+CMS：（1.5，1.6，1.7）

几十G

CMS方案：incremental Update的非常隐蔽的问题：并发标记，产生漏标

CMS的remark阶段，必须从头扫描一遍

内存不分代：

Epsilon：（jdk11诞生）

什么都不干，仅作记录，作用：1、开发JVM的人做debug用；2、内存超级大根本用不完可以使用

G1：（1.7诞生但不成熟，1.8可使用）

逻辑上分代，物理上不分代

G1的内存区域不是固定的E或者O

分区算法：部分回收（每个区大小为1-32,2的倍数）

一边清理一部分区域，一边占用一部分区域，特别大的对象放Humongous区域，也不够了开始FullGC

毛病：一次回收需要回收整个逻辑上的年青代（STW时间过长）

ZGC：zero paused GC（jdk11引入）

甲骨文官方支持

颜色算法：Colored Pointer+Load Barrier

分区更灵活（1M、2M、8M等），逻辑上不再分代，每100ms触发一次GC，每次找到特别满的区域进行清除

Shenandoash （jdk12引入）：

开源领域贡献