GC和垃圾收集器

迈不过友情╰ 2022-05-10 02:08 225阅读 0赞

# Java —— GC #

标签（空格分隔）： Java

--------------------

要想深入了解Java的GC(Garbage Collection)，我们应该先探寻如下三个问题：

*  What? -- 哪些内存需要回收？
 *  When? -- 什么时候回收？
 *  How? -- 如何回收？

## GC Definition ##

Definition: Program itself finds and collects memory which is useless. It is a form of automatic memory management which doesn't need programmers release memory.  
Java中为什么会有GC机制呢？

*  安全性考虑；-- for security.
 *  减少内存泄露；-- erase memory leak in some degree.
 *  减少程序员工作量。-- Programmers don't worry about memory releasing.

## What? -- 哪些内存需要回收？ ##

我们知道，内存运行时JVM会有一个运行时数据区来管理内存。它主要包括5大部分：**程序计数器(Program Counter Register)、虚拟机栈(VM Stack)、本地方法栈(Native Method Stack)、方法区(Method Area)、堆(Heap)**.

而其中**程序计数器、虚拟机栈、本地方法栈**是每个线程私有的内存空间，随线程而生，随线程而亡。例如栈中每一个栈帧中分配多少内存基本上在类结构去诶是哪个下来时就已知了，因此这3个区域的内存分配和回收都是确定的，无需考虑内存回收的问题。

但**方法区和堆**就不同了，一个接口的多个实现类需要的内存可能不一样，我们只有在程序运行期间才会知道会创建哪些对象，这部分内存的分配和回收都是动态的，GC主要关注的是这部分内存。

> 总而言之，GC主要进行回收的内存是JVM中的**方法区**和**堆**；  
> 涉及到**多线程(指堆)、多个对该对象不同类型的引用(指方法区)**，才会涉及GC的回收。

## When? -- 什么时候回收？ ##

### 堆 ###

在面试中经常会碰到这样一个问题（事实上笔者也碰到过）：**如何判断一个对象已经死去？**

很容易想到的一个答案是：对一个对象添加**引用计数器**。每当有地方引用它时，计数器值加1；当引用失效时，计数器值减1.而当计数器的值为0时这个对象就不会再被使用，判断为已死。是不是简单又直观。然而，很遗憾。这种做法是**错误**的！（面试时可千万别这样回答哦，我就是不假思索这样回答，然后就。。）为什么是错的呢？事实上，用引用计数法确实在大部分情况下是一个不错的解决方案，而在实际的应用中也有不少案例，但它却无法解决对象之间的**循环引用**问题。比如对象A中有一个字段指向了对象B，而对象B中也有一个字段指向了对象A，而事实上他们俩都不再使用，但计数器的值永远都不可能为0，也就不会被回收，然后就发生了内存泄露。。

所以，正确的做法应该是怎样呢？  
在Java，C\#等语言中，比较主流的判定一个对象已死的方法是：**可达性分析(Reachability Analysis).**  
所有生成的对象都是一个称为"GC Roots"的根的子树。从GC Roots开始向下搜索，搜索所经过的路径称为引用链(Reference Chain)，当一个对象到GC Roots没有任何引用链可以到达时，就称这个对象是不可达的（不可引用的），也就是可以被GC回收了。如下图所示：

\[可达性算法判定对象是否可回收\]\[1\]  
![731104-20160624112838750-212547580.png][]

> 无论是引用计数器还是可达性分析，判定对象是否存活都与引用有关！那么，如何定义对象的引用呢？

我们希望给出这样一类描述：当内存空间还够时，能够保存在内存中；如果进行了垃圾回收之后内存空间仍旧非常紧张，则可以抛弃这些对象。所以根据不同的需求，给出如下四种引用，根据引用类型的不同，GC回收时也会有不同的操作：

*  强引用(Strong Reference):Object obj = new Object();只要强引用还存在，GC永远不会回收掉被引用的对象。
 *  软引用(Soft Reference)：描述一些还有用但非必需的对象。在系统将会发生内存溢出之前，会把这些对象列入回收范围进行二次回收（即系统将会发生内存溢出了，才会对他们进行回收。）
 *  弱引用(Weak Reference):程度比软引用还要弱一些。这些对象只能生存到下次GC之前。当GC工作时，无论内存是否足够都会将其回收（即只要进行GC，就会对他们进行回收。）
 *  虚引用(Phantom Reference):一个对象是否存在虚引用，完全不会对其生存时间构成影响。

### 方法区 ###

