JVM 学习笔记（五）

前言：

　　前面的文件介绍了JVM的内存模型以及各个区域存放了那些内容，本编文章将介绍JVM中的垃圾回收Garbage Collector，和你们一块儿探讨一下。

如何肯定一个对象是垃圾：

　　这里介绍两种方法：

• 引用计数法

　　对于某个对象而言，只要应用程序中持有该对象的引用，就说明该对象不是垃圾，若是一个对象没有任何指针对其引用，它就是垃圾。

• 可达性分析

　　经过GC Root的对象，开始向下寻找，看某个对象是否可达。能做为GC Root:类加载器、Thread、虚拟机栈的本地变量表、static成员、常量引用、本地方法

栈的变量等。

垃圾回收算法：

　　已经可以肯定一个对象为垃圾以后，接下来要考虑的就是回收，怎么回收呢？得要有对应的算法，下面聊聊常见的垃圾回收算法。

• 标记-清除(Mark-Sweep)

1. 标记

　　找出内存中须要回收的对象，而且把它们标记出来。此时堆中全部的对象都会被扫描一遍，从而才能肯定须要回收的对象，比较耗时。

如图：绿色的区域表示当前存活的对象，灰色表示垃圾对象，白色表示没有用到的内存碎片。

      2. 清除

　　清除掉被标记须要回收的对象，释放出对应的内存空间。

 

有如下缺点：

标记清除以后会产生大量不连续的内存碎片，空间碎片太多可能会致使之后在程序运行过程当中须要分配较大对象时，没法找到足够的连续内存而不得不提早触发另

一次垃圾收集动做。

(1)标记和清除两个过程都比较耗时，效率不高

(2)会产生大量不连续的内存碎片，空间碎片太多可能会致使之后在程序运行过程当中须要分配较大对象时，没法找到足够的连续内存而不得不提早触发另外一次垃圾收集动做。

• 复制(Copying)

　　将内存划分为两块相等的区域，每次只使用其中一块，如图所示：

 

 

　　当其中一块内存使用完了，就将还存活的对象复制到另一块上面，而后把已经使用过的内存空间一次清除掉。

下图的清理事后的内存模型：

 

 缺点：

　　由于这种方法保留的两个大小同样的内存区域，而同一时刻只会用到其中的一个，因此该方法内存的空间利用率比较低。

• 标记-整理(Mark-Compact)

　　标记过程仍然与"标记-清除"算法同样，可是后续步骤不是直接对可回收对象进行清理，而是让全部存活

的对象都向一端移动，而后直接清理掉端边界之外的内存。 

　　如图是标记阶段，该阶段会将全部的垃圾作上标记。

 

 　　下图是整理阶段，该阶段会将被标记的区域清除，并把存活的对象往一端移动，这样内存区域就会连续化，不会有空间碎片。

 

 

 

分代收集算法：

　　既然上面介绍了3中垃圾收集算法，那么在堆内存中到底用哪个呢？

Young区（俗称新生代）：复制算法(对象在被分配以后，可能生命周期比较短，Young区复制效率比较高) 

Old区（俗称老年代）：标记清除或标记整理(Old区对象存活时间比较长，复制来复制去不必，不如作个标记再清理) 

垃圾收集器的介绍：

　　若是说收集算法是内存回收的方法论，那么垃圾收集器就是内存回收的具体实现。

先上一张Young区和Old区垃圾收集器的适用图：

 

 下面来介绍这几种垃圾收集器：

1.Serial收集器

　　Serial收集器是最基本、发展历史最悠久的收集器，曾经（在JDK1.3.1以前）是虚拟机新生代收集的惟一选择。它是一种单线程收集器，不只仅意味着它只会使用一个CPU或者一条收集线程去完成垃圾收集工做，更重要的是其在进行垃圾收集的时候须要暂停其余线程。

　　下面简单总结一下Serial收集器：

优势：简单高效，拥有很高的单线程收集效率
缺点：收集过程须要暂停全部线程
算法：复制算法
适用范围：新生代
应用：Client模式下的默认新生代收集器

　　下图是该模式下的应用线程状态图：

 2. ParNew收集器

　　简单理解为是Serial收集器的多线程版本。

简单总结一下该收集器：

优势：在多CPU时，比Serial效率高。
缺点：收集过程暂停全部应用程序线程，单CPU时比Serial效率差。
算法：复制算法
适用范围：新生代
应用：运行在Server模式下的虚拟机中首选的新生代收集器

3. Parallel Scavenge收集器

　　Parallel Scavenge收集器是一个新生代收集器，它也是使用复制算法的收集器，又是并行的多线程收集器，看上去和ParNew同样，可是Parallel Scanvenge更关注系统的吞吐量 。

这里解释一下什么是吞吐量：

吞吐量=运行用户代码的时间/(运行用户代码的时间+垃圾收集时间)

好比虚拟机总共运行了100分钟，垃圾收集时间用了1分钟，吞吐量=(100-1)/100=99%。

若吞吐量越大，意味着垃圾收集的时间越短，则用户代码能够充分利用CPU资源，尽快完成程序的运算任务。

4. Serial Old收集器

