垃圾回收及垃圾收集器

一、什么是垃圾回收

程序的运行必然需要申请内存资源，无效的对象资源如果不及时处理就会一直占有内存 资源，终将导致内存溢出，所以对内存资源的管理是非常重要了。

C/C++语言的垃圾回收

在C/C++语言中，没有自动垃圾回收机制，是通过new关键字申请内存资源，通过delete 关键字释放内存资源。
如果，程序员在某些位置没有写delete进行释放，那么申请的对象将一直占用内存资源， 终可能会导致内存溢出

Java语言的垃圾回收

为了让程序员更专注于代码的实现，而不用过多的考虑内存释放的问题，所以，在Java语 言中，有了自动的垃圾回收机制，也就是我们熟悉的GC。
有了垃圾回收机制后，程序员只需要关心内存的申请即可，内存的释放由系统自动识别 完成。
换句话说，自动的垃圾回收的算法就会变得非常重要了，如果因为算法的不合理，导致 内存资源一直没有释放，同样也可能会导致内存溢出的。
当然，除了Java语言，C#、Python等语言也都有自动的垃圾回收机制

垃圾收集器以及内存分配

串行垃圾收集器

串行垃圾收集器，是指使用单线程进行垃圾回收，垃圾回收时，只有一个线程在工作， 并且java应用中的所有线程都要暂停，等待垃圾回收的完成。这种现象称之为 STW（Stop-The-World）。
对于交互性较强的应用而言，这种垃圾收集器是不能够接受的。
一般在Javaweb应用中是不会采用该收集器的。

并行垃圾收集器

并行垃圾收集器在串行垃圾收集器的基础之上做了改进，将单线程改为了多线程进行垃 圾回收，这样可以缩短垃圾回收的时间。（这里是指，并行能力较强的机器）
当然了，并行垃圾收集器在收集的过程中也会暂停应用程序，这个和串行垃圾回收器是 一样的，只是并行执行，速度更快些，暂停的时间更短一些

CMS垃圾收集器

CMS全称 Concurrent Mark Sweep，是一款并发的、使用标记-清除算法的垃圾回收器， 该回收器是针对老年代垃圾回收的，通过参数-XX:+UseConcMarkSweepGC进行设置

G1垃圾收集器（特别标注重点）

G1垃圾收集器是在jdk1.7中正式使用的全新的垃圾收集器，oracle官方计划在jdk9中将 G1变成默认的垃圾收集器，以替代CMS。

G1的设计原则就是简化JVM性能调优，开发人员只需要简单的三步即可完成调优：

1. 第一步，开启G1垃圾收集器 2. 第二步，设置堆的大内存 3. 第三步，设置大的停顿时间
   G1中提供了三种模式垃圾回收模式，Young GC、Mixed GC 和 Full GC，在不同的条件 下被触发

使用原理
G1垃圾收集器相对比其他收集器而言，大的区别在于它取消了年轻代、老年代的物理 划分，取而代之的是将堆划分为若干个区域（Region），这些区域中包含了有逻辑上的 年轻代、老年代区域。
这样做的好处就是，我们再也不用单独的空间对每个代进行设置了，不用担心每个代内 存是否足够。
在G1划分的区域中，年轻代的垃圾收集依然采用暂停所有应用线程的方式，将存活对象 拷贝到老年代或者Survivor空间，G1收集器通过将对象从一个区域复制到另外一个区 域，完成了清理工作。
这就意味着，在正常的处理过程中，G1完成了堆的压缩（至少是部分堆的压缩），这样 也就不会有cms内存碎片问题的存在了。 在G1中，有一种特殊的区域，叫Humongous区域。
如果一个对象占用的空间超过了分区容量50%以上，G1收集器就认为这是一个巨型 对象。 这些巨型对象，默认直接会被分配在老年代，但是如果它是一个短期存在的巨型对 象，就会对垃圾收集器造成负面影响。 为了解决这个问题，G1划分了一个Humongous区，它用来专门存放巨型对象。如果 一个H区装不下一个巨型对象，那么G1会寻找连续的H分区来存储。为了能找到连续 的H区，有时候不得不启动Full GC。

