java中的垃圾回收机制简介

内存空间是有限的，运行时如果不能获取到内存，会抛出OutOfMemory，一种有效的解决措施是，抛弃那些程序永远不会不再用到的对象，腾出空间。

如何定义对象不会用到

1. 给对象添加一个引用计数器，每当这个对象被引用一次就加1，每当这个对象的引用失效1次，就减1，那么引用次数为0的就没有再用了，非0就代表还有用,但是引用计数器很难解决循环引用。 新建对象的引用计数为1，如果两个新建对象互相引用，那么他们的引用计数为2，此时如果只将原新对象置为null,只会各自使得引用计数减1，这种场景下得到的结果引用结果是1，因而仅靠这种粗略的检查并不能达到一个好的效果
2. 给对象的引用做追踪。可以定义一组集合，认定从这个集合出发，能够追溯到的所有对象，都是可用的，其余的都是不可用的 这种集合也称作 GC Roots,它定义一组根引用，包括当前所有正在被调用的方法的引用类型参数、局部变量、临时值；方法区中的常量引用对象;本地方法栈中的JNI等等

可引用对象的细分

干掉没有引用的对象，没什么问题，但是如果内存空间仍然不够，可以干掉部分虽然可用，但是不那么重要的对象来“确保大局”，java对此细分了强引用、软引用、弱引用、虚引用

详见reference 引用

常用的垃圾回收算法思想

1. 标记-清除。首先标记出需要清除的对象，然后再统一清除。
2. 复制算法。将一块内存分为两半，每次只用一半，当对使用的这块内存回收时，将可以用的对象复制到另一块内存上，然后一次性清除所有使用过的内存空间
3. 标记-整理。思想与标记-清除一致，只是在清除之前，会先把所有存活的对象都移向一端，然后清掉端边界外的内存
4. 分代思想。根据对象的存活周期将内存划分成几块，对不同的存活时间使用不同的垃圾回收算法

分代GC带来的好处

1. 大多数情况下，数据都会满足这么一个假设：大部分对象的存活时间很短，而其它的对象则有可能存活时间很长。在这一假设前提下划分为年轻代和老年代。配置年轻代占据堆中较小的一块，新创建的对象都在年轻代里面，GC时，由于大部分对象都会消亡，只会留下较小的部分，这样适合使用复制算法的思想来处理，这样的划分便降低了单次GC的时间长度(遍历的空间少)，同时提高了GC的效率（回收的多）。hotspot中年轻代被划分成8:1:1，这里其实就是认为90%的对象都会被回收，10%用来保留活下来的，这也就意味着复制算法每次只有10%的空间浪费
2. 为了更快的释放空间，一边能处理应用内存的分配。 并发GC的本质是GC一边搜集，应用一边产生，如果GC的速度跟不上产生的速度，那么垃圾就会组件堆积，最终应用分配请求只能停下来等GC追赶，因此越快释放出越多的空间，就能越好应付越高的应用分配内存的速率，从而让GC以完美的并发模式工作。

GC为什么要分代

什么时候可以回收

要做回收，首先得知道哪些对象是可达的(存活的)，而要知道可达性，对于对象引用追踪这种思想，就得要去遍历整个GC根集合。而要做到精准的枚举，就需要知道哪些栈的槽位有引用，哪些寄存器有引用，因而需要有一些位置去保存这些信息，而能够保存这些信息的地方即 安全点或者安全区域。

能够保存这些信息的地方必定也是知道引用情况的地方，这些地方也就可以执行GC

hotspot中的垃圾收集器

无论使用哪种收集器，在收集开始的时候都是从 safepoint开始

serial年轻代收集器

"古老"的收集器，使用单线程收集，它工作时必须暂停所有用户的线程，直到收集结束。对于年轻代的收集则使用复制算法。 可以用于Client模式下的虚拟机。

ParNew年轻代收集器

