Java中的垃圾回收

Myth丶恋晨 2022-08-21 06:38 139阅读 0赞

链接：http://it.deepinmind.com/gc/2016/04/19/garbage-collection-in-java.html

原文：https://plumbr.eu/handbook/garbage-collection-in-java

### 碎片及整理（Fragmenting and Compacting） ###

JVM在清除不可达对象之后，还得确保它们所在的空间是可以进行复用的。对象删除会导致碎片的出现，这有点类似于磁盘碎片，这会带来两个问题：

*  写操作会变得更加费时，因为查找下一个可用空闲块已不再是一个简单操作。
 *  JVM在创建新对象的，会在连续的区块中分配内存。因此如果碎片已经严重到

没有一个空闲块能足够容纳新创建的对象时，内存分配便会报错。

为了避免此类情形，JVM需要确保碎片化在可控范围内。因此，在垃圾回收的过程中，除了进行标记和删除外，还有一个“内存去碎片化”的过程。在这个过程当中，会给可达对象重新分配空间，让它们互相紧挨着对方，这样便可以去除碎片。下图展示的便是这一过程：

![640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1][]

###     ###

### 分代假设 ###

如前所述，垃圾回收需要完全中止应用运行。显然，对象越多，回收的时间也越长。那么我们能不能在更小的内存区域上进行回收呢？通过可行性调查，一组研究人员发现应用中绝大多数的内存分配会分为两大类：

*  绝大部分的对象很快会变为不可用状态。
 *  还有一些，它们的存活时间通常也不会很长。

这些结论最终构成了弱分代假设（Weak Generational Hypothesis）。基于这一假设，虚拟机内的内存被分为两类，新生代（Young Generation)及老生代（Old Generation)。后者又被称为年老代（Tenured Generation）。

![Image 1][]

有了各自独立的可清除区域后，这才出现了众多不同的回收算法，正是它们一直以来在持续提升着GC的性能。

这并不说明这样的方式是没有问题的。比如说，不同分代中的对象可能彼此间有引用，在进行分代回收时，它们便为视为是“事实上”的GC根对象（GC roots)。

而更为重要的是，分代假设对于某些应用来说并不成立。由于GC算法主要是为那些“快速消失”或者“永久存活”的对象而进行的优化，因此对于那些生命周期“适中的对象，JVM就显得无能为力了。

### 内存池 ###

在堆里面进行内存池的划分对大家来说应该是非常熟悉的了。不过大家可能不太清楚的是在不同的内存池中，垃圾回收是如何履行它的职责的。值得注意的是，虽然不同的GC算法细节实现上有所不同，但是本章中所提到的概念却是大同小异的。

![640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1 1][]

####     ####

#### 伊甸区（Eden) ####

新对象被创建时，通常便会被分配到伊甸区。由于通常都会有多个线程在同时分配大量的对象，因为伊甸区又被进一步划分成一个或多个线程本地分配缓冲（Thread Local Allocation Buffer，简称TLAB）。有了这些缓冲区使得JVM中大多数对象的分配都可以在各个线程自己对应的TLAB中完成，从而避免了线程间昂贵的同步开销。

如果在TLAB中无法完成分配（通常是由于没有足够的空间），便会到伊甸区的共享空间中进行分配。如果这里还是没有足够的空间，则会触发一次新生代垃圾回收的过程来释放空间。如果垃圾回收后伊甸区还是没有足够的空间，那么这个对象便会到老生代中去分配。

当进行伊甸区的回收时，垃圾回收器会从根对象开始遍历所有的可达对象，并将它们标记为存活状态。

前面我们已经提到，对象间可能会存在跨代引用，因此最直观的做法便是扫描其它分区到伊甸区的所有引用。但不幸的是这么做会做成分代的做法变得毫无意义。JVM对此有它自己的妙招：卡片式标记（card-marking）。基本的做法是，JVM将伊甸区中可能存在老生代引用的对象标记为"脏”对象。关于这点Nitsan的博客这里有更进一步的介绍。

![640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1 2][]

