JVM 垃圾回收算法和垃圾回收器

垃圾回收的区域

• 栈：栈中的生命周期是跟随线程，因此通常不须要关注
• 堆：堆中的对象是垃圾回收的重点
• 方法区：这一块也会发生垃圾回收，不过这块的效率比较低，通常不是咱们关注的重点

怎么判断对象的存活

通常有两种方式（引用计数法、可达性分析），JVM使用的是可达性分析

引用计数法

给对象添加一个引用计数器，当对象增长一个引用时计数器加 1，引用失效时计数器减 1。引用计数为 0 的对象可被回收（Python 在用，但主流虚拟机没有使用）

• 优势：快，方便，实现简单
• 缺陷：对象相互引用时（A.instance=B 同时 B.instance=A），很难判断对象是否该回收

可达性分析

来断定对象是否存活的。这个算法的基本思路就是经过一系列的称为“GC Roots”的对象做为起始点，从这些节点开始向下搜索，搜索所走过的路径称为引用链（Reference Chain），当一个对象到 GC Roots 没有任何引用链相连时，则证实此对象是不可用的

做为 GC Roots 的对象包括下面几种：

1. 当前虚拟机栈中局部变量表中的引用的对象
2. 方法区中类静态属性引用的对象
3. 方法区中的常量引用的对象

finalize

Java提供finalize()方法，垃圾回收器准备释放内存的时候，会先调用finalize()，能够完成对象的拯救（不被回收），可是不能保证必定不被回收，说白了就是没啥用，一个坑

各类引用（Reference）

Reference 中存储的数据表明的是另外一块内存的起始地址

强引用

通常的 Object obj = new Object() ，就属于强引用。 （若是有 GCroots 的强引用）垃圾回收器绝对不会回收它，当内存不足时宁愿抛出 OOM 错误，使得程序异常中止，也不会回收强引用对象

软引用

SoftReference垃圾回收器在内存充足的时候不会回收它，而在内存不足时会回收它

示例代码：

public static void main(String[] args) {
    String str = new String("SunnyBear"); // 强引用
    SoftReference<String> strSoft = new SoftReference<String>(str);
    str = null; // 干掉强引用，确保只有strSoft的软引用
    System.out.println(strSoft.get()); // SunnyBear
    System.gc(); // 执行一次gc，此命令请勿在线上使用，仅做示例操做
    System.out.println("------------ gc after");
    System.out.println(str); // null
    System.out.println(strSoft.get()); // SunnyBear
}
复制代码

因此软引用通常用来实现一些内存敏感的缓存，只要内存空间足够，对象就会保持不被回收掉

弱引用 WeakReference

垃圾回收器在扫描到该对象时，不管内存充足与否，都会回收该对象的内存

示例代码：

public static void main(String[] args) {
    String str = new String("SunnyBear"); // 强引用
    WeakReference<String> strWeak = new WeakReference<String>(str);
    str = null; // 干掉强引用，确保只有strSoft的软引用
    System.out.println(strWeak.get()); // SunnyBear
    System.gc(); // 执行一次gc，此命令请勿在线上使用，仅做示例操做
    System.out.println("------------ gc after"); // null
    System.out.println(str); // null
    System.out.println(strWeak.get()); // null
}
复制代码

实际应用，如WeakHashMap、ThreadLocal

虚引用 PhantomReference

幽灵引用，最弱，被垃圾回收的时候收到一个通知，若是一个对象只具备虚引用，那么它和没有任何引用同样，任什么时候候均可能被回收

虚引用主要用来跟踪对象被垃圾回收器回收的活动

GC

Minor GC

• 特色: 发生在新生代上，发生的较频繁，执行速度较快
• 触发条件: Eden 区空间不足/空间分配担保

Full GC

• 特色:主要发生在老年代上（新生代也会回收），较少发生，执行速度较慢
• 触发条件:
  • 调用 System.gc()
  • 老年代区域空间不足
  • 空间分配担保失败
  • JDK 1.7 及之前的永久代(方法区)空间不足

垃圾回收算法

复制算法（Copying）

将可用内存按容量划分为大小相等的两块，每次只使用其中的一块。当这一块的内存用完了，就将还存活着的对象复制到另一块上面，而后再把已使用过的内存空间一次清理掉。这样使得每次都是对整个半区进行内存回收，内存分配时也就不用考虑内存碎片等复杂状况，只要按顺序分配内存便可， 实现简单，运行高效。只是这种算法的代价是将内存缩小为了原来的一半。

