JVM的GC回收算法、GC收集器以及内存分配策略

痛定思痛。 2023-06-22 13:54 88阅读 0赞

**目录**

•写在前面

•标记-清除算法

•复制算法

•标记-整理算法

•HotSpot上的算法实现保障

•GC收集器

•内存分配策略

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

# •写在前面 #

JVM的垃圾回收算法、收集器以及内存分配策略放在一起了解和理解，我觉得有助于我们加深印象，这一篇文章我就不再讲述对象为什么要回收以及何时回收了，想要了解相关知识可以看我的另一篇文章[JVM如何判断对象是否要回收][JVM]。几个点放在一起内容会有些多，不过我弄了一个目录，需要的自行点击目录跳转就可以了。另一个要提前讲的就是“stop the world”这个概念，我觉得这个名词应该了解 过线程或者JVM的人都不陌生，stop the world会在执行某一个垃圾回收算法的时候产生，JVM为了执行垃圾回收，会暂停所有java程序线程的执行，等垃圾回收完成后，再继续运行。所以尽可能减少stop the world的时间，就是我们优化JVM的主要目标。

# •标记-清除算法 #

首先讲的是标记-清除算法，也是最基础的垃圾收集算法，我们看到它的名字就可以知道，算法分为两个阶段，分别是“标记”和“清除”两个阶段，首先标记出所有所有需要回收的对象，在标记完成之后，统一回收所有被标记的对象，至于如何完成对象标记，细节还是移驾另一篇文章[JVM如何判断对象是否要回收][JVM]。后面提到的收集算法，都是基于这个算法的思路并对其不足进行改进而得到的。

这个算法主要有两个不足的地方：第一是效率问题，标记和清除两个过程的效率都不高；还有一个就是内存空间的问题，这个算法在标记清除之后，会留下大量的不连续的内存碎片，这些空间碎片会导致一个很明显的问题就是无法给较大对象分配内存，而找不到足够的内存分配给对象，又会提前出发垃圾回收。如下图所示

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0RCQ18xMjE_size_16_color_FFFFFF_t_70][]

# •复制算法 #

所以，为了解决效率问题，就出现了复制算法，复制算法将可用内存按容量划分为大小相等的两块，每次只使用其中的一块。当这块内存用完了，就将还存活的对象复制到另一个内存块，然后再清楚掉这个使用过的内存空间，这样使得每次都是对一半的空间进行内存回收，内存分配的时候就不用了考虑内存碎片的等复杂情况，只要移动堆顶的指针，按顺序分配就可以了，简单高效，只不过这种算法的代价是牺牲了一半的内存空间，大致如下图。其实，我们如果了解过对象的生存时间后，我们可以发现，其实大部分的对象都是会被清除的，这个比例我查了一下大概是98%，所以我们可以对这个算法进行改进，不用1:1来划分空间，而是将内存划分为一块较大的空间（常叫做Eden空间）以及两块较小的空间（常叫做Survivor空间），大小比例是8:1:1，为什么需要两块S空间，是因为我们需要一块空间进行担保，大致过程如下（详细的在分配策略会讲解），每次我们进行清除的时候，先将Eden空间和其中一个Survivor空间的存活对象复制到另一个Survivor上，然后将这块survivor空间和Eden清除，每次只浪费10%的内存空间。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0RCQ18xMjE_size_16_color_FFFFFF_t_70 1][]

# •标记-整理算法 #

一样的，复制算法如果当对象的存活率比较高时，需要进行比较多的复制操作，这样降低了效率，而且我们还需要使用多余的空间来进行担保，这样不适合在老年代上使用（分代会在后面深入讲到，老年代是那些“不想死”的对象，所以存活率比较高）。所以根据老年代的特点，提出了标记-整理算法，不过和标记-清除不一样的是，它在标记后，将存活的对象向一端移动，然后清除掉存活对象边界以外的空间。大致如下图：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0RCQ18xMjE_size_16_color_FFFFFF_t_70 2][]

# •HotSpot上的算法实现保障 #

我们在进行GC之前，肯定需要进行高效的判定对象存活状况，我们使用的方法就是可达性分析，可达性分析一个比较重要的环节就是找到GCRoots，而一般能成为GCRoots对象的在虚拟机栈和本地方法栈和方法区中，想一下，光方法区就有几百兆那么大，我们难道挨个遍历所有的引用嘛，那显然是不实际也不高效的，除此之外，可达性分析分析过程中引用对象的关系不断变化是很敏感的，因为可达性分析工作必须在一个能保证一致性的快照（就像是整个执行系统被冻结在一个时间点上）中进行，所以这也是导致GC进行时，必须进行GC停顿（stop the world）。所以我们必须提高可达性分析速度从而降低GC停顿的时间。

