Java GC算法背景原理与内存池划分

约定不等于承诺〃 2023-10-02 14:22 1阅读 0赞

#### 文章目录 ####

*  1. 引用计数
 *  2. 标记-清除算法(Mark and Sweep)
 *   *  2.1 标记可达对象(Marking Reachable Objects)
     *  2.2 清除(Sweeping)
 *  3. 标记-清除-整理算法(Mark-Sweep-Compact)
 *  4. 分代假设
 *  5. 内存池划分
 *   *  5.1 年轻代（Young Gen）
     *  5.2 老年代 (Old Gen)
     *  5.3 永久代 (Perm Gen)
     *  5.4 元数据区 (Metaspace)

## 1. 引用计数 ##

通过在对象头中分配一个空间来保存该对象被引用的次数。如果该对象被其它对象引用，则它的引用计数加一，如果删除对该对象的引用，那么它的引用计数就减一。（一般不是一个对象被引用的次数为`0`了就立即释放，出于效率考虑，系统总是会等一批对象一起处理，这样更加高效）

如果`A`对象引用`B`对象，`B`对象引用`A`对象，引用计数始终不为`0`，这种循环依赖的对象没办法回收。

这种情况在计算机中叫做“ 内存泄漏 ”，该释放的没释放，该回收的没回收。 如果依赖关系更复杂，计算机的内存资源很可能用满，或者说不够用，内存不够用则称为“ 内存溢出 ”。

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

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

前面我们讲解了引用计数里需要查找所有的对象计数和对象之间的引用关系。那么如何来查找所有对象，怎么来做标记呢？

这个算法包含两步:

*  `Marking` (标记): 遍历所有的可达对象，并在本地内存(`native`)中分门别类记下。
 *  `Sweeping` (清除): 这一步保证不可达对象所占用的内存被清除，在之后进行内存分配时可以重用。

### 2.1 标记可达对象(Marking Reachable Objects) ###

![watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA56CW5Lia5rSLX18_size_20_color_FFFFFF_t_70_g_se_x_16][]

首先，有一些特定的对象被指定为 `Garbage Collection Roots`(`GC`根元素)。包括:

*  局部变量
 *  活动线程(`Active threads`)
 *  内存中所有类的静态字段(`static field`)
 *  `JNI`引用

如上图，从`GC`**根元素**开始扫描，到直接引用，以及其他对象(通过对象的属性域)。所有`GC`访问到的对象都被**标记**(`marked`)为存活对象。

存活对象在上图中用蓝色表示。标记阶段完成后，所有存活对象都被标记了。而其他对象就是从`GC`根元素不可达的，也就是说程序不能再使用这些不可达的对象(`unreachable objec`t)。这样的对象被认为是垃圾，`GC`会在接下来的阶段中清除他们。

**标记清除算法最重要的优点，就是解决了引用计数的循环引用而导致内存泄露的问题，因为只标记可达对象，如果一系列对象形成了环，但这个环上的所有对象都是不可达的，那么在引用跟踪的可达对象集合里就不包括环，环上的对象都属于不可达对象，都会被清除。**

`JVM`中包含了多种`GC`算法，如`Parallel Scavenge`(并行清除)，`Parallel Mark+Copy`(并行标记+复制) 以及 `CMS`，他们在实现上略有不同，但理论上都采用了以上两个步骤。

这种方法也有不好的地方：在标记阶段，需要暂停所有应用线程，去遍历所有对象的引用关系，因为不暂停就没法跟踪一直在变化的引用关系图。这种情景叫做 **`Stop The World pause`** (**`STW`全线停顿**)，也叫做`GC`停顿。有一个概念需要注意，可以安全地暂停线程的点叫做**安全点**(`safe point`)。`GC`过程中，有一部分操作需要等所有应用线程都到达安全点，然后暂停所有线程进行`GC`，这样`JVM`就可以专心执行清理工作。安全点可能有多种因素触发，但`GC`是最主要的原因。

标记阶段暂停的时间与堆内存大小、对象的总数没有直接关系，而是由**存活对象**(`alive objects`)的数量来决定。所以增加堆内存的大小并不会直接影响标记阶段占用的时间。

### 2.2 清除(Sweeping) ###