• 优势
  • 简单高效，不会出现内存碎片
• 缺点
  • 内存利用率低
  • 存活对象较多时效率明显下降，由于须要移动每一个不可回收数据的内存实际位置

注： 专门研究代表，新生代中的对象 90%是“朝生夕死”的，因此通常来讲回收占据 10% 的空间够用了，因此并不须要按照 1:1 的比例来划份内存空间，而是 将内存分为一块较大的 Eden 空间和两块较小的 Survivor 空间，每次使用 Eden 和其中一块 Survivor[1]。当回收时，将 Eden 和 Survivor 中还存活着的对象一 次性地复制到另一块 Survivor 空间上，最后清理掉 Eden 和刚才用过的 Survivor 空间。 HotSpot 虚拟机默认 Eden 和 Survivor 的大小比例是 8:1，也就是每次新生代中可用内存空间为整个新生代容量的 90%（80%+10%），只有 10%的内存会被 “浪费”。

标记-清除算法（Mark-Sweep）

首先标记全部须要回收的对象，而后统一回收被标记的对象

• 优势
  • 利用率100%
• 缺点
  • 标记和清除效率都不高（对比复制算法）
  • 会产生大量不连续的内存碎片

标记-整理算法（Mark-compact）

首先标记出全部须要回收的对象，在标记完成后，后续步骤不是直接对可回收对象进行清理，而是让全部存活的对象都向一端移动，而后直接清理掉端，边界之外的内存

• 优势
  • 利用率100%
  • 没有内存碎片
• 缺点
  • 标记和清除效率都不高（对比复制算法及标记清楚算法）

垃圾回收器

jvm 垃圾回收器把上面的三种算法所有用到了，采用分代收集

• 新生代：复制算法

收集器	收集对象和算法	收集器类型
Serial	新生代，复制算法	单线程
ParNew	新生代，复制算法	并行的多线程收集器
Parallel Scavenge	新生代，复制算法	并行的多线程收集器

• 老年代：标记清除算法和标记整理算法

收集器	收集对象和算法	收集器类型
Serial Old	老年代，标记整理算法	单线程
Parallel Old	老年代，标记整理算法	并行的多线程收集器
CMS（Conc Mark Sweep ）	老年代，标记清除算法	并行和并发收集器
G1（Garbage First）	跨新生代和老年代，复制算法 + 标记整理算法	并行和并发收集器

注：

• 并行：垃圾收集的多线程的同时进行
• 并发：垃圾收集的多线程和用户应用的多线程同时进行
• 使用 jps -v 能够看到使用的垃圾收集器，例如：-XX:+UseConcMarkSweepGC （CMS）

能够配套使用的垃圾回收器

连线表示能够 新生代 和 老年代 配套使用的垃圾收集器

Serial/Serial Old

最古老的，单线程，独占式，成熟，适合单 CPU 服务器 -XX:+UseSerialGC 新生代和老年代都用串行收集器

ParNew

ParNew 和 Serial 基本没区别，惟一的区别：多线程，多 CPU 的，停顿时间比 Serial 少

-XX:+UseParNewGC 新生代使用 ParNew，老年代使用 Serial Old

能够和CMS搭配使用

Parallel Scavenge（ParallerGC）/Parallel Old

关注吞吐量的垃圾收集器，高吞吐量则能够高效率地利用 CPU 时间，尽快完成程序的运算任务，主要适合在后台运算而不须要太多交互的任务。所谓吞吐量就是 CPU 用于运行用户代码的时间与 CPU 总消耗时间的比值，即吞吐量=运行用户代码时间/（运行用户代码时间+垃圾收集时间），虚拟机总共运行了 100 分钟，其中垃圾收集花掉 1 分钟，那有吞吐效率就是 99%

CMS（Concurrent Mark Sweep）

收集器是一种以获取最短回收停顿时间为目标的收集器。目前很大一部分的 Java 应用集中在互联网站或者 B/S 系统的服务端上，这类应用尤为重视服务的响应速度，但愿系统停顿时间最短，以给用户带来较好的体验。