现实中，java虚拟机使用的都是准确是GC，也就是当执行系统停顿下来的时候，并不需要一个不漏的检查所有引用位置，而是通过某种方法直接得到哪些地方存放着对象引用。而这种方式是通过一组叫做OopMap的数据结构实现的。在类加载完成之后，HotSpot就把对象内什么偏移量上是什么类型的数据计算出来，在JIT编译拖成中，也会在特定的位置记录下栈和寄存器中那些位置时引用，这样，GC扫描时就可以直接得知这些信息。

通过HotSpot可以快速完成GCRoots枚举，但是有一个问题凸显出来了，就是可能导致引用关系变化，或者说OopMap内容变化的指令非常多，如果为每一条指令都生成对应的OOpMap，那GC空间的成本将会变高。实际上，也并不是每条指令都生成OopMap的，我们只有在特定的位置记录这些信息，这些特定的位置就叫做安全点。即程序执行时并非在所有地方都能停顿下来开始GC的，只有到达安全点时才能停顿。安全点既不能太少导致GC等待时间太长，也不能过于频繁导致过分增大运行时符合，所以确定安全点也是需要一些方法，不过这个方法我就不觉提讲，不然很难说完。所有线程跑到安全点停顿下来有两种方案，一种是抢断式中断，即不需要线程的执行代码主动配合，在GC发生时，首先所有线程全部中断，如果发现有线程中断的地方不在安全点上，就恢复线程，让它执行到安全点上（现在虚拟机不用这种方式实现）。另一种是主动式中断，即GC时不直接对线程中断，仅仅简单的设置一个标志，各个线程执行时主动轮询这个标志，线程发现中断标志就自己挂起。

安全点很棒的一直思路，但是（什么都怕但是，哈哈哈），还是会出现一些问题导致安全点也失效的，就是在进入到安全点之前，程序不执行了，啥叫程序不执行，就比如在到达安全点之前，程序发生了Sleep状态或者Blocked状态，这个时候线程无法响应JVM的中断请求，所以，为了解决这种情况，使用了安全区域。其实可以把它理解成安全点的延伸，当线程执行到安全区域时，首先标识自己进入了安全区域，那样，当这段时间里，JVM要发起GC时，就不用管标识自己为安全区域线程了，当线程要离开安全区域是，它要检查系统是否已经完成了根节点枚举（或者整个GC过程），如果完成了，那线程就继续执行，否则等待。

# •GC收集器 #

**Serial收集器：**串行收集器是最古老，最稳定以及效率高的收集器，可能会产生较长的停顿，只使用一个线程去回收。新生代、老年代使用串行回收；新生代复制算法、老年代标记-压缩；垃圾收集的过程中会Stop The World（服务暂停）

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0RCQ18xMjE_size_16_color_FFFFFF_t_70 3][]

**ParNew收集器 ：**ParNew收集器其实就是Serial收集器的多线程版本。新生代并行，老年代串行；新生代复制算法、老年代标记-压缩

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0RCQ18xMjE_size_16_color_FFFFFF_t_70 4][]

**Parallel收集器：**Parallel Scavenge收集器类似ParNew收集器，Parallel收集器更关注系统的吞吐量。可以通过参数来打开自适应调节策略，虚拟机会根据当前系统的运行情况收集性能监控信息，动态调整这些参数以提供最合适的停顿时间或最大的吞吐量；也可以通过参数控制GC的时间不大于多少毫秒或者比例；新生代复制算法、老年代标记-压缩

**Parallel Old 收集器：**Parallel Old是Parallel Scavenge收集器的老年代版本，使用多线程和“标记－整理”算法。这个收集器是在JDK 1.6中才开始提供

**CMS收集器：**CMS收集器是一种以获取最短回收停顿时间为目标的收集器。目前很大一部分的Java应用都集中在互联网站或B/S系统的服务端上，这类应用尤其重视服务的响应速度，希望系统停顿时间最短，以给用户带来较好的体验。从名字（包含“Mark Sweep”）上就可以看出CMS收集器是基于“标记-清除”算法实现的，它的运作过程相对于前面几种收集器来说要更复杂一些，整个过程分为4个步骤，包括：

初始标记（CMS initial mark）需要“Stop The World”

并发标记（CMS concurrent mark）

重新标记（CMS remark）需要“Stop The World”

并发清除（CMS concurrent sweep）