`Mark and Sweep`(标记-清除) 算法的概念非常简单，在标记阶段完成后，所有不可达对象占用的内存空间会被清除，可以用来分配新对象。

这种算法需要使用空闲表(`free-list`)来记录所有的空闲区域，以及每个区域的大小。维护空闲表增加了对象分配时的开销。此外还存在另一个弱点 —— 明明还有很多空闲内存，但是却都不连续，导致写入操作越来越耗时，因为寻找一块足够大的空闲内存变得困难，可能最后没有一个区域的大小能够存放需要分配的对象，从而导致内存分配失败(在`Java` 中就是 `OutOfMemoryError`)，这个就叫**内存的碎片化**。就像是摆满棋子的围棋盘上，一部分位置上棋子被拿掉而产生了一些零散的空位置，没有一整片的空地方。  
![watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA56CW5Lia5rSLX18_size_20_color_FFFFFF_t_70_g_se_x_16 1][]

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

## 3. 标记-清除-整理算法(Mark-Sweep-Compact) ##

这个算法就是在标记-清除算法的基础上多了整理(`Compact`)这一步。也就是将所有被标记的对象(存活对象)，迁移到内存空间的起始处，**消除了标记-清除算法的缺点**。

但是也有缺点，是`GC`暂停时间会增加，因为需要将所有对象复制到另一个地方，然后修改指向这些对象的引用，这也是需要额外时间的。

> `JVM`中的引用是一个抽象的概念，如果`GC`移动某个对象，就会修改(栈和堆中)所有指向该对象的引用。  
> 移动/拷贝/提升/压缩 一般来说是一个 `STW` 的过程，所以修改对象引用是一个安全的行为。但因为要更新所有的引用，可能会影响应用程序的性能。

碎片整理之后，分配新对象就很简单，只需要通过**指针碰撞**(`pointer bumping`)即可。使用这种算法，内存空间剩余的容量一直是清楚的，不会再导致内存碎片问题。

> 指针碰撞：假设`Java`堆中内存时完整的，已分配的内存和空闲内存分别在不同的一侧，通过一个指针作为分界点，需要分配内存时，仅仅需要把指针往空闲的一端移动与对象大小相等的距离。

![watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA56CW5Lia5rSLX18_size_20_color_FFFFFF_t_70_g_se_x_16 2][]

在这里思考一个问题，任何一种`GC`算法能否高效的管理当前堆内存的所有对象？答案是否定的，因为对象的生命周期都不同，有的很快被清除，有的还会存活很长时间。于是就有了**分代假设理论**…

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

## 4. 分代假设 ##

我们前面提到过，执行垃圾收集需要停止整个应用。很明显，对象越多则收集所有垃圾消耗的时间就越长。 但可不可以只处理一个较小的内存区域呢? 为了探究这种可能性，做了一个分析图。

![watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA56CW5Lia5rSLX18_size_20_color_FFFFFF_t_70_g_se_x_16 3][]

于是便有了分代假设：

1.  大部分新生对象很快无用；
2.  存活较长时间的对象，可能存活更长时间。

我们可以根据对象的不同特点，把对象进行分类。基于这一假设，`VM`中的内存被分为**年轻代**(`Young Generation`)和**老年代**(`Old Generation`)。老年代有时候也称为年老区(`Tenured`)。

拆分为这样两个可清理的单独区域，我们就可以**根据对象的不同特点，允许采用不同的算法来大幅提高`GC`的性能。**

要着重强调的是，分代假设并不适用于所有程序。因为分代`GC`算法专门针对“要么死得快”，“否则活得长” 这类特征的对象来进行优化，此时`JVM`管理那种存活时间半长不长的对象就显得非常尴尬了。

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

## 5. 内存池划分 ##

![watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA56CW5Lia5rSLX18_size_20_color_FFFFFF_t_70_g_se_x_16 4][]

我们把新对象的创建放在年轻代，把长期存活的对象放在老年代。这样就可以用不同的策略去优化这两块对象内存的管理方式。

### 5.1 年轻代（Young Gen） ###

**年轻代**可以分为**新生代 (`Eden Space`)和两个存活区(`Survivor Spaces`)——`S0`和`S1`**，新生代也叫`Eden`区，是分配创建新对象的地方。

