JVM 垃圾收集器（Garbage Collection）

浅浅的花香味﹌ 2022-05-15 01:17 176阅读 0赞

# 判断对象是否存活 #

在堆里边存放着java世界中几乎所有的对象实例，垃圾收集器在对堆进行回收前，首先需要确定这些对象之中哪些还“存活”着，哪些已经“死去”（即不可能再被任何途径使用的对象）。

## 引用计数算法 ##

给对象添加一个引用计数器，每当有一个地方引用它时，计数器值就加1；当引用失效时，计数器值就减1；任何时刻计数器为0的对象就是不可能再被使用的。该方法简单，但也有一个缺点是很难解决对象之间相互循环引用的问题。

## 可达性分析算法 ##

该算法的基本思路就是通过一系列的称为“GCRoots”的对象作为起始点，从这些节点开始向下搜索，搜索所走过的路径称为引用链。当一个对象到GC Roots没有任何引用链相连时，则证明此对象是不可用的。在java语言中，可作为GC Roots的对象包括下面几种：

1.  虚拟机栈（栈帧中的本地变量表）中引用的对象；
2.  方法区中类静态属性引用的对象；
3.  方法区中常量引用的对象；
4.  本地方法栈中JNI（即一般说的native方法）引用的对象。

## 再谈引用 ##

引用分为强引用、软引用、弱引用和虚引用。

*  **强引用：**代码中明确指明的，如“Object a = new Object()”,只要强引用还在，就不会被GC
 *  **软引用：**被软应用关联对象第一次发生GC时可以躲过，第二次遇到GC时才会被回收
 *  **弱引用：**被弱引用关联的对象在发生GC时就会被回收
 *  **虚引用：**也称为幽灵引用，它是最弱的一种引用关系。一个对象是否有虚引用的存在，完全不会对其生存时间构成影响，也无法通过虚引用来取得一个对象实例。为一个对象设置虚引用关联的唯一目的就是能在这个对象呗垃圾收集器回收时受到一个系统通知。

## 生存还是死亡 ##

即使在可达性分析算法中不可达的对象，也并非是“非死不可”的。要真正宣告一个对象死亡，至少要经历两次标记过程：如果对象在进行可达性分析后发现没有与GC Roots相连接的引用链，那它将会被第一次标记并且进行一次筛选，筛选的条件是此对象是否有必要执行finalize()方法。当对象没有覆盖finalize()方法，或者finalize()方法已经被虚拟机调用过，虚拟机将这两种情况都视为“没有必要执行”。  
如果这个对象呗判定为有必要执行finalize()方法，那么这个对象将会放置在一个叫做F-Queue的队列中，并在稍后由一个由虚拟机自动建立的、低优先级的Finalizer线程去执行它。finalize()方法是对象逃脱死亡命运的最后一次机会，稍后GC将对F-Queue中的对象进行第二次小规模的标记，如果对象要再finalize()中成功拯救自己——只要重新与引用链上的任何一个对象建立关联即可，譬如把自己（this关键字）赋值给某个类变量或者对象的成员变量，那么在第二次标记时它将被移除出“即将回收”的集合。

## 回收方法区 ##

方法区（或者HotSpot虚拟机中的永久代）的垃圾收集主要回收两部分内容：废弃常量和无用的类。回收废弃常量与回收java堆中的对象非常相似。以常量池中字面量的回收为例，假设一个字符串”abc”已经进入了常量池中，但是当前系统没有任何一个String对象值为”abc”，换句话说，就是没有任何String对象引用常量池中的”abc”常量，也没有其他地方引用了这个字面量，如果这时发生内存回收，而且必要的话，这个”abc”常量就会被系统清理出常量池。常量池中的其他类（接口）、方法、字段的符号引用也与此类似。  
判定一个常量是否是“废弃常量”比较简单，而要判定一个类是否是“无用的类”的条件则相对苛刻的多，需要同时满足一下3个条件：

1.  该类所有的示例都已经被回收
2.  加载该类的ClassLoader已经被回收
3.  该类对应的Class对象没有在任何地方被引用，无法在任何地方通过反射访问该类的方法。

在大量使用发射、动态代理、CGLib等ByteCode框架、动态生成JSP以及OSGi这类频繁自定义ClassLoader的场景都需要虚拟机具备类卸载的功能，以保证永久代不会溢出。