标记完成后，所有存活对象会被复制到其中的一个存活区。于是整个伊甸区便可认为是清空了，又可以重新用来分配对象了。这一过程便被称为”标记复制“：存活对象先被标记，随后被复制到存活区中。

#### 存活区(Survivor) ####

紧挨着伊甸区的是两个存活区，分别是from区和to区。值得一提的是其中的一个存活区始终都是空的。

空的存活区会在下一次新生代GC的时候迎来它的居民。整个新生代中的所有存活对象（包含伊甸区以及那个非空的名为from的存活区）都会被复制到to区中。一旦完成之后，对象便都跑到to区中而from区则被清空了。这时两者的角色便会发生调转。

![Image 1][]

存活对象会不断地在两个存活区之间来回地复制，直到其中的一些对象被认为是已经成熟，“足够老”了。请记住这点，基于分代假设，已经存活了一段时间的对象，在相当长的一段时间内仍可能继续存活。

这些“年老”的对象会被提升至老年代空间。出现对象提升的时候，这些对象则不会再被复制到另一个存活区，而是直接复制到老年代中，它们会一直待到不再被引用为止。

垃圾回收器会跟踪每个对象历经的回收次数，来判断它们是否已经“足够年老”，可以传播至老年代中。在一轮GC完成之后，每个分区中存活下来的对象的计数便会加一。当一个对象的年龄超过了一个特定的年老阈值之后，它便会被提升到老年代中。

JVM会动态地调整实际的年龄阈值，不过通过指定-

XX:+MaxTenuringThreshold参数可以给该值设置一个上限。将-XX:+MaxTenuringThreshold设置为0则立即触发对象提升，而不会复制到存活区中。在现代的JVM中，这个值默认会被设置为15个GC周期。在HotSpot虚拟机中这也是该值的上限。

如果存活区的大小不足以存放所有的新生代存活对象，则会出现过早提升。

####     ####

#### 老生代 ####

老生代的内存空间的实现则更为复杂。老生代的空间通常都会非常大，里面存放的对象都是不太可能会被回收的。

老生代的GC比新生代的GC发生的频率要少得多。由于老生代中的多数对象都被认为是存活的，也就不会存在标记-复制操作了。在GC中，这些对象会被挪到一起以减少碎片。老生代的回收算法通常都是根据不同的理论来构建的。不过大体上都会分成如下几步：

*  标记可达对象，设置GC根对象可达的所有对象后的标记位
 *  删除不可达对象
 *  整理老生代空间的对象，将存活对象复制到老生代开始的连续空间内。

从以上描述中可知，为了避免过度碎片化，老生代的GC是明确需要进行整理操作的。

#### 持久代 ####

在Java 8以前还有一个特殊的空间叫做持久代（Permanent Generation）。这是元数据比如类相关数据存放的地方。除此之外，像驻留的字符串（internalized string）也会被存放在持久代中。这的确给Java开发人员带来了不少麻烦事，因为很难评估这究竟会使用到多少空间。评估不到位偏会抛出java.lang.OutOfMemoryError: Permgen space的异常。只要不是真的因为内存泄漏而引起的OutOfMemoryError异常，可以通过增加持久代空间的大小来解决这一问题，比如下例中的把持久代最大空间设置为256MB：

> java -XX:MaxPermSize=256m com.mycompany.MyApplication

####     ####

#### 元空间 ####

由于元数据空间大小的预测是件繁琐且低效的工作，于是Java 8中干脆就去掉了持久代，转而推出了元空间。从此以后，那些个杂七杂八的东西便都存储到正常的Java堆了。

但是，类定义如今则是存储到了元空间里。它存储在本地内存中，不会与堆 内存相混杂。默认情况下，元空间的大小只受限于Java进程的可用本地内存的大小。这大大解放了开发人员，他们不会再因为多增加了一个类而引发java.lang.OutOfMemoryError: Permgen space异常了。值得注意的是，虽然看似元空间大小毫无限制了，但这一些并非是没有代价的——如果任由元空间无节制地增长，你可能会面临的是频繁的内存交换（swapping）或者是本地内存分配失败。