> What部分我们已经提到，GC主要回收的是**堆和方法区**中的内存，而上面的How主要是针对对象的回收，他们一般位于堆内。那么，**方法区**中的东西该怎么回收呢？

关于方法区中需要回收的是一些**废弃的常量**和**无用的类**。

1.  废弃的常量的回收。这里看引用计数就可以了。没有对象引用该常量就可以放心的回收了。
2.  无用的类的回收。什么是无用的类呢？

*  该类所有的实例都已经被回收。也就是Java堆中不存在该类的任何实例；
 *  加载该类的ClassLoader已经被回收；
 *  该类对应的java.lang.Class对象没有任何地方被引用，无法在任何地方通过反射访问该类的方法。

> 总而言之，对于**堆中的对象**，主要用可达性分析判断一个对象是否还存在引用，如果该对象没有任何引用就应该被回收。而根据我们实际对引用的不同需求，又分成了4中引用，每种引用的回收机制也是不同的。  
> 对于**方法区中的常量和类**，当一个常量没有任何对象引用它，它就可以被回收了。而对于类，如果可以判定它为无用类，就可以被回收了。

## How? -- 如何回收？ ##

### 标记-清除(Mark-Sweep)算法 ###

分为两个阶段：首先标记出所有需要回收的对象，在标记完成后统一回收所有被标记的对象。  
缺点：效率问题，标记和清除两个过程的效率都不高；空间问题，会产生很多碎片。

### 复制算法 ###

将可用内存按容量划分为大小相等的两块，每次只用其中一块。当这一块用完了，就将还存活的对象复制到另外一块上面，然后把原始空间全部回收。高效、简单。  
缺点：将内存缩小为原来的一半。

### 标记-整理(Mark-Compat)算法 ###

标记过程与标记-清除算法过程一样，但后面不是简单的清除，而是让所有存活的对象都向一端移动，然后直接清除掉端边界以外的内存。

### 分代收集(Generational Collection)算法 ###

*  新生代中，每次垃圾收集时都有大批对象死去，只有少量存活，就选用复制算法，只需要付出少量存活对象的复制成本就可以完成收集；
 *  老年代中，其存活率较高、没有额外空间对它进行分配担保，就应该使用“标记-整理”或“标记-清理”算法进行回收。

## 一些收集器 ##

### Serial收集器 ###

单线程收集器，表示在它进行垃圾收集时，必须暂停其他所有的工作线程，直到它收集结束。"Stop The World".

### ParNew收集器 ###

实际就是Serial收集器的多线程版本。

*  并发(Parallel):指多条垃圾收集线程并行工作，但此时用户线程仍然处于等待状态；
 *  并行(Concurrent):指用户线程与垃圾收集线程同时执行，用户程序在继续运行，而垃圾收集程序运行于另一个CPU上。

### Parallel Scavenge收集器 ###

该收集器比较关注吞吐量(Throughout)(CPU用于用户代码的时间与CPU总消耗时间的比值)，保证吞吐量在一个可控的范围内。

### CMS(Concurrent Mark Sweep)收集器 ###

CMS收集器是一种以获得最短停顿时间为目标的收集器。

### G1(Garbage First)收集器 ###

从JDK1.7 Update 14之后的HotSpot虚拟机正式提供了商用的G1收集器，与其他收集器相比，它具有如下优点：并行与并发；分代收集；空间整合；可预测的停顿等。

> 本部分主要分析了三种不同的垃圾回收算法：Mark-Sweep, Copy, Mark-Compact. 每种算法都有不同的优缺点，也有不同的适用范围。而JVM中对垃圾回收器并没有严格的要求，不同的收集器会结合多个算法进行垃圾回收。

## 内存分配 ##

Java技术体系中所提倡的自动内存管理最终可以归结为自动化的解决2个问题：**给对象分配内存**以及**回收分配给对象的内存**。

### 对象优先在Eden分配 ###

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

*  Minor GC(新生代GC):指发生在新生代的垃圾收集动作，因为Java对象大多都具备朝生夕灭的特性，所以Minor GC发生的非常频繁。
 *  Full GC/Major GC(老年代GC):指发生在老年代的GC，出现了Major GC，经常会伴随至少一次的Minor GC。

### 大对象直接进老年代 ###

大对象是指需要大量连续内存空间的Java对象（例如很长的字符串以及数组）。

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

JVM为每个对象定义一个对象年龄计数器。