# 垃圾收集算法 #

## 1. 标记-清除算法（Mark-Sweep）  ##

![6529cb146d19426496da51832b69e059.png][]

首先标记出所有需要回收的对象，在标记完成后统一回收所有被标记的对象。这种算法的主要不足有两个：一个是效率问题，标记和清楚两个过程的效率都不高；另一个是空间问题，标记清除之后会产生大量不连续的内存碎片，空间碎片太多会导致以后在程序运行过程中需要分配较大对象时，无法找到足够的连续内存而不得不提前出发另一次垃圾收集动作。

## 2. 复制算法（Copying） ##

![e7d36625e7e846e0863014a46f370e39.png][]

复制算法适用于新生代，因为在新生代，垃圾对象通常会多余存活对象，复制算法效果会比较好。为了解决效率问题，可以将内存按照容量划分为大小相等的两块，每次只使用其中的一块。当这块的内存用完了，就将还存活的对象复制到另一块上面，然后再把已使用过的内存空间一次清理掉。这种方法实现简单，运行高效，代价是将内存缩小为了原来的一半。  
为了提高内存的利用率，可以将内存分为一块较大的Eden空间和两块较小的Survivor空间，每次使用Eden和其中一块Survivor。当回收时，将Eden和Survivor中还存活着的对象一次性地复制到另外一块Survivor空间上，最后清理掉Eden和刚刚用过的Survivor空间。  
为什么需要有两块Survivor? 这是因为survivor中的对象在达到“老年”（由指定参数-XX:MaxTenuringThreshold决定）之前肯定有对象已经变成“垃圾”了，这时候必须要对其进行回收，如果只使用一个survivor的话，那么要不容忍survivor存在内存碎片，要么要对其进行内存整理，出于和对Eden区域同样的考虑，所以实际上对Survivor的GC也是基于复制算法的，不过是从一个Survivor到另外一个Survivor（这也是GC日志中为什么叫from space和to space），所以Survivor的两个区是对称的，没有先后关系，所以Survivor区中可能同时存在从Eden复制过来对象，以及从前一个Survivor复制过来的对象，某一次GC结束时肯定会有一个Survivor是空的。

## 3. 标记-整理算法（Mark-Compact） ##

![f0a92bddbf8648c6aa6ae9d38272ebfe.png][]

复制收集算法在对象存活率较高时就要进行较多的复制操作，效率将会变低。更关键的是，如果不想浪费50%的空间，就需要有额外的空间进行分配担保，以应对被使用的内存中所有对象都100%存活的极端情况，所以在老年代一般不能直接选用这种算法。  
根据老年代的特点，有人提出“标记-整理”算法，标记过程仍然与“标记-清除”算法中的一样，但后续步骤不是直接对可回收对象进行清理，而是让所有存活的对象都向一端移动，然后直接清理掉端边界以外的内存。

## 4. 分代收集算法 ##

一般把JVM的堆分为新生代和老年代，这样可以根据各个年代的特点采用最适当的收集算法。在新生代中，选用**复制算法**；而老年代中因为对象存活率高，没有额外空间对它进行分配担保，就采用**“标记-清理**”或者**“标记-整理”**算法来进行回收。

## 5. 分区收集算法 ##

分区收集算法是将整个堆空间划分为连续的不同小区间，每个小区间独立使用，独立回收，G1收集器就是使用该算法。

# HotSpot中垃圾收集算法的实现 #

## 枚举根节点 ##

在可达性分析中，从GC Roots节点找引用链这个操作为例，可作为GC Roots的节点主要在全局性的引用（例如常量或者类静态属性）与执行上下文（例如栈帧中的本地变量表）中，现在很多应用仅仅方法区就有数百兆，如果要逐个检查这里面的引用，那么必然会消耗很多时间。  
另外，可达性分析对执行时间的敏感还体现在GC停顿上，因为这项分析工作必须在一个能确保一致性的快照中进行——这里“一致性”的意思是指在整个分析起见整个执行系统看起来就像被冻结在某个时间点上，不可以出现分析过程中对象引用关系还在不断变化的情况，该点不满足的话分析结果准确性就无法得到保证。  
对于主流的Java虚拟机，当执行系统停顿下来后，并不需要一个不漏地检查完所有执行上下文和全局的引用位置，虚拟机应该是有办法直接得知哪些地方存放着对象引用。对于HotSpot，是使用了一组称为OopMap的数据结构来达到这个目的的，在类加载完成的时候，HotSpot就把对象内什么偏移量上是什么类型的数据计算出来，在JIT编译过程中，也会在特定的位置记录下栈和寄存器中哪些位置是引用。这样，GC在扫描时就可以直接得知这些信息了。

