五分钟了解Java10针对垃圾收集的改进

Java10 已经发布了大概有一个多月了。我们在之前的文中介绍过10为我们带来的一些新特性： JDK10要来了：下一代 Java 有哪些新特性？。其中就提到了10 关于G1垃圾收集器的一些改进。G1在Java 9的时候已经是被作为默认的垃圾收集器了。如果你了解G1的话，应该知道它是一个更注重低停顿的收集器。有关G1的内容你可以移步 一步步图解G1。

那么在10中针对垃圾回收都有哪些改进和改变呢？

严格的来说有两处是与垃圾回收有关的：

分别是JEP304和JEP307。

JEP 304: 垃圾回收器接口（Garbage Collector Interface）

就是引入了一个一个垃圾回收器的接口。让Hotspot虚拟机的模块化水平得到了进一步的提高，让我们可以轻松的添加一个新的GC或者排除掉JDK内部自带的现存的某个GC，总之，就是解耦了。

在Java10 之前，垃圾回收器的代码被分散到很多地方，这一点，那一点，你如果要想自己实现一个全新的GC，必须得了解这些需要改动的地方。简直牵一发而动全身，耦合。

如今有了这个接口你就轻松了。有关这个接口的内容我们就不多赘述了。你可以移步此文了解： JDK10要来了：下一代 Java 有哪些新特性？

接下来我们重点说说10针对G1的改进。

JEP 307: G1的Full GC多线程

这个JEP的目标只有一个，那就是要把G1的full GC算法给并行化，从而提高性能。

你知道，G1最大的亮点就是可以尽量的避免full gc。但毕竟是“尽量”，在有些情况下，G1就要进行full gc了，比如如果它无法足够快的回收内存的时候，它就会强制停止所有的应用线程然后清理。在Java10之前，一个单线程版的标记-清除-压缩算法被用于full gc。

所以为了尽量减少full gc带来的影响，在Java10中，就把之前的那个单线程版的标记-清除-压缩的full gc算法改成了支持多个线程同时full gc。这样也算是减少了full gc所带来的停顿。

你可以通过-XX:ParallelGCThreads这个参数来指定用于并行GC的线程数。