serial的多线程版本。多线程收集，它工作时必须暂停所有用户的线程，直到收集结束。对于年轻代的收集则使用复制算法。与CMS收集器配合工作,使用 -XX:UseConcMarkSweepGC的默认年轻代收集器

Parallel Scavenge年轻代收集器

多线程收集器。它的目标是提供一个可控的吞吐量：

与缩短停顿时间的收集器相比，它的目标是高效率的利用CPU的时间，尽快完成运算任务。另外它还支持自适应调节：比如年轻代大小、Eden和Survior的比例、晋升老年代的大小等，来达到最佳的吞吐量。适合后台运算而不需要太多交互的任务，不能配合CMS工作

缩短停顿时间的关注点则是在于提供良好的响应速度，从而提升用户体验

Serial老年代收集器

单线程收集。它需要暂停所有用户线程，直到收集结束。年老代使用标记-整理算法。它同样适用于Client模式下的虚拟机

如果是Server模式，在JDK1.5以及之前可以用来配合Parallel Scavenge搭配使用，以及作为CMS收集器的预备方案，在发生Concurrent Mode Failure时使用

Parallel 老年代收集器

多线程收集。它需要暂定所有用户线程，直到收集结束。使用标记整理算法，它也是以吞吐量优先，在JDK1.6中提供，用来配合Parallel Scavenge使用

CMS(Concurrent Mark Sweep) 老年代收集器

并发收集。它分为4个阶段：

• 初始标记：需要暂停用户线程。用于标记GC Roots能直接关联到的对象
• 并发标记：不需暂停用户线程。用于标记所有活着的对象
• 重新标记：需要暂停用户线程。修正因为用户线程运行而导致的标记变动的对象
• 并发清除：不需暂停用户线程。清除消亡的对象

它整体使用的是标记-清除 算法，系统停顿时间短，适用响应速度快，用户体验好

缺点：

1. 并发意味着它会占用CPU资源，吞吐量就低；
2. 由于清理的时候用户线程还在运行，那么用户线程也是需要空间的，如果空间不够，就产生Concurrent Mode Failure，转而使用Serial Old,另外用户运行也会不断的产生垃圾，这部分无法清除(浮动垃圾)， 因此有设置CMS触发的参数 -XX:CMSInitiatingOccupancyFraction
3. 标记-清除之后会产生碎片 可以通过 -XX:CMSCompactAtFullCollection设置是否要清理碎片，以及 -XX:CMSFullGCsBeforeCompaction来表示多此次运行不压缩的Full GC后来一次压缩

G1(Garbage-First)收集器

新生代和老年代都可以收集。大致步骤如下：

1. 初始标记：需要暂停用户线程。用于标记GC Roots能直接关联到的对象，以及实现G1算法相关的操作
2. 并发标记：不许需要暂停用户线程。用于标记活着的对象
3. 最终标记：需要停顿并行执行。用于修正因用户运行而导致的标记变更
4. 筛选回收：不需要暂停，并发执行。根据G1算法的细节进行回收价值和成本的排序，生成执行计划

与CMS相比优点：

• 空间整合：G1从整体上来讲是基于标记-整理算法，从局部来讲是基于“复制”算法实现，这意味着运行期间不会产生内存空间碎片
• 可预测的停顿：使用者可以指定在长度为M毫秒的时间片段内，消耗时间不超过N毫秒

JDK 7 引入

ZGC

并发垃圾收集器。几乎所有的阶段都是并发执行

ZGC仍然会压缩堆,压缩堆这件事，通常意味着

• 将或者的对象移到堆的一端
• 执行移动过程中需要暂停应用线程

压缩主要会遇到这么些问题

• 在搬运对象到另一个内存地址的时候，另一个线程也同时会对对象进行读和写
• 搬运成功后，其它有这个对象引用的也必须去跟新他们的引用地址

ZGC过程地址

JDK 11引入

垃圾收集器参数