当`Eden`区要满的时候，就会做一次垃圾回收，在垃圾回收的阶段会先标记存活对象，然后会把`Eden`区里存活的对象复制到其中一个存活区，假设是`S0`。这个时候随着程序的运行，对象继续创建，因为`S0`在上个阶段已经往里面复制了一部分对象，这时`Eden`区再次要满的时候，就会把`Eden`区和`S0`里存活的对象复制到另一个存活区`S1`，复制完后，`Eden`区和`S0`区所有的对象占用的内存都是可以被释放的，所以直接把`Eden`区和`S0`给清空掉。

然后在下一个使用周期继续在`Eden`区创建对象，`Eden`区再满的时候，就会把`Eden`区和`S1`区里的存活对象复制到`S0`，再把`Eden`和`S1`清空掉。需要注意的时，通常`Eden`区、`S0`区、`S1`区中都只有两个区域有数据，另外一个存活区是空的。年轻代绝大部分对象会在垃圾回收的时候被清理掉，只有少量对象会存活，所以每次垃圾回收只要把这少量对象标记出来，然后复制到其中一个存活区即可。

>   每个周期里都会把少量对象从一个存活区复制到另一个存活区，所以这两个存活区除了叫`S0`和`S1`以外，也可以叫`from`和`to`，复制的起点存活区叫`from`，目标存活区叫`to`

注意：这里用到的算法是**标记-复制**算法，不需要做移动。因为复制了一份，原有的数据可以清空掉。如下图：

![watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA56CW5Lia5rSLX18_size_20_color_FFFFFF_t_70_g_se_x_16 5][]

细心地小伙伴肯定发现了，图中怎么还会有一个`TLAB`的区域？

因为会有多个线程同时创建多个对象，所以 `Eden` 区被划分为多个线程本地分配缓冲区(`Thread Local Allocation Buffer`，简称`TLAB`)。

通过这种缓冲区划分，大部分对象直接由`JVM` 在对应线程的`TLAB`中分配，避免与其他线程的同步操作。

如果 `TLAB` 中没有足够的内存空间，就会在共享`Eden`区(`shared Eden space`)中分配。如果共享`Eden`区也没有足够的空间，就会触发一次年轻代`GC` 来释放内存空间。如果`GC`之后 `Eden` 区依然没有足够的空闲内存区域，则对象就会被分配到老年代空间(`Old Generation`)。

### 5.2 老年代 (Old Gen) ###

从上图可以看到，在`GC`后，对象有一部分去了老年代，这个细节很重要。

如果对象经历了一定的`GC`次数后仍然存活，那么它们就会挪到老年代。比如默认情况下是`15`次（这也是`HotSpot JVM`中允许的最大值），通过`-XX: +MaxTenuringThreshold=15`设置最大老年代的阈值。因为对象存活周期超过`15`次，有很大概率这个对象会继续存活很多代，所以放在老年代。

**如果存活区空间不够存放年轻代中的存活对象，对象提升(`Promotion`)到老年代的步骤也可能更早地进行。**

老年代内存空间通常会更大，里面的对象是垃圾的概率也更小。老年代`GC`发生的频率比年轻代小很多。同时，因为预期老年代中的对象大部分是存活的，所以不再使用标记和复制(`Mark and Copy`)算法。而是采用移动对象的方式来实现最小化内存碎片。老年代空间的清理算法通常是建立在不同的基础上的。原则上，会执行以下这些步骤

*  先标记所有的根可达对象
 *  删除不可达对象
 *  整理老年代空间里存活的对象，方法是将所有的存活对象复制，从老年代空间开始的地方依次存放

整理的方法就是把所有存活对象进行复制，移动到老年代空间开始的地方，依次往后对齐存放，也就是做了内存的碎片整理。

**为什么用这种复制移动方式处理？** 因为老年代没有继续分区，没办法像年轻代一样有两个存活区交替进行复制清除，只能进行整理，避免碎片过多。

### 5.3 永久代 (Perm Gen) ###

在`Java 8` 之前有一个特殊的空间,称为“永久代”(`Permanent Generation`)。这是存储元数据(`metadata`)的地 方，比如 `class` 信息等。此外，**这个区域中也保存有其他的数据和信息，包括内部化的字符串(`internalized strings`)等等。 实际上这给`Java`开发者造成了很多麻烦，因为很难去计算这块区域到底需要占用多少内存空间。** 预测失败导致的结果就是产生 `java.lang.OutOfMemoryError: Permgen space` 这种形式的错误。除非`OutOfMemoryError` 确实是内存泄漏导致的，否则就只能增加 `permgen` 的大小，例如下面的示例，就 是设置 `perm gen` 最大空间为 `256 MB`:

