[JVM知识点梳理]JVM之垃圾回收机制

垃圾收集器在对堆进行回收前，需要先确定这些对象中哪些还“存活”着，哪些已经“死去”(也就是不被任何引用类型所引用)。

基于这个目前有两种算法可判断对象是否存活

• 引用计数算法
• 可达性分析算法

引用计数算法

给对象添加一个引用计数器，每当有一个地方引用它时，计数器就加1；当引用失效时，计数器就减1；任何时刻计数器为0的对象就是不可能再被使用的。

优点：

• 实现简单
• 判断效率高

缺点：

• 很难解决对象之间相互循环引用的问题

可达性分析算法

通过一系列的称为“GC Roots”的对象作为起始点，从这些节点开始向下搜索，搜索所走过的路径称为引用链，当一个对象到GC Roots没有任何引用链相连时，则证明此对象是不可用的。

可作为GC Roots的对象包括下面几种

• 虚拟机栈(栈帧中的本地变量表)中引用的对象
• 方法区中类静态属性引用的对象
• 方法区中常量引用的对象
• 本地方法栈中JNI(即一般说的Native方法)引用的对象

引用

• 强引用

  在程序中普遍存在，类似Object obj = new Object()这类的引用，只要强引用还在，垃圾收集器永远不会回收掉被引用的对象

• 软引用

  用来描述一些还有用但并非必需的对象。对于软引用关联着的对象，在系统将要发生内存溢出异常之前，将会把这些对象列进回收范围之中进行第二次回。如果这次回收还没有足够的内存，才会抛出内存溢出异常。在JDK1.2之后，提供了SoftReference类来实现软引用。

• 弱引用

  用来描述非必须对象，但它的强度比软引用更弱一些，被弱引用关联的对象只能生存到下一次垃圾收集发生之前。当垃圾收集器工作时，无论当前内存是否足够，都会回收掉只被弱引用关联的对象。在JDK1.2之后，提供了WeakReference类来实现弱引用。

• 虚引用

  它是最弱的一种引用关系。一个对象是否有虚引用的存在，完全不会对其生存时间构成影响，也无法通过虚引用来取得一个对象实例。为一个对象设置虚引用关联的唯一目的就是能在这个对象被收集器回收时收到一个系统通知。在JDK1.2之后，提供了PhantomReference类来实现虚引用。

生存还是死亡

即使在可达性分析算法中不可达的对象，也并非是“非死不可”的，这时候它们暂时处于“缓刑”阶段，要真正宣告一个对象死亡，至少要经历两次标记过程：

• 如果对象在进行可达性分析后发现没有与GC Roots相连接的引用链，拿它将会被第一次标记并且进行一次筛选，筛选的条件是此对象是否有必要执行finalize()方法。当对象没有覆盖finalize()方法，或者finalize()方法已经被虚引用调用过，虚引用将这两种情况都视为“没有必要执行”。
• 如果此对象被判定为有必要执行finalize()方法，那么这个对象将会放置在一个叫做F-Queue的队列中，并在稍后由一个虚拟机自动建立的，但并不承若会等待它运行结束
• 这样做的原因是，如果一个对象在finalize()方法中执行缓慢，或者发生了死循环，将会很有可能会导致F-Queue队列中其他对象永久处于等待，甚至导致整个内存回收系统崩溃。finalize()方法是对象逃脱死亡命运的最后一次机会，稍后GC将对F-Queue中的对象进行第二次小规模的标记，例如把自己(this关键字)赋值给某个类变量或者对象的成员变量，那在第二次标记时它将被移除出“即将回收”的集合；如果对象这个时候还没有逃脱，拿基本上它就真的被回收了

垃圾收集算法

标记 - 清除算法

定义

• 最基础的收集算法，算法分为“标记”和“清除”两个阶段
• 首先标记出所有需要回收的对象，在标记完成后统一回收掉所有被标记的对象

缺点

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

复制算法

定义

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

优点

• 每次对其中的一块进行内存回收，内存分配时不用考虑内存碎片等复杂情况，只要移动堆顶指针，按顺序分配内存即可
• 实现简单，运行高效

缺点

• 将内存缩小为原来的一半，付出的代价太高

现在的商业虚拟机都采用这种收集算法来回收新生代，新生代的对象98%是朝生夕死的，所以并不需要按照1 : 1的比例来划分内存空间，而是将内存分为一块较大的Eden和两块较小的Survivor空间，每次使用Eden和其中的一块Survivor。当回收时，将Eden和Survivor中还存活着的对象一次性的拷贝到另外一块Survivor空间上，最后清理掉Eden和刚才用过的Survivor的空间。Hotspot虚拟机默认Eden和Survivor的大小比例是8 : 1。