## 安全点 ##

在OopMap的协助下，HotSpot可以快速且准确地完成GC Roots枚举，但一个很现实的问题随之而来：可能导致引用关系变化，或者说OopMap内容变化的指令非常多，如果为每一条指令都生成对应的OopMap，那将会需要大量的额外空间，这样GC的空间成本将会变得很高。  
实际上，HotSpot只是在“特定的位置”记录了这些信息，这些位置成为安全点。即程序执行时并非在所有地方都能停顿下来开始GC，只有在到达安全点时才能暂停。安全点的选定既不能太少以至于让GC等待时间太长，也不能过于频繁以至于过分增大运行时的负荷。所以安全点的选择基本上是以程序“是否具有让程序长时间执行的特征”为标准。“长时间执行”的最明显特征就是指令序列复用，例如方法调用、循环跳转、异常跳转等。  
对于安全点，另一个需要考虑从的问题是如何在GC发生时让所有线程都“跑”到最近的安全点上再停顿下来。这里有两种方案：抢先式中断和主动式中断（使用较多）。抢先式中断是在GC发生时，首先把所有线程全部中断，如果发现有线程中断的地方不在安全点上，就恢复线程，让它跑到安全点上；而主动式中断的思想是当GC需要中断线程的时候，不直接对线程操作，仅仅简单地设置一个标志，各个线程执行时，主动去轮询这个标志，发现中断标志位真时就自己中断挂起。

## 安全区域 ##

安全点机制保证了程序执行时，在不太长的时间内就会遇到可进入GC的安全点。但是，程序“不执行”的时候呢？比如没有分配CPU时间，典型的例子就是线程处于Sleep或者Blocked状态，这时候线程无法响应JVM的中断请求，从而“走”到安全的地方去中断挂起，JVM也显然不太可能等待线程重新被分配CPU时间，对于这种情况，就需要安全区域来解决。  
安全区域是指一段代码片段之中，引用关系不会发生变化。在这个区域中的任何地方开始GC都是安全的。在线程执行到安全区域后，首先标识自己已经进入安全区域，当在这段时间里JVM要发起GC时，就不用管标识自己为安全区域状态的线程了。在线程要离开安全区域时，它要检查系统是否已经完成了根节点枚举（或者是整个GC过程），如果完成了，那线程就继续执行，否则它就必须等待知道收到可以安全离开安全区域的信号为止。

# 垃圾收集器 #

![70][]

## 串行收集器 ##

**新生代串行收集器Serial GC**是基于复制算法，实现简单，处理高效。**老年代串行收集器Serial Old GC**使用的是标记整理算法。Serial收集器是最简单的一个，是一个单线程的收集器，它在工作的时候会将所有应用线程全部冻结。  
如何使用它：你可以打开-XX:+UseSerialGC这个JVM参数来使用它。

![Center][]

与串行收集器相关的参数：  
\-XX:+UseSerialGC：在新生代和老年代使用串行收集器  
\-XX:SurvivorRatio：设置Eden区大小和Survivor区大小的比例；默认是8，即Eden:Survivor=8:1  
\-XX:PretenureSizeThreshold：设置大对象直接进入老年代的对象大小阈值。  
\-XX:MaxTenuringThreshold：设置对象进入老年代的年龄的最大值；默认是15岁，出生就已经是1岁了。

## 并行收集器 ##

### ParNew收集器 ###

**新生代ParNew收集器**ParNewGC是串行收集器的多线程版本

![Center 1][]

则老年代默认使用**SerialOldGC**收集器，老年代也可以修改成CMS

### Parallel Scavenge收集器 ###