*  如果对象在Eden出生并经历过第一次Minor GC后仍然存活，并且能够被Survivor容纳，则应该被移动到Survivor空间中，并且年龄对象设置为1；
 *  对象在Survivor区中每熬过一次Minor GC，年龄就会增加1岁，当它的年龄增加到一定程度(默认为15岁，可通过参数-XX:MaxTenuringThreshold设置)，就会被晋升到老年代中。
 *  要注意的是：JVM并不是永远的要求对象的年龄必须达到MaxTenuringThreshold才能晋升老年代，如果在Survivor空间中相同年龄所有对象大小的总和大于Survivor空间的一般，年龄大于等于该年龄的对象就可以直接进入老年代，无需等到MaxTenuringThreshold中要求的年龄。

### 空间分配担保 ###

*  在发生Minor GC之前，虚拟机会先检查老年代最大可用的连续空间是否大于新生代所有对象总空间，如果这个条件成立，则进行Minor GC是安全的；
 *  如果不成立，则虚拟机会查看HandlePromotionFailure设置值是否允许担保失败。如果允许，则急促检查老年代最大可用连续空间是否大于历次晋升到老年代对象的平均大小，如果大于，将尝试着进行一次Minor GC，尽管它是有风险的；
 *  如果小于或者HandePromotionFailure设置为不允许冒险，则这时要改为进行一次Full GC.

--------------------

## 总结 ##

本篇博客主要根据Java的GC原理，从What，When，How三方面对如何进行垃圾回收做了分析。  
简而言之：  
What -- 堆和方法区；  
When -- 已死的对象（引用无法可达）；  
How -- 标记-清除-整理-复制算法。  
关于GC问题，牢牢把握住这三个问题，然后进行发散性思维，便可以很好的掌握这部分内容了。  
最后对Java对对象的内存分配策略进行了介绍：新生代Eden区 -- Survivor区 -- 老年代

## JVM区域各个区的讲解 Eden Space（伊甸园）、Survivor Space(幸存者区)、Tenured Gen（老年代-养老区） ##