标记-整理算法

定义

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

分代收集算法

定义

• 根据对象存活周期的不同将内存划分为几块

• 将Java堆分为新生代和老年代，根据各个年代的特点采用最适合的收集算法

  新生代：每次垃圾收集时都发现有大批对象死去，只有少量存活，那就选用复制算法；

  老年代：对象存活率高、没有额外空间对它进行分配担保，就必须使用“标记-清理”或“标记-整理”算法来回收

垃圾收集器

如下图展示了7中不同分代的收集器，如果两个收集器之间存在连线，就说明它们可以搭配使用。

Serial 收集器

• 最基本、历史最悠久的收集器，在JDK1.3之前是虚拟机新生代收集的唯一选择

• 它是单线程收集器，使用一个CPU或一条线程去完成垃圾收集工作，并且在它进行垃圾收集时，必须暂停其他所有的工作线程，直到它收集结束。

  

特点

• 简单而高效，对于限定单个CPU的环境来说，Serial收集器由于没有线程交互的开销，专心做垃圾shou'ji自然可以获得最高的单线程收集效率

• 在进行垃圾收集时，必须暂停其他所有的工作线程

• 它用于桌面应用，分配给虚拟机管理的内存一般不会太大。收集几十兆甚至一两百兆的新生代，停顿时间完全可以控制在几十毫秒最多一百多毫秒以内，只要不频繁发生，这点停顿是可以接受的。Serial收集器对于运行在Client模式下的虚拟机来说是一个很好的选择

ParNew收集器

• 它是Serial收集器的多线程版本

• 除了使用多线程进行垃圾收集以外，其余行为包括Serial收集器可用的所有控制参数(例如：-XX:SurvivorRatio、-XX:PretenureSizeThreshold、-XX:HandlePromotionFailure等)、收集算法、Stop The World、对象分配规则、回收策略等都与Serial收集器完全一样，实际上这两种收集器也共用了相当多的代码

  

• 它默认开启的收集线程数与CPU的数量相同，在CPU非常多(譬如32个)的环境下，可以使用-XX:ParallelGCThreads参数来限制垃圾收集的线程数

特点

• 在多CPU的环境下，它对于GC时系统资源的利用很有好处

• 除了Serial收集器外，目前只有它能与CMS收集器(这款收集器是HotSpot虚拟机中第一款真正意义上的并发收集器)配合工作

• 在单CPU环境下不会有比Serial收集器更好的效果，甚至由于多线程交互的开销，该收集器在通过超线程技术实现的两个CPU的环境中都不能百分之百地保证超越Serial收集器

• 它是许多运行在Server模式下的虚拟机中首选的新生代收集器

Parallel Scavenge收集器

• 新生代收集器
• 使用复制算法
• 并行的多线程收集器

特点

• 该收集器目标则是达到一个可控制的吞吐量(所谓吞吐量就是CPU用户运行用户代码的时间与CPU总消耗时间的比值，即吞吐量 = 运行用户代码时间 / （运行用户代码时间 + 垃圾收集时间）)，虚拟机总共运行了100分钟，其中垃圾收集花掉1分钟，那吞吐量就是99%。

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

• 提供两个参数来控制吞吐量，分别是控制最大垃圾收集停顿时间的-XX:MaxGCPauseMillis参数及直接设置吞吐量大小的-XX:GCTimeRatio参数

• 打开-XX:+UseAdaptiveSizePolicy参数，就不需要手工指定新生代的大小(-Xmn)、Eden与Survivor区的比例、晋升老年代对象年龄(-XX:PretenureSizeThreshold)等细节参数了，虚拟机会根据当前系统的运行情况收集性能监控信息，动态调整这些参数以提供最合适的停顿时间或最大的吞吐量，这种调节方式称为GC自适应的调节策略

Serial Old收集器

• 它是Serial收集器的老年代版本
• 单线程收集器
• 使用“标记-整理”算法

特点

• 它也是被Client模式下的虚拟机使用

• 如果在Server模式下，它还有两大用途：一个是在JDK1.5及之前的版本中与Paralle Scavenge收集器搭配使用；另一个就是作为CMS收集器的后备方案，在并发收集发生Concurrent Mode Failure的时候使用

  image.png

Parallel Old收集器

• 它是Parallel Scavenge收集器的老年代版本
• 多线程收集器
• 使用“标记整理”

特点

• 在注重吞吐量及CPU资源敏感的场合，可以优先考虑Parallel Scavenge加Parallel Old收集器

CMS收集器

• 是一种以获取最短回收停顿时间为目标的收集器
• 多线程收集器
• 使用“标记-清除”算法

