【JVM】垃圾回收(GC)

GC全拼Garbage Collection

对象存活分析

Java虚拟机总共分为五个区域，其中三个是线程私有：程序计数器，虚拟机栈，本地方法栈，两个是线程共享：堆，方法区。线程私有的区域等到线程结束时（栈帧出栈时）会自动被释放，空间比较容易清理。而线程共享的java堆和方法区中的空间较大而且没有线程的回收容易产生很多垃圾信息，GC垃圾回收真正关心的就是这部分。

Java堆和方法区主要存放各种类型的对象（方法区中也存储一些静态变量和全局常量等信息），那么我们在使用GC对其进行回收的时候首先要考虑的就是如何判断一个对象是否应该被回收。也就是要判断一个对象是否还有其他的引用或关联使得这个对象处于存活的状态。我们需要将不在存活状态的所有对象标记出，以便于GC进行回收。

判断对象是否存活有两种比较常见的方法：引用计数法与可达性分析算法。

引用计数法

引用计数法的逻辑是：在堆中存储对象时，在对象头处维护一个counter计数器，如果一个对象增加了一个引用与之相连，则将counter++。如果一个引用关系失效则counter–。如果一个对象的counter变为0，则说明该对象已经被废弃，不处于存活状态。

引用计数法的逻辑非常简单，但是存在问题，java并不采用这种方式进行对象存活判断。

缺点：

1、不便区分多种引用的情况；

JDK从1.2开始增加了多种引用方式：软引用、弱引用、虚引用，且在不同引用情况下程序应进行不同的操作。如果我们只采用一个引用计数法来计数无法准确的区分这么多种引用的情况。

2、无法解决循环引用的情况。

如果一个对象A持有对象B，而对象B也持有一个对象A，那发生了类似操作系统中死锁的循环持有，这种情况下A与B的counter恒大于1，会使得GC永远无法回收这两个对象。

 

可达性分析算法

算法的基本思路就是通过一系列名为GC Roots的对象作为起始点，从这些节点开始向下搜索，搜索所走过的路径称为引用链(Reference Chain)，当一个对象到GC Roots没有任何引用链相连时，则证明此对象是不可用的。

