jvm垃圾收集算法

妖狐艹你老母 2022-06-03 23:59 217阅读 0赞

#### **一、标记垃圾** ####

**1、引用计数（ReferenceCounting）算法**  
这种方法比较简单直观，FlashPlayer/Python使用该算法，简单高效。核心思路是，给每个对象添加一个被引用计数器，被引用时+1，引用失效-1，等于0时就表示该对象没有被引用，可以被回收。但是，Java/C\#并不采用该算法，因为该算法没有解决对象相互引用的问题，即：当两个对象相互引用且不被其它对象引用时，各自的引用计数为1，虽不为0，但仍然是可被回收的垃圾对象。

**2、根搜索（GC Roots Tracing）算法**  
基本原理是：GCRoot对象作为起始点（根）。如果从根到某个对象是可达的，则该对象称为“可达对象”（存活对象，不可回收对象）。否则就是不可达对象，可以被回收。

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

#### **二、jvm算法思想以及原理** ####

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

> 最基础的收集算法，分为标记和清除两个阶段。后续的算法都是基于这种思路并对其不足进行改进而得到的。

##### **不足：** #####

>  *  效率：标记和清除两个过程效率都不高
>  *  空间：标记清除完会产生大量碎片，空间碎片导致以后程序运行过程中需要分配较大对象时，无法找到足够的连续内存不得不提前触发另一次垃圾收集动作。

**执行过程：**  
![标记-清除算法][-]

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

#### **2、复制算法（Copying）** ####

##### **不足：** #####

> 为了解决效率问题，复制算法出现。但代价是将内存缩小为原来的一半。很显然，Copying算法的效率跟存活对象的数目多少有很大的关系，如果存活对象很多，那么Copying算法的效率将会大大降低。

**执行过程：**  
![这里写图片描述][SouthEast]

> 很多商用的虚拟机都采用这种算法回收新生代。IBM研究表明，新生代中的对象98%是“朝生夕死”的，所以不需要1：1划分空间。HotSpot 虚拟机默认Eden和survivor大小比例是8：1。每次回收将Eden和survivor中还存活的对象复制到另一个survivor中，因此只浪费的10%的内存。我们也没法保证每次回收只有多余10%的对象存活，当剩余的survivor内存不够时，需要依赖其它内存（老年代）。

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

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

> 为了解决Copying算法的缺陷，充分利用内存空间，提出了Mark-Compact算法。该算法标记阶段和Mark-Sweep一样，但是在完成标记之后，它不是直接清理可回收对象，而是将存活对象都向一端移动，然后清理掉端边界以外的内存。

![这里写图片描述][SouthEast 1]

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

#### **4、分代收集算法（Generational Collection）** ####

> 分代收集算法是目前大部分JVM的垃圾收集器采用的算法。它的核心思想是根据对象存活的生命周期将内存划分为若干个不同的区域。一般情况下将堆区划分为老年代（Tenured Generation）和新生代（Young Generation），老年代的特点是每次垃圾收集时只有少量对象需要被回收，而新生代的特点是每次垃圾回收时都有大量的对象需要被回收，那么就可以根据不同代的特点采取最适合的收集算法。
> 
> 　　目前大部分垃圾收集器对于新生代都采取Copying算法，因为新生代中每次垃圾回收都要回收大部分对象，也就是说需要复制的操作次数较少，但是实际中并不是按照1：1的比例来划分新生代的空间的，一般来说是将新生代划分为一块较大的Eden空间和两块较小的Survivor空间，每次使用Eden空间和其中的一块Survivor空间，当进行回收时，将Eden和Survivor中还存活的对象复制到另一块Survivor空间中，然后清理掉Eden和刚才使用过的Survivor空间。
> 
> 　而由于老年代的特点是每次回收都只回收少量对象，一般使用的是Mark-Compact算法。
> 
> 　　注意，在堆区之外还有一个代就是永久代（Permanet Generation），它用来存储class类、常量、方法描述等。对永久代的回收主要回收两部分内容：废弃常量和无用的类。

#### **三、垃圾收集器** ####

垃圾收集算法是 内存回收的理论基础，而垃圾收集器就是内存回收的具体实现。下面介绍一下HotSpot（JDK 7)虚拟机提供的几种垃圾收集器，用户可以根据自己的需求组合出各个年代使用的收集器。  
　　![这里写图片描述][SouthEast 2]

**1.Serial/Serial Old**