其中初始标记、重新标记这两个步骤仍然需要“Stop The World”。初始标记仅仅只是标记一下GC Roots能直接关联到的对象，速度很快，并发标记阶段就是进行GC Roots Tracing的过程，而重新标记阶段则是为了修正并发标记期间，因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录，这个阶段的停顿时间一般会比初始标记阶段稍长一些，但远比并发标记的时间短。由于整个过程中耗时最长的并发标记和并发清除过程中，收集器线程都可以与用户线程一起工作，所以总体上来说，CMS收集器的内存回收过程是与用户线程一起并发地执行。老年代收集器（新生代使用ParNew）

优点: 并发收集、低停顿

缺点: 产生大量空间碎片、并发阶段会降低吞吐量

**G1收集器：**G1是目前技术发展的最前沿成果之一，HotSpot开发团队赋予它的使命是未来可以替换掉JDK1.5中发布的CMS收集器。与CMS收集器相比G1收集器有以下特点：

空间整合，G1收集器采用标记整理算法，不会产生内存空间碎片。分配大对象时不会因为无法找到连续空间而提前触发下一次GC。

可预测停顿，这是G1的另一大优势，降低停顿时间是G1和CMS的共同关注点，但G1除了追求低停顿外，还能建立可预测的停顿时间模型，能让使用者明确指定在一个长度为N毫秒的时间片段内，消耗在垃圾收集上的时间不得超过N毫秒，这几乎已经是实时Java（RTSJ）的垃圾收集器的特征了。

上面提到的垃圾收集器，收集的范围都是整个新生代或者老年代，而G1不再是这样。使用G1收集器时，Java堆的内存布局与其他收集器有很大差别，它将整个Java堆划分为多个大小相等的独立区域（Region），虽然还保留有新生代和老年代的概念，但新生代和老年代不再是物理隔阂了，它们都是一部分（可以不连续）Region的集合。G1的新生代收集跟ParNew类似，当新生代占用达到一定比例的时候，开始出发收集。和CMS类似，G1收集器收集老年代对象会有短暂停顿。

# •内存分配策略 #

关于对象的内存分配，总整体上看，就是在堆上的分配（但也可能经过JIT编译后被拆散为标量类型并间接的栈上分配）对象主要分配在新生代的Eden去区上，不过特别的是，如果启动了本地线程分配缓冲（可以参考我另一篇文章，[如何判断对象是否可以回收][JVM]），少数情况也可能直接分配在老年代。不过，在大多数情况下，对象还是在新生代Eden区分配的，当Eden区没有足够的空间进行分配时，虚拟机将发起一次MinorGC（这里解释一下啥是MinorGC，MinorGC是新生代GC，所以MinorGC非常频繁，还有一个我们经常看到的FullGC/MajorGC是指老年代GC，可以说出现一次MajorGC，就至少发生一次MinorGC，当然也并非绝对哦）。当大对象出现时，可以设置让它直接分配到老年代上，为啥呢？因为在新生代中，如果遇到哪些生命周期很短的大对象（很长的字符串或者数组之类的对象），就会频繁的发生内存复制，很消耗资源。

值得一提的是，虚拟机采用分代收集的思想来管理内存，自然需要判断哪些对象放在新生代，哪些对象放在老年代。为了做到这一点，虚拟机给每个对象定义了一个对象年龄计数器，如果对象在Eden出生并经过第一次MinorGC后仍然存在，并且能被Survivor容纳的话，将被移动到Survivor空间中，并且对象的年龄设为1，对象在Survivor中每熬过一次MinorGC，年龄就增加1，当年龄增加到一定程度，就会被晋升老年代（默认是15岁）。当然，也不一定说对象必须到达某个年龄才能进入老年代，虚拟机为了更好的适应不同程序的内存状况，规定如果Survivor空间中相同年龄的所有对象大小总和大于Survivor空间的一半，年龄大于或等于该年龄的对象就可以直接进入老年代，而无须等到设定的年龄阈值。

[JVM]: https://blog.csdn.net/DBC_121/article/details/103562284
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0RCQ18xMjE_size_16_color_FFFFFF_t_70]: https://img-blog.csdnimg.cn/20191216175015832.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0RCQ18xMjE=,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0RCQ18xMjE_size_16_color_FFFFFF_t_70 1]: https://img-blog.csdnimg.cn/20191216175724575.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0RCQ18xMjE=,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0RCQ18xMjE_size_16_color_FFFFFF_t_70 2]: https://img-blog.csdnimg.cn/20191216182705142.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0RCQ18xMjE=,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0RCQ18xMjE_size_16_color_FFFFFF_t_70 3]: https://img-blog.csdnimg.cn/2019121710552422.jpg?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0RCQ18xMjE=,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0RCQ18xMjE_size_16_color_FFFFFF_t_70 4]: https://img-blog.csdnimg.cn/20191217105643804.jpg?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0RCQ18xMjE=,size_16,color_FFFFFF,t_70