在主流的商用程序语言中(Java和C#)，都是使用可达性分析算法判断对象是否存活的。

可以作为GC Roots对象的情况：

1. 1. 虚拟机栈(栈桢中的本地变量表)中的引用的对象（方法的局部变量）
   2. 方法区中的类静态属性引用的对象（类的静态变量）
   3. 方法区中的常量引用的对象
   4. 本地方法栈中JNI（Native方法）的引用的对象

 

对象迁入规则

对象的内存分配，从大方向上将，就是在堆上分配（但也可能经过JIT编译后被拆散为标量类型并间接地在栈上分配），对象主要分配在新生代的Eden区上，如果启动了本地线程分配缓冲，将按线程优先在TLAB上分配。少数情况也可能直接分配在老年代中，分配的规则并不是百分之百固定的，其细节取决于当前使用的是哪一种垃圾收集器组合，还有虚拟机中与内存相关的参数的设置。

一、对象优先分配在Eden区

二、大对象保存到老年代（优先保存在Eden区）

所谓大对象，就是指需要大量连续内存空间的Java对象，最典型的大对象就是那种很长的字符串及数组（byte[]数组就是典型的大对象）。大对象对虚拟机的内存分配来说就是一个坏消息（更加坏的情况就是遇到一群朝生夕死的短命大对象，写程序时应该避免），经常出现大对象容易导致内存还有不少空间时就提前触发垃圾收集以获取足够的连续空间来安置大对象。

虚拟机提供了一个-XX:PretenureSizeThreshold参数，令大于这个设置值的对象直接进入老年代中分配。这样避免在Eden区及两个Survivor区之间发生大量的内存拷贝。

大对象进入老年代遵循以下原则：

（1）新生代内存空间充足时，保存在新生代，遵循对象优先分配原则，保存在Eden区；

（2）新生代内存空间不足时，直接进入到老年代；

（3）当进行第一次GC时，无论内存是否充足，存活的大对象直接全部进入老年代；

为什么要优先保存在Eden？

试想一下，如果这个大的对象是朝生夕死的话，如果新生代足够充足的话，完全没有必要进入到老年代。

三、长期存活的对象将进入老年代

这里使用对象到达一定的年龄直接进入老年代更准确，对象默认年龄为15；我们可以通过修改参数-XX:MaxTenuringThreshold来设置。

四、动态对象年龄判定

为了能更好地适应不同程序的内存状况，虚拟机并不总是要求对象的年龄必须达到MaxTenuringThreshold才能晋升到老年代，如果在Survivor空间中相同年龄所有对象大小的综合大于Survivor空间的一半，年龄大于或等于该年龄的对象就可以直接进入老年代，无须等到MaxTenuringThreshold中要求的年龄。

这个实际这个规则运行的时候是如下的逻辑：年龄1+年龄2+年龄n的多个年龄对象总和超过了Survivor区域的50%，此时就会把年龄n以上的对象都放入老年代。

五、空间分配担保

当发生Minor GC时，虚拟机会检测之前每次晋升到老年代的平均大小是否大于老年代的剩余空间大小，如果大于，则改为直接进行一次Full GC。如果小于，则查看HandlePromotionFailure设置是否允许担保失败；如果允许，那只会进行Minor GC；如果不允许，则也要改为进行一次Full GC。

注：在JDK1.6需要手动设置空间分配担保，之后则默认开启空间分配担保。

新生代使用复制收集算法，但为了内存利用率，值使用其中一个Survivor空间来作为轮换备份，因此当出现大量对象在Minor GC后仍然存活的情况时（最极端就是内存回收后新生代中所有对象都存活），就需要老年代进行分配担保，让Survivor无法容纳的对象直接进入老年代。与生活中的贷款担保类似，老年代要进行这样的担保，前提是老年代本身还有容纳这些对象的剩余空间，一共有多少对象会活下去，在实际完成内存回收之前是无法明确知道的，所以只好取之前每一次回收晋升到老年代对象容量的平均大小值作为经验，与老年代的剩余空间进行对比，决定是否进行Full GC来让老年代腾出更多空间。

取平均值进行比较其实仍然是一种动态概率的手段，也就是说如果某次Minor GC存活后的对象突增，远远高于平均值时，依然会导致担保失败（Handle Promotion Failure）。如果出现HandlePromotionFailure失败，那就只好在失败后重新发起一次Full GC。虽然担保失败时绕的圈子是最大的，但大部分情况下都还是会将HandlePromotionFailure开关打开，避免Full GC过于频繁。

 

垃圾收集算法

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

“标记-清除”（Mark-Sweep）算法，如它的名字一样，算法分为“标记”和“清除”两个阶段：首先标记出所有需要回收的对象，在标记完成后统一回收掉所有被标记的对象。之所以说它是最基础的收集算法，是因为后续的收集算法都是基于这种思路并对其缺点进行改进而得到的。

它的主要缺点有两个：一个是效率问题，标记和清除过程的效率都不高；另外一个是空间问题，标记清除之后会产生大量不连续的内存碎片，空间碎片太多可能会导致，当程序在以后的运行过程中需要分配较大对象时无法找到足够的连续内存而不得不提前触发另一次垃圾收集动作。

 

复制算法（Copying）

“复制”（Copying）的收集算法，它将可用内存按容量划分为大小相等的两块，每次只使用其中的一块。当这一块的内存用完了，就将还存活着的对象复制到另外一块上面，然后再把已使用过的内存空间一次清理掉。

优点是每次都是对其中的一块进行内存回收，内存分配时就不用考虑内存碎片等复杂情况，只要移动堆顶指针，按顺序分配内存即可，实现简单，运行高效。缺点是将内存缩小为原来的一半，代价太高了一点。

 

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

老年代采用的算法。

     复制收集算法在对象存活率较高时就需要执行较多的复制操作，效率将会变低。更关键的是，如果不想浪费50%的空间，就需要有额外的空间进行分配担保，以应对被使用的内存中所有对象都100%存活的极端情况，所以在老年代一般不能直接选用复制收集算法。

    根据老年代的特点提出了“标记-整理”算法，标记过程仍然与“标记-清除”算法一样，但后续步骤不是直接对可回收对象进行清理，而是让所有存活的对象都向一端移动，然后直接清理掉端边界以外的内存。

 标记-整理的步骤：

标记阶段

整理阶段：移动存活对象，同时更新存活对象中所有指向被移动对象的指针

 

分代收集算法（Generational Collection）

     当前商业虚拟机的垃圾收集都采用“分代收集”算法，这种算法并无新的方法，只是根据对象的存活周期的不同将内存划分为几块，一般是把Java堆分为新生代和老年代，这样就可以根据各个年代的特点采用最适当的收集算法。在新生代中，每次垃圾收集时都发现有大批对象死去，只有少量存活，那就选用复制算法，只需要付出少量存活对象的复制成本就可以完成收集。而老年代中因为对象存活率高、没有额外空间对它进行分配担保，就必须使用“标记-清理”或“标记-整理”算法来进行回收。

 

垃圾收集器

如果说收集算法是内存回收的方法论，垃圾收集器就是内存回收的具体实现。下图展示了7种不同分代的收集器，如果两个收集器之间存在连线，就说明他们可以搭配使用。并没有最好的收集器这一说，我们需要选择的是对具体应用最合适的收集器。

 

Serial

适用于新生代。

单线程，在进行垃圾收集时必须暂停其他所有的工作线程（"Stop the World"）。虚拟机运行在Client模式下的默认新生代收集器。简单而高效（与其他收集器的单线程比），对于限定单个CPU的环境来说，Serial收集器由于没有线程交互的开销，专心做垃圾收集自然可以获得最高的单线程效率。

 

ParNew

适用于新生代。

ParNew收集器其实是Serial收集器的多线程版本，它是许多运行在Server模式下的虚拟机中首选的新生代收集器，因为除了Serial收集器外，目前只有它能与CMS收集器配合工作。

 

Parallel Scavenge

适用于新生代。

      “吞吐量优先”收集器，使用复制算法，并行多线程，这些特点与ParNew一样，它的独特之处是它的关注点与其他收集器不同，CMS等收集器的关注点是尽可能缩短垃圾收集时用户线程的停顿时间，而Parallel Scavenge收集器的目的则是达到一个可控制的吞吐量（Throughput）,即CPU用于运行用户代码的时间与CPU总消耗时间的比值，吞吐量=运行用户代码时间 /（运行用户代码时间+垃圾收集时间），虚拟机总共运行了100分钟，其中垃圾收集花掉1分钟，吞吐量就是99%。

      停顿时间越短对于需要与用户交互的程序来说越好，良好的响应速度能提升用户的体验；

      高吞吐量可以最高效率地利用CPU时间，尽快地完成程序的运算任务，主要适合在后台运算而不太需要太多交互的任务。

参数设置：

-XX:MaxGCPauseMillis 控制最大垃圾收集停顿时间。（大于0的毫秒数）停顿时间缩短是以牺牲吞吐量和新生代空间换取的。（新生代调的小，吞吐量跟着小，垃圾收集时间就短，停顿就小）。

-XX:GCTimeRatio 直接设置吞吐量大小，0<x<100 的整数，允许的最大GC时间=1/(1+x)。

-XX:+UseAdaptiveSizePolicy  一个开关参数，开启GC自适应调节策略（GC Ergonomics）,将内存管理的调优任务（新生代大小-Xmn、Eden与Survivor区的比例-XX:SurvivorRatio、晋升老年代对象年龄-XX: PretenureSizeThreshold 、等细节参数）交给虚拟机完成。这是Parallel Scavenge收集器与ParNew收集器的一个重要区别，另一个是吞吐量。

 

Serial Old

适用于老年代。

它是Serial收集器的老年代版本，单线程，使用“标记-整理”算法。主要是在Client模式下的虚拟机使用。如果在Server模式下，它还有两大用途：在JDK1.5及之前的版本中与Parallel Scavenge收集器搭配使用；作为CMS 收集器的后备预案，在并发收集发生Concurrent Mode Failure的时候使用。运行过程同Serial收集器。

 

Parallel Old

适用于老年代。

它是Parallel Scavenge收集器的老年代版本，多线程，使用“标记-整理”算法。在注重吞吐量及CPU资源敏感的场合，都可以优先考虑Parallel Scavenge+Parallel Old收集器。

 

CMS

适用于老年代。

全拼为：Concurrent Mark Sweep。它是一种以获取最短回收停顿时间为目标的收集器。

优点：并发收集，低停顿。基于“标记-清除”算法。目前很大一部分Java应用都集中在互联网站或B/S系统的服务端上，这类应用尤其重视服务的响应速度，希望系统停顿时间最短，以给用户带来较好的体验，CMS收集器就非常符合这类应用的需求。

运作过程较复杂，分为4个步骤：

初始标记（CMS initial mark）:需要“Stop The World”，标记GC Roots能直接关联到的对象，速度快。

并发标记（CMS concurrent mark）：进行GC Roots Tracing 过程

重新标记（CMS remark）：需要“Stop The World”,修正并发标记期间，因用户程序继续运行而导致标记产生变动的那一部分对象的标记记录。停顿时间：初始标记<重新标记<<并发标记

并发清除（CMS concurrent sweep）：时间较长。

缺点：

对CPU资源非常敏感，面向并发设计的程序都会对CPU资源较敏感。CMS默认的回收线程数: （CPU数量+3）/4

无法处理浮动垃圾，可能出现“Concurrent Mode Failure”失败而导致另一次Full GC的产生。并发清理阶段用户程序运行产生的垃圾过了标记阶段所以无法在本次收集中清理掉，称为浮动垃圾。CMS收集器默认在老年代使用了68%的空间后被激活。若老年代增长的不是很快，可以适当调高参数-XX:CMSInitiatingOccupancyFraction  提高触发百分比，但调得太高会容易导致“Concurrent Mode Failure”失败。

基于“标记-清除”算法会产生大量空间碎片。提供开关参数

-XX:+UseCMSCompactAtFullCollection 用于在“ 享受”完Full GC服务之后进行碎片整理过程，内存整理的过程是无法并发的。但是停顿时间会变长。

 

G1

Garbage First

它是当前收集器技术发展的最前沿成果。与CMS相比有两个显著改进：

• 基于“标记-整理”算法实现收集器,不会产生内存空间碎片
• 非常精确地控制停顿

G1收集器可以在几乎不牺牲吞吐量的前提下完成低停顿的内存回收，这是由于它能够极力避免全区域的垃圾收集，之前的收集器进行收集的范围都是整个新生代或老年代，而G1将整个Java堆（包括新生代、老年代）划分为多个大小固定的独立区域（Region），并且跟踪这些区域里面的垃圾堆积程度，在后台维护一个优先列表，每次根据允许的收集时间，优先回收垃圾最多的区域（这就是Garbage First名称的由来）。区域划分、有优先级的区域回收，保证了G1收集器在有限的时间内可以获得最高的收集效率。