> 　　Serial/Serial Old收集器是最基本最古老的收集器，它是一个单线程收集器，并且在它进行垃圾收集时，必须暂停所有用户线程。Serial收集器是针对新生代的收集器，采用的是Copying算法，Serial Old收集器是针对老年代的收集器，采用的是Mark-Compact算法。它的优点是实现简单高效，但是缺点是会给用户带来停顿。

**2.ParNew**

> 　　ParNew收集器是Serial收集器的多线程版本，使用多个线程进行垃圾收集。

**3.Parallel Scavenge**

> 　　Parallel Scavenge收集器是一个新生代的多线程收集器（并行收集器），它在回收期间不需要暂停其他用户线程，其采用的是Copying算法，该收集器与前两个收集器有所不同，它主要是为了达到一个可控的吞吐量。

**4.Parallel Old**

> 　　Parallel Old是Parallel Scavenge收集器的老年代版本（并行收集器），使用多线程和Mark-Compact算法。

**5.CMS**

> 　　CMS（Current Mark Sweep）收集器是一种以获取最短回收停顿时间为目标的收集器，它是一种并发收集器，采用的是Mark-Sweep算法。

**6.G1**

> 　　G1收集器是当今收集器技术发展最前沿的成果，它是一款面向服务端应用的收集器，它能充分利用多CPU、多核环境。因此它是一款并行与并发收集器，并且它能建立可预测的停顿时间模型。

#### **Heap分区的目的** ####

1.  为了分代：不同代的对象放到不同的内存分区中，实现“代提升”，也方便实现对不同分代采用不同的垃圾收集算法。
2.  垃圾收集算法需要：新生代GC使用到复制算法，该算法需要将对应的分区划分成三个分区：Eden/S0/S1。

术语

> Generation代  
> \- YongGeneration/NewGeneration：新生代，在Eden/S0/S1的存活的对象。  
> \- OldGeneration：老年代，在Tenured区存活的对象。  
> \- PermanentGeneration：永久代。  
> Space 区  
> \- Eden：伊甸园区，是新生代的一个区。  
> \- Survivor：幸存区，属于新生代，为了复制算法的需要。一般分成大小相等的两个区（S0/S1或者From/To）。  
> \- Tenured：存放老年代的区域。  
> \- Permanent：终身区。

下图：Hotspot 的 Heap 分区

![这里写图片描述][SouthEast 3]

下图：VisualVM 中通过 VisualGC插件显示的分区  
![这里写图片描述][SouthEast 4]

对象的内存分配，往大方向上讲就是在堆上分配，对象主要分配在新生代的Eden Space和From Space，少数情况下会直接分配在老年代。如果新生代的Eden Space和From Space的空间不足，则会发起一次GC，如果进行了GC之后，Eden Space和From Space能够容纳该对象就放在Eden Space和From Space。在GC的过程中，会将Eden Space和From Space中的存活对象移动到To Space，然后将Eden Space和From Space进行清理。如果在清理的过程中，To Space无法足够来存储某个对象，就会将该对象移动到老年代中。在进行了GC之后，使用的便是Eden space和To Space了，下次GC时会将存活对象复制到From Space，如此反复循环。当对象在Survivor区躲过一次GC的话，其对象年龄便会加1，默认情况下，如果对象年龄达到15岁，就会移动到老年代中。

一般来说，大对象会被直接分配到老年代，所谓的大对象是指需要大量连续存储空间的对象，最常见的一种大对象就是大数组，比如：  
　　byte\[\] data = new byte\[4\*1024\*1024\]  
　　这种一般会直接在老年代分配存储空间。  
　　当然分配的规则并不是百分之百固定的，这要取决于当前使用的是哪种垃圾收集器组合和JVM的相关参数。

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

***参考：***  
《深入理解Java虚拟机》

[-]: /images/20220604/e46b999981c24c4a8dc885687ad9864e.png
[SouthEast]: /images/20220604/5b57f3af428d4667b0ed9e111829014e.png
[SouthEast 1]: /images/20220604/1bb6b200acec4f95ad5361b629dfcc2f.png
[SouthEast 2]: /images/20220604/43b3d143820e43fb93147fef8e6f80aa.png
[SouthEast 3]: /images/20220604/0d159cf2c7e2486ba3215d938aaaea56.png
[SouthEast 4]: /images/20220604/68f512d583ea4f5da47153f3963dac69.png