**注:此部分转载自**[https://www.aliyun.com/jiaocheng/822128.html?spm=5176.100033.1.17.34085cb356Bxhr][https_www.aliyun.com_jiaocheng_822128.html_spm_5176.100033.1.17.34085cb356Bxhr]

摘要：JVM区域总体分两类,heap区和非heap区。heap区又分:EdenSpace(伊甸园)、SurvivorSpace(幸存者区)、TenuredGen(老年代-养老区)。非heap区又分:CodeCache(代码缓存区)、PermGen(永久代)、JvmStack(java虚拟机栈)、LocalMethodStatck(本地方法栈)。HotSpot虚拟机GC算法采用分代收集算法:1、一个人(对象)出来(new出来)后会在EdenSpace(伊甸园)无忧无虑的生活,直到GC

### JVM区域总体分两类,heap区和非heap区。 ###

*  heap区又分:Eden Space(伊甸园)、Survivor Space(幸存者区)、Tenured Gen(老年代-养老区)。
 *  非heap区又分:Code Cache(代码缓存区)、Perm Gen(永久代)、Jvm Stack(java虚拟机栈)、Local Method Statck(本地方法栈)。

### HotSpot虚拟机GC算法采用分代收集算法: ###

*  1、一个人(对象)出来(new 出来)后会在Eden Space(伊甸园)无忧无虑的生活,直到GC到来打破了他们平静的生活。GC会逐一问清楚每个对象的情况,有没有钱(此对象的引用)啊,因为GC想赚钱呀,有钱的才可以敲诈嘛。然后富人就会进入Survivor Space(幸存者区),穷人的就直接kill掉。
 *  2、并不是进入Survivor Space(幸存者区)后就保证人身是安全的,但至少可以活段时间。GC会定期(可以自定义)会对这些人进行敲诈,亿万富翁每次都给钱,GC很满意,就让其进入了Genured Gen(养老区)。万元户经不住几次敲诈就没钱了,GC看没有啥价值啦,就直接kill掉了。
 *  3、进入到养老区的人基本就可以保证人身安全啦,但是亿万富豪有的也会挥霍成穷光蛋,只要钱没了,GC还是kill掉。

**分区的目的**:新生区由于对象产生的比较多并且大都是朝生夕灭的,所以直接采用标记-清理算法。而养老区生命力很强,则采用复制算法,针对不同情况使用不同算法。

非heap区域中Perm Gen中放着类、方法的定义,jvm Stack区域放着方法参数、局域变量等的引用,方法执行顺序按照栈的先入后出方式。

### 现代JVM内存管理方法及GC的实现和主要思路 ###

谨以此文纪念已经辞世的C语言之父,Dennis Ritchie。无论世事如何变迁,无论日月如何更替,您的光辉成就都照耀着现代计算机技术发展之路。

提到现代JVM内存管理,就不能不提到一个意义深远的东西,C语言。C语言最为人诟病,但是也是C语言最让人神往的,就是它的内存管理机制。在C语言中,程序员可以自由的控制内存,自己决定内存里写0还是写1.所谓的数据类型转换,在C语言看来,不过就是内存里的几次复制以及排列位置的不同,仅此而已。

然而随着应用规模的不断增大,无论是盘根错节的对象耦合关系,还是巨大的内存使用量,都让开发人员麻爪。动辄几个GB的内存总量,动辄成千上万的内存对象数量,都不再是一个人乃至十个人可以控制的范围了。况且,百密一疏,只要有一点点内存泄露,随着时间的推移,都有可能变成无比的灾难。OOM之类的问题,在程序员眼里,早已经是家常便饭,谁还没溢出过内存呢,是吧。

的确是有高手可以控制好内存,但是不是所有人。那么,大规模团队化开发的时候,如何保证内存使用不出现问题呢?代码走查?人工校验?反复测试?这些能不能行的通先不谈,就算可行,巨大的工作量也可以让所有合同超期到下个世纪。于是有人提出了一个想法。可以不可以让一部分高手写出完善的内存管理模块,再加上一堆各式各样的类库和标准,最后构成一个庞大的运行时?

这一想法被无数语言团队采用。第一个实现的,就是James Gosling领导的Java团队。Java的目标是Write Once,Run Anywhere.估计他们在咖啡馆喝咖啡的时候一时写错了,应该是Debug Anywhere,这才符合现在的实际,呵呵。扯远了,我们回头看内存管理。

JVM提供了很多类库,封装了很多数据类型和常用工具类,作为自己的基本库来使用,比如java.lang包。举一个最简单的例子,来一句最简单的代码。int i = 5;

在C语言里,这句话申请了几个字节的内存,然后放了个5进去,Java也是这么搞的。只不过,C语言里申请了以后要自己管理,而Java你不用自己烦恼这个事情,虚拟机会帮你处理。它会判断何时需要,何时不需要。由此推开去,更加复杂的业务,比如连接数据库,读取文件,我们要做的只是调用类库而已,内存申请和释放都由虚拟机全盘接管,我们不用动一根手指头。

我们是爽了,虚拟机就头疼了。这么多对象,什么时候该销毁,什么时候该保持,什么时候要检查这些关系呢?在JVM里,这个事情有一个模块来做,也就是我们这片文章的主角,GC,Garbage Collection,垃圾回收。

假设我们是实现GC的程序员,那么我们要做什么呢?首先,负责分配内存,负责控制对象的持有计数,负责销毁内存对象,还得负责内存整理什么的。在Sun制定的JVM规范里,详细描述了GC部分要做的事情,这里就不赘述了,想看的话,请自行Google。

现有的JVM,主流的,分别是HotSpot和JRockit,主要研究对象也是这两个。这篇文章里,我们只研究HotSpot,也就是所谓的Sun JVM。目前阶段,Sun的GC方式主要有CMS和G1两种。考虑到效果和实际应用,这里只介绍CMS。

CMS,全称Concurrent Low Pause Collector,是JDK1.4后期版本开始引入的新gc算法,在jdk5和jdk6中得到了进一步改进,它的主要适合场景是对响应时间的重要性需求较高的应用,并且预期这部分应用能够承受垃圾回收线程和应用线程共享处理器资源,且应用中存在比较多的长生命周期的对象的应用。CMS是用于对tenured generation的回收,也就是年老代的回收,目标是尽量减少应用的暂停时间,减少full gc发生的几率,利用和应用程序线程并发的垃圾回收线程来标记清除年老代。

JVM在程序运行过程当中,会创建大量的对象,这些对象,大部分是短周期的对象,小部分是长周期的对象,对于短周期的对象,需要频繁地进行垃圾回收以保证无用对象尽早被释放掉,对于长周期对象,则不需要频率垃圾回收以确保无谓地垃圾扫描检测。为解决这种矛盾,Sun JVM的内存管理采用分代的策略。

1)年轻代(Young Gen):年轻代主要存放新创建的对象,内存大小相对会比较小,垃圾回收会比较频繁。年轻代分成1个Eden Space和2个Suvivor Space(命名为A和B)。当对象在堆创建时,将进入年轻代的Eden Space。垃圾回收器进行垃圾回收时,扫描Eden Space和A Suvivor Space,如果对象仍然存活,则复制到B Suvivor Space,如果B Suvivor Space已经满,则复制到Old Gen。同时,在扫描Suvivor Space时,如果对象已经经过了几次的扫描仍然存活,JVM认为其为一个持久化对象,则将其移到Old Gen。扫描完毕后,JVM将Eden Space和A Suvivor Space清空,然后交换A和B的角色(即下次垃圾回收时会扫描Eden Space和BSuvivor Space。这么做主要是为了减少内存碎片的产生。

我们可以看到:Young Gen垃圾回收时,采用将存活对象复制到到空的Suvivor Space的方式来确保尽量不存在内存碎片,采用空间换时间的方式来加速内存中不再被持有的对象尽快能够得到回收。 2)年老代(Tenured Gen):年老代主要存放JVM认为生命周期比较长的对象(经过几次的Young Gen的垃圾回收后仍然存在),内存大小相对会比较大,垃圾回收也相对没有那么频繁(譬如可能几个小时一次)。年老代主要采用压缩的方式来避免内存碎片(将存活对象移动到内存片的一边,也就是内存整理)。当然,有些垃圾回收器(譬如CMS垃圾回收器)出于效率的原因,可能会不进行压缩。 3)持久代(Perm Gen):持久代主要存放类定义、字节码和常量等很少会变更的信息

