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

DD的博客全面升级,阅读体验更佳(尤其是系列教程),后续不再通过这里发布新文章,而是改到 www.didispace.com 发布啦,奔走相告!点击直达~

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的线程数。

本文作者:贺卓凡,
原文链接:https://mp.weixin.qq.com/s/bE7ni5c0T5LMJ04UzyBRrg
版权归作者所有,转载请注明作者、原文、译者等出处信息