特点

它的运作过程相对复杂，整个过程分为4个步骤，包括：

• 初始标记
• 并发标记
• 重新标记
• 并发清除

其中初始标记、重新标记这两个步骤仍然需要“Stop The World”。初始标记仅仅只是标记一下GC Roots能直接关联到的对象，速度很快，并发标记阶段就是进行GC Roots Tracing的过程，而重新标记阶段则是为了修正并发标记期间，因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录

由于整个过程中耗时最长的并发标记和并发清除过程中，收集器线程都可以与用户线程一起工作，所以总体上来说，CMG收集器的内存回收过程是与用户一起并发地执行的，如下图可以比较清楚地看到CMS收集器的运作步骤中并发和需要停顿的时间

image.png

它的主要优点

• 并发收集、低停顿
• 在Sun的一些官方文档被称为并发低停顿收集器

它有三个显著的缺点

• CMS收集器对CPU资源非常敏感，在并发阶段，它虽然不会导致用户线程停顿，但是会因为占用了一部分线程(或者说CPU资源)而导致应用程序变慢，总吞吐量会降低
• CMS收集器无法处理浮动垃圾，可能出现“Concurrent Mode Failure”失败而导致另一次Full GC的产生。由于CMS并发清理阶段用户线程还在运行着，CMS无法在本次收集中处理掉它们，只好留待下一次GC时再将其清理掉。这一部分垃圾就称为“浮动垃圾”。要是CMS运行期间预留的内存无法满足程序需要，j就会出现一次“Concurrent Mode Failure”失败，这个时候虚拟机将启动后备方案：临时启用Serial Old收集器来重新进行老年代的垃圾收集
• CMS是一款基于“标记-清除”算法实现的收集器，收集时会产生大量空间碎片。

G1收集器

G1收集器是垃圾收集器理论进一步发展的产物，它与前面的CMS收集器相比有两个显著的改进：

• 基于“标记-整理”算法实现的收集器，也就是说它不会产生空间碎片
• 它可以非常精确地控制停顿，既能让使用者明确指定在一个长度为M毫秒的时间片段内，消耗在垃圾收集上的时间不得超过N毫秒，着几乎是实时Java的垃圾收集器的特征了

G1将整个Java堆(包括新生代、老年代)划分为多个大小固定的独立区域，并且跟踪这些区域里面的垃圾堆积程度，在后台维护一个优先列表，每次根据允许的收集时间，优先回收垃圾最多的区域。区域划分及有优先级的区域回收，保证了G1收集器在有限的时间内可以获得最高的收集效率。

内存回收策略

对象分配规则

对象优先在Eden区分配。

大多数情况下，对象在新生代Eden区中分配。当Eden区没有足够的空间进行分配时，虚拟机将发起一次Minor GC

大对象直接进入老年代

• 这里的大对象指得是需要连续内存空间的Java对象，最典型的大对象就是那种很长的字符串及数组。大对象对虚拟机的内存分配来说就是一个坏消息，经常出现大对象容易导致内存还有不少空间时就提前触发垃圾收集以获取足够的连续空间来“安置”它们。
• 虚拟机提供了一个-XX:PretenureSizeThreshold参数，令大于这个设置值的对象直接在老年代分配。这样做的目的是避免在Eden区及两个Survivor区之间发生大量的内存拷贝(新生代采用复制算法收集内存)

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

虚拟机给每个对象定义了一个对象年龄计数器。如果对象在Eden出生并经过第一次Minor GC后仍然存活，并且能被Survivor容纳的话，将被移动到Survivor空间中，并将年龄设为1。对象在Survivor区中每熬过一次Minor GC,年龄就增加1岁，当它的年龄增加到一定程度(默认为15岁)时，就会被晋升到老年代中。对象晋升老年代的年龄阈值，可以通过参数-XX:MaxTenuringThreshod来设置

动态对象年龄判定

如果在Survivor空间中相同年龄所有对象大小的总和大于Survivor空间的一半，年龄大于或等于该年龄的对象就可以直接进入老年代，无须等到MaxTenuringThreshold中要求的年龄。

空间分配担保

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

注意

• 新生代GC(Minor GC): 指发生在新生代的垃圾收集动作，因为Java对象大多都具备朝生夕灭的特性。所以Minor GC 非常频繁，一般回收速度也比较快。
• 老年代GC(MajorGC/Full GC):
  指发生在老年代的GC，出现了Major GC，经常会伴随着至少一次的Minor GC（但非绝对的，在ParalleScavenge收集器的收集策略里就有直接进行Major GC的策略选择过程）。MajorGC的速度一般会比Minor GC慢10倍以上