以上是JVM区域各个区的讲解 Eden Space（伊甸园）、Survivor Space(幸存者区)、Tenured Gen（老年代-养老区）的内容，更多 space 老区 幸存者 伊甸园 讲解 survivor 各个 区域 年代 Tenured 的内容，请您使用右上方搜索功能获取相关信息。

## JVM的垃圾收集器 ##

### Serial收集器 ###

Serial收集器是新生代的垃圾收集器，是一个单线程的收集器，它开始工作时会暂停掉其它所有的工作线程，一直到它工作结束。它是虚拟机运行在Client模式下的默认新生代垃圾收集器，采用复制算法。

### ParNew收集器 ###

ParNew收集器是新生代的垃圾收集器，采用多线程进行垃圾收集和回收，采用复制算法的收集器，它是Serial收集器的多线程版本，它的实现复用了很多Serial收集器的代码，所以它包含了很多Serial收集器的参数和特性，它能与CMS收集器配合工作。它开始工作的时候会暂停所有用户线程。

### Parallel Scavenge收集器 ###

Parallel Scavenge收集器是一个新生代收集器，采用复制算法，多条垃圾收集线程并行工作。它与ParNew收集器的区别是它可以通过参数控制吞吐量，因此也被成为吞吐量优先收集器。

### Serial Old收集器 ###

Serial Old收集器是一个老年代收集器，它也是一个单线程收集器，使用标记-整理算法。虚拟机运行在Client模式下，Serial Old收集器用于收集和回收老年代。

### Parallel Old收集器 ###

Parallel Old收集器是一个老年代收集器，它使用多线程进行垃圾收集和回收，使用标记-整理算法。和Parallel Scavenge收集器一样，它也注重吞吐量优先。

### CMS收集器 ###

CMS收集器是一个老年代收集器，采用标记-清除算法，注重获取最短回收停顿时间，是比较常用的垃圾收集器。它的工作过程包含4个步骤：初始标记、并发标记、重新标记和并发清除，其中初始标记和重新标记需要暂停所有的用户线程。因为它采用标记-清除算法，所以会产生空间碎片。

### G1收集器 ###

G1收集器可以用于新生代和老年代，具备用户线程和回收线程的并行与并发等特性。

--------------------

本文来自 wind瑞 的CSDN 博客 ，全文地址请点击：[https://blog.csdn.net/windrui/article/details/79293702?utm\_source=copy][https_blog.csdn.net_windrui_article_details_79293702_utm_source_copy]

[731104-20160624112838750-212547580.png]: /images/20220510/3e64f2e562134e479613643c52fcae4d.png
[https_www.aliyun.com_jiaocheng_822128.html_spm_5176.100033.1.17.34085cb356Bxhr]: https://www.aliyun.com/jiaocheng/822128.html?spm=5176.100033.1.17.34085cb356Bxhr
[https_blog.csdn.net_windrui_article_details_79293702_utm_source_copy]: https://blog.csdn.net/windrui/article/details/79293702?utm_source=copy