Young GC

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

Remembered Set（已记忆集合）

G1引进了RSet的概念。它的全称是Remembered Set，其作用是跟踪指向某个堆 内的对象引用
每个Region初始化时，会初始化一个RSet，该集合用来记录并跟踪其它Region指向该 Region中对象的引用，每个Region默认按照512Kb划分成多个Card，所以RSet需要记录 的东西应该是 xx Region的 xx Card

Mixed GC

当越来越多的对象晋升到老年代old region时，为了避免堆内存被耗尽，虚拟机会触发一 个混合的垃圾收集器，即Mixed GC，该算法并不是一个Old GC，除了回收整个Young Region，还会回收一部分的Old Region，这里需要注意：是一部分老年代，而不是全部 老年代，可以选择哪些old region进行收集，从而可以对垃圾回收的耗时时间进行控制。 也要注意的是Mixed GC 并不是 Full GC。
MixedGC什么时候触发？ 由参数 -XX:InitiatingHeapOccupancyPercent=n 决定。默 认：45%，该参数的意思是：当老年代大小占整个堆大小百分比达到该阀值时触发。 它的GC步骤分2步：

1. 全局并发标记（global concurrent marking）
2. 2. 拷贝存活对象（evacuation）

全局并发标记

全局并发标记，执行过程分为五个步骤：
初始标记（initial mark，STW） 标记从根节点直接可达的对象，这个阶段会执行一次年轻代GC，会产生全局停顿。
根区域扫描（root region scan） G1 GC 在初始标记的存活区扫描对老年代的引用，并标记被引用的对象。 该阶段与应用程序（非 STW）同时运行，并且只有完成该阶段后，才能开始下 一次 STW 年轻代垃圾回收。
并发标记（Concurrent Marking） G1 GC 在整个堆中查找可访问的（存活的）对象。该阶段与应用程序同时运行， 可以被 STW 年轻代垃圾回收中断。
重新标记（Remark，STW） 该阶段是 STW 回收，因为程序在运行，针对上一次的标记进行修正。
清除垃圾（Cleanup，STW） 清点和重置标记状态，该阶段会STW，这个阶段并不会实际上去做垃圾的收集， 等待evacuation阶段来回收。

拷贝存活对象

Evacuation阶段是全暂停的。该阶段把一部分Region里的活对象拷贝到另一部分Region 中，从而实现垃圾的回收清理

G1收集器相关参数

-XX:+UseG1GC
使用 G1 垃圾收集器
-XX:MaxGCPauseMillis
设置期望达到的大GC停顿时间指标（JVM会尽力实现，但不保证达到），默认 值是 200 毫秒。
-XX:G1HeapRegionSize=n
设置的 G1 区域的大小。值是 2 的幂，范围是 1 MB 到 32 MB 之间。目标是根 据小的 Java 堆大小划分出约 2048 个区域。 默认是堆内存的1/2000。 -XX:ParallelGCThreads=n
设置 STW 工作线程数的值。将 n 的值设置为逻辑处理器的数量。n 的值与逻辑 处理器的数量相同，多为 8。
-XX:ConcGCThreads=n
设置并行标记的线程数。将 n 设置为并行垃圾回收线程数 (ParallelGCThreads) 的 1/4 左右。
-XX:InitiatingHeapOccupancyPercent=n
设置触发标记周期的 Java 堆占用率阈值。默认占用率是整个 Java 堆的 45%

对于G1垃圾收集器优化建议

年轻代大小
避免使用 -Xmn 选项或 -XX:NewRatio 等其他相关选项显式设置年轻代大小。 固定年轻代的大小会覆盖暂停时间目标。
暂停时间目标不要太过严苛
G1 GC 的吞吐量目标是 90% 的应用程序时间和 10%的垃圾回收时间。 评估 G1 GC 的吞吐量时，暂停时间目标不要太严苛。目标太过严苛表示您愿意 承受更多的垃圾回收开销，而这会直接影响到吞吐量。