-XX:MaxPermSize=256m

### 5.4 元数据区 (Metaspace) ###

既然估算元数据所需空间那么复杂，`Java 8`直接删除了永久代(`Permanent Generation`)，改用 `Metaspace`。 从此以后，`Java` 中很多杂七杂八的东西都放置到普通的堆内存里。 当然，像类定义(`class definitions`)之类的信息会被加载到 `Metaspace` 中。元数据区位于本地内存(`native memory`)，不再影响到普通的`Java`对象。默认情况下，`Metaspace`的大小只受限于 `Java` 进程可用的本地内存。这样程序就不再因为多加载了几个类/`JAR`包就导致 `java.lang.OutOfMemoryError: Permgen space.` 。注意，这种不受限制的空间也不是没有代价的 —— 如果 `Metaspace` 失控，则可能会导致严重影 响程序性能的内存交换(`swapping`)，或者导致本地内存分配失败。 如果需要避免这种最坏情况，那么可以通过下面这样的方式来限制 `Metaspace` 的大小，如 `256 MB`

-XX:MaxMetaspaceSize=256m

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

欢迎一键三连~  
  
有问题请留言，大家一起探讨学习  
  
\----------------------Talk is cheap, show me the code-----------------------

[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA56CW5Lia5rSLX18_size_20_color_FFFFFF_t_70_g_se_x_16]: https://img-blog.csdnimg.cn/97d348141d0e4d41be4f77747eee903e.png?x-oss-process=image/watermark,type_ZHJvaWRzYW5zZmFsbGJhY2s,shadow_50,text_Q1NETiBA56CW5Lia5rSLX18=,size_20,color_FFFFFF,t_70,g_se,x_16
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA56CW5Lia5rSLX18_size_20_color_FFFFFF_t_70_g_se_x_16 1]: https://img-blog.csdnimg.cn/e02e96ee8c0046338372090255ce9e12.png?x-oss-process=image/watermark,type_ZHJvaWRzYW5zZmFsbGJhY2s,shadow_50,text_Q1NETiBA56CW5Lia5rSLX18=,size_20,color_FFFFFF,t_70,g_se,x_16
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA56CW5Lia5rSLX18_size_20_color_FFFFFF_t_70_g_se_x_16 2]: https://img-blog.csdnimg.cn/174f4dd0d23d406599cc00301e3abc6d.png?x-oss-process=image/watermark,type_ZHJvaWRzYW5zZmFsbGJhY2s,shadow_50,text_Q1NETiBA56CW5Lia5rSLX18=,size_20,color_FFFFFF,t_70,g_se,x_16
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA56CW5Lia5rSLX18_size_20_color_FFFFFF_t_70_g_se_x_16 3]: https://img-blog.csdnimg.cn/5741e390e1c24f308286dd9f6eac2991.png?x-oss-process=image/watermark,type_ZHJvaWRzYW5zZmFsbGJhY2s,shadow_50,text_Q1NETiBA56CW5Lia5rSLX18=,size_20,color_FFFFFF,t_70,g_se,x_16
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA56CW5Lia5rSLX18_size_20_color_FFFFFF_t_70_g_se_x_16 4]: https://img-blog.csdnimg.cn/f03004d35ff944a79b93a7468ec3c376.png?x-oss-process=image/watermark,type_ZHJvaWRzYW5zZmFsbGJhY2s,shadow_50,text_Q1NETiBA56CW5Lia5rSLX18=,size_20,color_FFFFFF,t_70,g_se,x_16
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA56CW5Lia5rSLX18_size_20_color_FFFFFF_t_70_g_se_x_16 5]: https://img-blog.csdnimg.cn/9a14bc475be749849834f7b5af0aaf10.png?x-oss-process=image/watermark,type_ZHJvaWRzYW5zZmFsbGJhY2s,shadow_50,text_Q1NETiBA56CW5Lia5rSLX18=,size_20,color_FFFFFF,t_70,g_se,x_16