如果你希望避免此类情况，可以像下例中这样限制一下元空间的大小，将它设置成比如256MB：

> java -XX:MaxMetaspaceSize=256m com.mycompany.MyApplication

### 新生代GC(Minor GC) vs 老生代GC(Major GC） vs Full GC ###

清除堆内存不同区域的垃圾回收事件又被称为新生代GC,老生代GC，以及Full GC事件。本章我们将介绍一下不同事件的区别在哪里。不过你会发现其实各自的差别并不是那么重要。

重要的是我们希望知道应用是否到达它的服务能力上限了，而这又只能去监控应用的处理延时或者吞吐量。只有在这个时间GC事件才能派上用场。这些事件的关键之处在于它们是否停止了应用的运行，以及停了多久。

不过由于新生代GC,老生代GC，Full GC这几个术语被广泛使用却又没有一个清晰的定义，我们还是先来详细地介绍一下它们的区别再说吧。

#### 新生代GC ####

新生代垃圾的回收被称作Minor GC。这个定义非常清晰，理解起来也不会有什么歧义。不过当处理新生代GC事件时，还是有一些有意思的东西值得注意的：

*  只要JVM无法为新创建的对象分配空间，就肯定会触发新生代GC，比方说Eden区满了。因此对象创建得越频繁，新生代GC肯定也更频繁。
 *  一旦内存池满了，它的所有内容就会被拷贝走，指针又将重新归零。因此和经典的标记(Mark)，清除(Sweep)，整理(Compact)的过程不同的是，Eden区和Survivor区的清理只涉及到标记和拷贝。在它们中是不会出现碎片的。写指针始终在当前使用区的顶部。
 *  在一次新生代GC事件中，通常不涉及到年老代。年老代到年轻代的引用被认为是GC的根对象。而在标记阶段中，从年轻代到年老代的引用则会被忽略掉。
 *  和通常所理解的不一样的是，所有的新生代GC都会触发“stop-the-world”暂停，这会中断应用程序的线程。对绝大多数应用而言，暂停的时间是可以忽略不计的。如果Eden区中的大多数对象都是垃圾对象并且永远不会被拷贝到Survivor区/年老代中的话，这么做是合理的。如果恰好相反的话，那么绝大多数的新生对象都不应该被回收，新生代GC的暂停时间就会变得相对较长了。

现在来看新生代GC还是很清晰的——每一次新生代GC都会对年轻代进行垃圾清除。

#### 老年代GC与Full GC ####

你会发现关于这两种GC其实并没有明确的定义。JVM规范或者垃圾回收相关的论文中都没有提及。不过从直觉来说，根据新生代GC(Minor GC)清理的是新生代空间的认识来看，不难得出以下推论（这里应当从英文出发来理解，Minor, Major与Full GC，翻译过来的名称已经带有明显的释义了）：

*  Major GC清理的是老年代的空间。
 *  Full GC清理的是整个堆——包括新生代与老年代空间

不幸的是这么理解会有一点复杂与困惑。首先——许多老年代GC其实是由新生代GC触发的，因此在很多情况下两者无法孤立来看待。另一方面——许多现代的垃圾回收器会对老年代进行部分清理，因此，使用“清理”这个术语则显得有点牵强。

那么问题就来了，先别再纠结某次GC到底是老年代GC还是Full GC了，你应该关注的是这次GC是否中断了应用线程还是能够和应用线程并发地执行。

即便是在JVM的官方工具中，也存在着这一困扰。通过一个例子来说明应该更容易理解一些。我们用两款工具来跟踪某个运行着CMS回收器的JVM，来比较下它们的输出有什么不同：

首先通过jstat的输出来查看下GC的信息：

> my-precious: me$ jstat -gc -t 4235 1s