新生代ParallelGC收集器也是使用复制算法，但它非常关注系统的吞吐量。  
老年代ParallelOldGC收集器也是一种关注吞吐量的收集器，使用标记-整理算法。  
所谓吞吐量就是CPU用于运行用户代码的时间与CPU总消耗时间的比值。吞吐量=运行用户代码时间/(运行用户代码时间+垃圾收集时间)。

与并行GC相关的参数：  
\-XX:+UseParNewGC：在新生代使用并行收集器；

\-XX:+UseParallelGC：设置并行新生代收集器（吞吐量优先）  
\-XX:+UseParallelOldGC：老年代使用并行收集器；  
\-XX:ParallelGCThreads：设置用于垃圾回收的线程数。通常和CPU数量相等；  
\-XX:MaxGCPauseMillis：设置最大垃圾收集停顿时间；  
\-XX:GCTimeRatio：设置吞吐量大小，0到100之间；默认是99，如99就代表：运行用户代码时间/(运行用户代码时间+垃圾收集时间)=99%

## CMS收集器 ##

CMS收集器（concurrent-mark-sweep）是一种以获取最短回收停顿时间为目标的收集器。其使用了多个线程（concurrent）来扫描堆并标记（mark）那些不再使用的可以回收(sweep)的对象。主要步骤有：初始标记、并发标记、预清理、重新标记、并发清除和并发重置。这个算法在两种情况下会进入一个”stop the world”的模式：当进行根对象的初始标记的时候 （老生代中线程入口点或静态变量可达的那些对象）以及当这个算法在并发运行的时候应用程序改变了堆的状态使得它不得不回去再次确认自己标记的对象都是正确的。

![Center 2][]

虽然称之为并发低停顿收集器，但是它有以下3个缺点：

1.  对CPU资源非常敏感，因为需要占用一部分线程资源。
2.  无法处理浮动垃圾，可能出现“Concurrent Mode Failure”失败而导致另一次Full GC的产生。
3.  因为是基于标记-清除算法的，所以收集结束时会有大量空间碎片产生。

## **G1回收器** ##

G1（ Garbage first）回收器在JDK 7update 4中首次引入，与其他收集器相比，G1具有以下特点：  
并行与并发：G1能充分利用多CPU、多核环境下的硬件优势，使用多个CPU或者CPU核心来缩短Stop-The-World停顿的时间；  
分代收集：与其他收集器一样，分代概念在G1中依然得以保留；  
空间整合：与CMS的“标记-清理”算法不同，G1从整体来看是基于“标记-整理”算法实现的收集器，从局部来看是基于“复制”算法实现的，两种算法都不会产生内存空间碎片；  
可预测的停顿：降低停顿时间是G1和CMS共同的关注点，但G1除了追求低停顿外，还能建立可预测的停顿时间模型，能让使用者明确指定在一个长度为M毫秒的时间片段内，消耗在垃圾收集的时间不得超过N毫秒。

![Center 3][]

G1算法将堆划分为若干个区域（Region），它仍然属于分代收集器。不过，这些区域的一部分包含新生代，新生代的垃圾收集依然采用暂停所有应用线程的方式，将存活对象拷贝到老年代或者Survivor空间。老年代也分成很多区域，G1收集器通过将对象从一个区域复制到另外一个区域，完成了清理工作。这就意味着，在正常的处理过程中，G1完成了堆的压缩（至少是部分堆的压缩），这样也就不会有cms内存碎片问题的存在了。

![20161222153407_471.png][]

在G1中，还有一种特殊的区域，叫Humongous区域。 如果一个对象占用的空间超过了分区容量50%以上，G1收集器就认为这是一个巨型对象。这些巨型对象，默认直接会被分配在年老代，但是如果它是一个短期存在的巨型对象，就会对垃圾收集器造成负面影响。为了解决这个问题，G1划分了一个Humongous区，它用来专门存放巨型对象。如果一个H区装不下一个巨型对象，那么G1会寻找连续的H分区来存储。为了能找到连续的H区，有时候不得不启动Full GC。

详细请看：[https://www.cnblogs.com/ASPNET2008/p/6496481.html][https_www.cnblogs.com_ASPNET2008_p_6496481.html]

[https://blog.csdn.net/j3T9Z7H/article/details/80074460][https_blog.csdn.net_j3T9Z7H_article_details_80074460]