• UseParNewGC：使用ParNew+Serial Old收集器
• UseConcMarkSweepGC:使用ParNew+CMS+Serial Old收集器
• UseParallelGC:使用Parallel Scavenge+Serial Old
• UseParallelOldGC:使用Parallel Scavenge+Parallel Old

运行调节的参数

• SurvivorRatio:Eden与Survivor的分配比例
• Newratio:年轻代和年老代的比值，比如4表示young:old=1:4
• PretenureSizeThreshold:直接晋升到老年代的对象大小
• MaxTenuringThreshold:晋升到老年代的年龄
• ParallelGCThreads:并行GC内存回收的线程数
• CMSCompactAtFullCollection:运行CMS后是否需要碎片整理
• CMSFullGCsBeforeCompaction：运行CMS若干次后再进行碎片整理
• CMSInitiatingOccupancyFraction:使用CMS，老年代空间使用多少后触发GC，默认68%

专业名词

名字讲解地址

Partial GC:不收集整个GC堆

• young GC:只收集年轻代
• Old GC:只收集年老代,限CMS的并行收集
• Mixed GC:收集年轻代和年老代，限G1

Full GC:收集整个堆，包括年轻代，年老代，永久带(如果有的话)

Minor GC一般指的是young GC;Major GC通常和Full GC等价,另外由于名词混用，也可能指的是Old GC

触发young gc的时候，如果发现之前young GC的平均大小比目前老年代的剩余空间大，则触发Full GC,永久带如果没有足够的空间，也会触发Full GC

注意: ParallelScavenge 则是在每次触发Full GC之前会先执行一次young gc，再执行full gc;

GC 文件

使用 jstat -gc pid time_interval count格式能够查看Java堆状况

• gcutil可以用来查询百分比
• gcnew/gcold分别查看年轻代和年老代的GC

结果如下

 S0C    S1C    S0U    S1U      EC       EU        OC         OU       MC     MU    CCSC   CCSU   YGC     YGCT    FGC    FGCT     GCT
16960.0 16960.0 5116.0  0.0   136064.0 93854.9   339724.0   271888.9  152936.0 149578.7 20444.0 19683.3    220    2.122  19      0.923    3.045
复制代码

• S0C、S1C、S0U、S1U：Survivor 0/1区容量（Capacity）和使用量（Used）
• EC、EU：Eden区容量和使用量
• OC、OU：年老代容量和使用量
• PC、PU：永久代容量和使用量
• YGC、YGT：年轻代GC次数和GC耗时
• FGC、FGCT：Full GC次数和Full GC耗时
• GCT：GC总耗时

使用 -XX:+PrintGCDetails 可以显示GC的情况，形如

[GC[ParNew: 6996K->1202K(78656K), 0.0036460 secs][CMS: 0K->1163K(174784K), 0.0311840 secs] 6996K->1163K(253440K), [CMS Perm : 3060K->3059K(21248K)], 0.0349020 secs] [Times: user=0.03 sys=0.02, real=0.03 secs] 
复制代码

• [GC 表明停顿的类型，有Full则表明发生了Full GC
• [ParNew 表示垃圾收集的区域与对应的GC收集器 ；其中 [ParNew 表明用的是ParNew收集器； [DefNew 表明使用的是Serial收集器；[PSYoungGen 表明使用的是 Parallel Scavenge收集器；[CMS 这种表示CMS收集器
• 6996K->1202K(78656K) 表示“GC前该区域已使用容量->GC后该区域已使用容量(该内存区域的总容量)”
• 0.0036460 secs 表示该内存区域GC所用的时间
• 6996K->1163K(253440K) (方括号外)的表示"GC前java堆已使用的容量->GC后Java堆使用的容量(Java堆总容量)"
• Times: user=0.03 sys=0.02, real=0.03 secs 分别表示用户态消耗的CPU时间、内核态的CPU时间和操作从开始到结束所经过的强钟时间 墙钟时间包含各种非运算的等待耗时，例如等待磁盘IO，CPU时间则不包含这些，但是多线程会叠加CPU的时间