> Time S0C    S1C    S0U    S1U      EC       EU        OC         OU       MC     MU    CCSC   CCSU   YGC     YGCT    FGC    FGCT     GCT   
> 
>  5.7 34048.0 34048.0  0.0   34048.0 272640.0 194699.7 1756416.0   181419.9  18304.0 17865.1 2688.0 2497.6      3    0.275   0      0.000    0.275
> 
>  6.7 34048.0 34048.0 34048.0  0.0   272640.0 247555.4 1756416.0   263447.9  18816.0 18123.3 2688.0 2523.1      4    0.359   0      0.000    0.359
> 
>  7.7 34048.0 34048.0  0.0   34048.0 272640.0 257729.3 1756416.0   345109.8  19072.0 18396.6 2688.0 2550.3      5    0.451   0      0.000    0.451
> 
>  8.7 34048.0 34048.0 34048.0 34048.0 272640.0 272640.0 1756416.0  444982.5  19456.0 18681.3 2816.0 2575.8      7    0.550   0      0.000    0.550
> 
>  9.7 34048.0 34048.0 34046.7  0.0   272640.0 16777.0  1756416.0   587906.3  20096.0 19235.1 2944.0 2631.8      8    0.720   0      0.000    0.720
> 
> 10.7 34048.0 34048.0  0.0   34046.2 272640.0 80171.6  1756416.0   664913.4  20352.0 19495.9 2944.0 2657.4      9    0.810   0      0.000    0.810
> 
> 11.7 34048.0 34048.0 34048.0  0.0   272640.0 129480.8 1756416.0   745100.2  20608.0 19704.5 2944.0 2678.4     10    0.896   0      0.000    0.896
> 
> 12.7 34048.0 34048.0  0.0   34046.6 272640.0 164070.7 1756416.0   822073.7  20992.0 19937.1 3072.0 2702.8     11    0.978   0      0.000    0.978
> 
> 13.7 34048.0 34048.0 34048.0  0.0   272640.0 211949.9 1756416.0   897364.4  21248.0 20179.6 3072.0 2728.1     12    1.087   1      0.004    1.091
> 
> 14.7 34048.0 34048.0  0.0   34047.1 272640.0 245801.5 1756416.0   597362.6  21504.0 20390.6 3072.0 2750.3     13    1.183   2      0.050    1.233
> 
> 15.7 34048.0 34048.0  0.0   34048.0 272640.0 21474.1  1756416.0   757347.0  22012.0 20792.0 3200.0 2791.0     15    1.336   2      0.050    1.386
> 
> 16.7 34048.0 34048.0 34047.0  0.0   272640.0 48378.0  1756416.0   838594.4  22268.0 21003.5 3200.0 2813.2     16    1.433   2      0.050    1.484
> 
> 这段输出是从JVM启动后第17秒开始截取的。从中可以看出，在经过了12次新生代GC后出现了两次Full GC，共耗时50ms。通过GUI的工具也可以获取到同样的信息，比如说jsonsole或者是jvisualvm。

在接受这一结论前，我们再来看下同样是这次JVM启动后所输出的GC日志。很明显-XX:+PrintGCDetails给我们讲述的是一段截然不同却更为详尽的故事：

> java -XX:+PrintGCDetails -XX:+UseConcMarkSweepGC eu.plumbr.demo.GarbageProducer