CMS 收集器就很是符合这类应用的需求。-XX:+UseConcMarkSweepGC ，通常新生代使用 ParNew，老年代的用 CMS，从名字（包含“Mark Sweep”）上就能够看出，CMS 收集器是基于“标记—清除”算法实现的，它的运做过程相对于前面几种收集器来讲更复杂一些

回收过程

整个过程分为 4 个步骤，包括：

1. 初始标记：仅仅只是标记一下 GC Roots 能直接关联到的对象，速度很快，须要停顿（STW -Stop the world）
2. 并发标记：从 GC Root 开始对堆中对象进行可达性分析，找到存活对象，它在整个回收过程当中耗时最长，不须要停顿
3. 从新标记：为了修正并发标记期间因用户程序继续运做而致使标记产生变更的那一部分对象的标记记录，须要停顿(STW)。这个阶段的停顿时间通常会比初始标记阶段稍长一些，但远比并发标记的时间短
4. 并发清除：不须要停顿

优缺点

• 优势
  • 因为整个过程当中耗时最长的并发标记和并发清除过程收集器线程均可以与用户线程一块儿工做，因此，从整体上来讲，CMS 收集器的内存回收过程是与用户线程一块儿并发执行的
• 缺点
  • CPU 资源敏感：由于并发阶段多线程占据 CPU 资源，若是 CPU 资源不足，效率会明显下降
  • 因为 CMS 并发清理阶段 用户线程还在运行着，伴随程序运行天然就还会有新的垃圾不断产生，这一部分垃圾出如今标记过程以后，CMS 没法在当次收集中处理掉它们，只好留待下一次 GC 时再清理掉。这一部分垃圾就称为 浮动垃圾
  • 因为浮动垃圾的存在，所以须要预留出一部份内存，意味着 CMS 收集不能像其它收集器那样等待老年代快满的时候再回收。在 1.6 的版本中老年代空间使用率阈值(92%)，若是预留的内存不够存放浮动垃圾，就会出现 Concurrent Mode Failure，这时虚拟机将临时启用 Serial Old 来替代 CMS。
  • 会产生内存碎片：标记-清除算法 会致使产生不连续的内存碎片

G1

G1相比较CMS的改进

• 基于标记-整理算法, 不会产生空间碎片，分配大对象时不会没法获得连续的空间而提早触发一次full gc
• 停顿时间可控： G1能够经过设置预期停顿时间（Pause time）来控制垃圾收集时间，可是这个预期停顿时间G1只能尽可能作到，而不是必定能作到

可预测的停顿：

G1 收集器之因此能创建可预测的停顿时间模型，是由于它能够有计划地避免在整个 Java 堆中进行全区域的垃圾收集。G1 跟踪各个 Region 里面的垃圾堆积的价值大小（回收所得到的空间大小以及回收所需时间的经验值），在后台维护一个优先列表，每次根据容许的收集时间，优先回收价值最大的 Region（这也就是 Garbage-First 名称的来由）。这种使用 Region 划份内存空间以及有优先级的区域回收方式，保证了 G1 收集器在有限的时间内能够获取尽可高的收集效率

G1的设置参数

• -XX:+UseG1GC // 开启G1
• -XX:MaxGCPauseMillis=200 // 预期停顿时间200毫秒，默认也是200
• -XX:G1HeapRegionSize=2 // 设置每一个区域大小2M，其必须是2的幂，范围容许为1Mb到32Mb
• -XX:G1NewSizePercent // 新生代最小值，默认值 5%
• -XX:G1MaxNewSizePercent // 新生代最大值，默认值 60%
• -XX:ParallelGCThreads // STW 期间，并行 GC 线程数
• -XX:ConcGCThreads=n // 并发标记阶段，并行执行的线程数

G1是怎么划堆内存的呢

G1 把堆划分红多个大小相等的 独立区域（Region），新生代和老年代再也不物理隔离

G1 算法将堆划分为若干个独立区域（Region），它仍然属于分代收集器。不过，这些区域的一部分包含新生代，新生代的垃圾收集依然采用暂停全部应用线程的方式，将存活对象拷贝到老年代或者 Survivor 空间。例如其中一个独立区域如图：

GC 的模式

1. Young GC

Young GC 主要是对 Eden 区进行 GC，它在 Eden 空间耗尽时会被触发。在这种状况下，Eden 空间的数据移动到 Survivor 空间中，若是 Survivor 空间不够，Eden 空间的部分数据会直接晋升到老年代空间。Survivor 区的数据移动到新的 Survivor 区中，也有部分数据晋升到老年代空间中。最终 Eden 空间的数据为空，GC 中止工做，应用线程继续执行