　　Serial Old收集器是Serial收集器的老年代版本，也是一个单线程收集器，不一样的是采用"标记-整理算法"，运行过程和Serial收集器同样。

 下图是该模式下的应用线程状态图：

 

 5. Parallel Old收集器

　　Parallel Old收集器是Parallel Scavenge收集器的老年代版本，使用多线程和"标记-整理算法"进行垃圾回收。

6. CMS收集器

　　CMS(Concurrent Mark Sweep)收集器是一种以获取 最短回收停顿时间 为目标的收集器。

采用的是"标记-清除算法",整个过程分为4步 

 

(1) 初始标记   　　CMS initial mark     　　　　标记GC Roots能关联到的对象     　　　Stop The World--->速度很快 

(2) 并发标记  　　 CMS concurrent mark   　　进行GC Roots Tracing 

(3) 从新标记   　　CMS remark 　　　　　　  修改并发标记因用户程序变更的内容 　   Stop The World 

(4) 并发清除 　　   CMS concurrent sweep

 

　　因为整个过程当中，并发标记和并发清除，收集器线程能够与用户线程一块儿工做，因此整体上来讲，CMS收集器的内存回收过程是与用户线程一块儿并发地执行的。

简单总结一下优缺点：

优势：并发收集，低停顿。

缺点：产生大量空间碎片，并发阶段会下降吞吐量。

 

 7. G1收集器

　　G1 (Garbage-First)是一款面向服务器的垃圾收集器,主要针对配备多颗处理器及大容量内存的机器. 以极高几率知足GC停顿时间要求的同时,还具有高吞吐量性能特征. 在Oracle JDK 7 update 4 及以上版本中获得彻底支持, 专为如下应用程序设计:

• 能够像CMS收集器同样,GC操做与应用的线程一块儿并发执行
• 紧凑的空闲内存区间且没有很长的GC停顿时间.
• 须要可预测的GC暂停耗时.
• 不想牺牲太多吞吐量性能.
• 启动后不须要请求更大的Java堆.

　　G1的长期目标是取代CMS(Concurrent Mark-Sweep Collector, 并发标记-清除). 由于特性的不一样使G1成为比CMS更好的解决方案. 一个区别是,G1是一款压缩型的收集器.G1经过有效的压缩彻底避免了对细微空闲内存空间的分配,不用依赖于regions，这不只大大简化了收集器，并且还消除了潜在的内存碎片问题。除压缩之外，G1的垃圾收集停顿也比CMS容易估计，也容许用户自定义所但愿的停顿参数(pause targets)

概括总结一下G1收集器的特色：

1.并行与并发

2.分代收集（仍然保留了分代的概念）

3.空间整合（总体上属于“标记-整理”算法，不会致使空间碎片） 

4.可预测的停顿（比CMS更先进的地方在于能让使用者明确指定一个长度为M毫秒的时间片断内，消耗在垃圾收集 上的时间不得超过N毫秒）。

　　使用G1收集器时，Java堆的内存布局与就与其余收集器有很大差异，它将整个Java堆划分为多个大小相等的独立区域（Region），虽然还保留有新生代和老年代的概念，但新生代和老年代再也不是物理隔离的了，它们都是一部分Region（不须要连续）的集合。

　　工做过程能够分为以下几步：

初始标记（Initial Marking） 标记一下GC Roots可以关联的对象，而且修改TAMS的值，须要暂 停用户线程
并发标记（Concurrent Marking） 从GC Roots进行可达性分析，找出存活的对象，与用户线程并发 执行
最终标记（Final Marking） 修正在并发标记阶段由于用户程序的并发执行致使变更的数据，需 暂停用户线程
筛选回收（Live Data Counting and Evacuation） 对各个Region的回收价值和成本进行排序，根据 用户所指望的GC停顿时间制定回收计划

 

 

垃圾收集器分类：

串行收集器->Serial和Serial Old

　　只能有一个垃圾回收线程执行，用户线程暂停。 适用于内存比较小的嵌入式设备 。

并行收集器[吞吐量优先]->Parallel Scanvenge、Parallel Old

　　多条垃圾收集线程并行工做，但此时用户线程仍然处于等待状态。 适用于科学计算、后台处理等若交互场景 。

并发收集器[停顿时间优先]->CMS、G1

　　用户线程和垃圾收集线程同时执行(但并不必定是并行的，多是交替执行的)，垃圾收集线程在执行的时候不会停顿用户线程的运行。 适用于相对时间有要求的场景，好比Web 。 

理解吞吐量和停顿时间：

　　停顿时间->垃圾收集器 进行 垃圾回收终端应用执行响应的时间。

　　吞吐量->运行用户代码时间/(运行用户代码时间+垃圾收集时间) 。

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

 

如何选择合适的垃圾收集器：

　　首先咱们了解一下官网是如何建议的：

 

 　　简单翻译一下就是：

　　1.优先调整堆的大小让服务器本身来选择　　2.若是内存小于100M，使用串行收集器　　3.若是是单核，而且没有停顿时间要求，使用串行或JVM本身选　　4.若是容许停顿时间超过1秒，选择并行或JVM本身选　　5.若是响应时间最重要，而且不能超过1秒，使用并发收集器