> 3.157: \[GC (Allocation Failure) 3.157: \[ParNew: 272640K->34048K(306688K), 0.0844702 secs\] 272640K->69574K(2063104K), 0.0845560 secs\] \[Times: user=0.23 sys=0.03, real=0.09 secs\] 
> 
> 4.092: \[GC (Allocation Failure) 4.092: \[ParNew: 306688K->34048K(306688K), 0.1013723 secs\] 342214K->136584K(2063104K), 0.1014307 secs\] \[Times: user=0.25 sys=0.05, real=0.10 secs\] 
> 
> ... cut for brevity ...
> 
> 11.292: \[GC (Allocation Failure) 11.292: \[ParNew: 306686K->34048K(306688K), 0.0857219 secs\] 971599K->779148K(2063104K), 0.0857875 secs\] \[Times: user=0.26 sys=0.04, real=0.09 secs\] 
> 
> 12.140: \[GC (Allocation Failure) 12.140: \[ParNew: 306688K->34046K(306688K), 0.0821774 secs\] 1051788K->856120K(2063104K), 0.0822400 secs\] \[Times: user=0.25 sys=0.03, real=0.08 secs\] 
> 
> 12.989: \[GC (Allocation Failure) 12.989: \[ParNew: 306686K->34048K(306688K), 0.1086667 secs\] 1128760K->931412K(2063104K), 0.1087416 secs\] \[Times: user=0.24 sys=0.04, real=0.11 secs\] 
> 
> 13.098: \[GC (CMS Initial Mark) \[1 CMS-initial-mark: 897364K(1756416K)\] 936667K(2063104K), 0.0041705 secs\] \[Times: user=0.02 sys=0.00, real=0.00 secs\] 
> 
> 13.102: \[CMS-concurrent-mark-start\]
> 
> 13.341: \[CMS-concurrent-mark: 0.238/0.238 secs\] \[Times: user=0.36 sys=0.01, real=0.24 secs\] 
> 
> 13.341: \[CMS-concurrent-preclean-start\]
> 
> 13.350: \[CMS-concurrent-preclean: 0.009/0.009 secs\] \[Times: user=0.03 sys=0.00, real=0.01 secs\] 
> 
> 13.350: \[CMS-concurrent-abortable-preclean-start\]
> 
> 13.878: \[GC (Allocation Failure) 13.878: \[ParNew: 306688K->34047K(306688K), 0.0960456 secs\] 1204052K->1010638K(2063104K), 0.0961542 secs\] \[Times: user=0.29 sys=0.04, real=0.09 secs\] 
> 
> 14.366: \[CMS-concurrent-abortable-preclean: 0.917/1.016 secs\] \[Times: user=2.22 sys=0.07, real=1.01 secs\] 
> 
> 14.366: \[GC (CMS Final Remark) \[YG occupancy: 182593 K (306688 K)\]14.366: \[Rescan (parallel) , 0.0291598 secs\]14.395: \[weak refs processing, 0.0000232 secs\]14.395: \[class unloading, 0.0117661 secs\]14.407: \[scrub symbol table, 0.0015323 secs\]14.409: \[scrub string table, 0.0003221 secs\]\[1 CMS-remark: 976591K(1756416K)\] 1159184K(2063104K), 0.0462010 secs\] \[Times: user=0.14 sys=0.00, real=0.05 secs\] 
> 
> 14.412: \[CMS-concurrent-sweep-start\]

从以上能够看出，在运行了12次新生代GC后的确出现了一些“不太寻常”的事情。但并不是执行了两次Full GC，这个“不寻常”的事情其实只是在年老代中执行了一次包含了数个阶段的GC而已：

*  初始标记阶段，从0.0041705 秒或者说4ms的时候开始。这一阶段是一次“stop-the-world”事件，所有的应用线程都被暂停以便进行初始标记。
 *  并发地执行标记和预清理(Preclean)的阶段。这是和应用线程一起并发执行的。
 *  最终标记阶段，从0.0462010秒或者说46毫秒的时候开始。这一阶段也同样是“stop-the-world”的。
 *  并发地进行清除操作。正如名字所说的，这一阶段也无需中断应用线程，可以并发地执行。

因此我们从实际的GC日志中所看到的是这样——其实没有什么两次所谓的Full GC,只有一次清理年老代空间的Major GC而已。

如果你再看下jstat输出的结果，就不难得出结论了。它确切地指出了两次stop-the-world事件，总耗时50ms，这段时间内所有活跃线程都会出现延迟响应。不过如果你想据此来优化吞吐量的话，很可能会徒劳无功——jstat只列出了两次stop-the-world的初始标记及最终标记的部分，而并发执行的那部分工作却被它给隐藏掉了。

[640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1]: /images/20220724/9963d0b2b25440e1ae11cba6461f8d26.png
[Image 1]: 
[640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1 1]: /images/20220724/a06c6e68180b432888b7c15a57c8ec29.png
[640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1 2]: /images/20220724/6b4173270a6b4149965d8203827635ef.png