2. Mixed GC

选定全部新生代里的 Region，外加根据 global concurrent marking 统计得出收集收益高的若干老年代 Region。在用户指定的开销目标范围内尽量选择益高的老年代 Region。Mixed GC 不是 full GC，它只能回收部分老年代的 Region。若是 mixed GC 实在没法跟上程序分配内存的速度，致使老年代填满没法继续进行 Mixed GC，就会使用 serial old GC（full GC）来收集整个 GC heap。因此咱们能够知道，G1 是不提供 full GC 的

收集过程

大体分为4个步骤：

1. 初始标记：仅仅只是标记一下 GC Roots 能直接关联到的对象，而且修改 TAMS（Nest Top Mark Start）的值，让下一阶段用户程序并发运行时，能在正确能够的 Region 中建立对象，此阶段须要停顿线程(STW)，但耗时很短
2. 并发标记：从 GC Root 开始对堆中对象进行可达性分析，找到存活对象，此阶段耗时较长，但可与用户程序并发执行
3. 最终标记：为了修正在并发标记期间因用户程序继续运做而致使标记产生变更的那一部分标记记录，虚拟机将这段时间对象变化记录在线程的 Remembered Set Logs 里面，最终标记阶段须要把 Remembered Set Logs 的数据合并到 Remembered Set 中。这阶段须要停顿线程(STW)，可是可并行执 行
4. 筛选回收：首先对各个 Region 中的回收价值和成本进行排序，根据用户所指望的 GC 停顿时间来制定回收计划。此阶段其实也能够作到与用户程序一块儿并发执行，可是由于只回收一部分 Region，时间是用户可控制的，并且停顿用户线程将大幅度提升收集效率

垃圾回收器的一些重要参数

参数	描述
UseSerialGC	虚拟机运行在 Client 模式下的默认值，打开此开关后，使用 Serial+Serial Old 的收集器组合进行内存回收
UseParNewGC	打开此开关后，使用 ParNew + Serial Old 的收集器组合进行内存回收
UseConcMarkSweepGC	打开此开关后，使用 ParNew + CMS + Serial Old 的收集器组合进行内存回收。Serial Old 收集器将做为 CMS 收集器出现 Concurrent Mode Failure 失败后的后备收集器使用
UseParallelGC	虚拟机运行在 Server 模式下的默认值，打开此开关后，使用 Parallel Scavenge + Serial Old(PS MarkSweep) 的收集器组合进行内存回收
UseParallelOldGC	打开此开关后，使用 Parallel Scavenge + Parallel Old 的收集器组合进行内存回收
SurvivorRatio	新生代中 Eden 区域与 Survivor 区域的容量比值，默认为 8，表明 Eden : Survivor = 8 : 1
PretenureSizeThreshold	直接晋升到老年代的对象大小，设置这个参数后，大于这个参数的对象将直接在老年代分配
MaxTenuringThreshold	晋升到老年代的对象年龄，每一个对象在坚持过一次 Minor GC 以后，年龄就增长 1，当超过这个参数值时就进入老年代
UseAdaptiveSizePolicy	动态调整 Java 堆中各个区域的大小以及进入老年代的年龄
HandlePromotionFailure	是否容许分配担保失败，即老年代的剩余空间不足以应付新生代的整个 Eden 和 Survivor 区的全部对象都存活的极端状况
ParallelGCThreads	设置并行 GC 时进行内存回收的线程数
GCTimeRatio GC	时间占总时间的比率，默认值为 99，即容许 1% 的 GC 时间，仅在使用 Parallel Scavenge 收集器生效
MaxGCPauseMillis	设置 GC 的最大停顿时间，仅在使用 Parallel Scavenge 收集器时生效
CMSInitiatingOccupancyFraction	设置 CMS 收集器在老年代空间被使用多少后触发垃圾收集，默认值为 68%，仅在使用 CMS 收集器时生效
UseCMSCompactAtFullCollection	设置 CMS 收集器在完成垃圾收集后是否要进行一次内存碎片整理，仅在使用 CMS 收集器时生效
CMSFullGCsBeforeCompaction	设置 CMS 收集器在进行若干次垃圾收集后再启动一次内存碎片整理，仅在使用 CMS 收集器时生效