某某茶叶有限公司欢迎您!
金沙棋牌在线 > 金沙棋牌在线 > [转]八、垃圾搜集器精解(让你在垃圾搜集器的世界里耍的游刃有余)

[转]八、垃圾搜集器精解(让你在垃圾搜集器的世界里耍的游刃有余)

时间:2019-12-29 06:38

OpenJDK 8 有多种 GC(Garbage Collector)算法,如 Parallel GC、CMS 和 G1。哪一个才是最快的呢?如果在 Java 9 中将 Java 8 默认的 GC 从 Parallel GC 改为 G1 (目前只是建议)将会怎么样呢?让我们对此进行基准测试。

版权声明
作者:zuoxiaolong(左潇龙)
出处:博客园左潇龙的技术博客--http://www.cnblogs.com/zuoxiaolong
您的支持是对博主最大的鼓励,感谢您的认真阅读。
本文版权归作者所有,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出原文连接,否则保留追究法律责任的权利。
原文链接:http://www.cnblogs.com/zuoxiaolong/p/jvm8.html

基准测试方法

运行相同的代码六次,每次使用不同的VM参数(-XX:+UseSerialGC, -XX:+UseParallelGC, -XX:+UseConcMarkSweepGC, -XX:ParallelCMSThreads=2, -XX:ParallelCMSThreads=4, -XX:+UseG1GC)。

每次运行大概花费55分钟。

其它VM参数:-Xmx2048M -server

OpenJDK版本:1.8.0_51(当前最新的版本)

软件:Linux version 4.0.4-301.fc22.x86_64

硬件:Intel? Core? i7-4790 CPU @ 3.60GHz

每次运行13个?OptaPlanner?规划问题方案。每次运行时间为5分钟。前30秒用于JVM预热,不计算在内。

解决规划问题不涉及 IO (除了启动时需要几毫秒来加载输入信息)。单个 CPU 使用完全饱和。通常会创建许多存活时间很短的对象,GC 之后就会回收这些对象。

衡量标准可以是计算每毫秒的得分,越高越好。计算一个拟议规划解决方案是一个不可小觑的问题:涉及到大量的计算,包括每个实体与其他所有实体的冲突检测。

为了能在本地重复运行这些基准测试,可以从源码进行构建,然后运行主类 GeneralOptaPlannerBenchmarkApp。

引言

在上一章我们已经探讨过hotspot上垃圾搜集器的实现,一共有六种实现六种组合。本次LZ与各位一起探讨下这六种搜集器各自的威力以及组合的威力如何。

为了方便各位的观看与对比,LZ决定采用当初写设计模式时使用的方式,针对某些搜集器,分几个维度去解释这些搜集器。

基准测试结果

执行结果

为了方便查看,我已经对每种 GC 与 Java 8 默认 GC(Parallel GC)进行了比较。

图片 1

结果非常清楚:默认(Parallel GC)是最快的

原始基准测试数据

图片 2

相对基准测试数据
图片 3

client模式与server模式

在介绍本章内容之前,要说一下JVM的两种模式,一种是client模式,一种是server模式。我们平时开发使用的模式默认是client模式,也可以使用命令行参数-server强制开启server模式,两者最大的区别在于在server模式下JVM做了很多优化。

server模式下的JAVA应用程序启动较慢,不过由于server模式下JVM所做的优化,在程序长时间运行下,运行速度将会越来越快。相反,client模式下的JAVA应用程序虽然启动快,但不适合长时间运行,若是运行时间较长的话,则会在性能上明显低于server模式。

Java 9 默认应该为 G1 吗?

有一种提议是在 OpenJDK9 的服务器端使用 G1 作为默认 GC。我第一反应就是拒绝该提议:

G1 的平均值要慢17.60%

G1 在每个数据集用例下都比较慢。

在最大数据集(Machine Reassignment B10)下,表现比其它数据集都要差,G1 慢了34.07%。

如果在开发机和服务器之间采用不同的默认 GC,则开发者基准测试的可信度就会下降。

另一方面,存在几个需要注意的细节:

G1 关注是 GC 暂停的问题,而不是吞吐量。对于这些用例(计算量比较大),GC 暂停时长基本没影响。

这是一个(基本是)单线程的基准测试。并行解决多个问题或采用多线程解决的基准测试,结果可能不同。

G1 推荐的堆内存至少是 6GB。而这次基准测试的堆内存是 2GB,即使在最大数据集(Machine Reassignment B10)也只需要这么多内存。

海量计算只是 OpenJDK 的诸多功能中的一个:这是在社区广泛争论的一个问题。如果有其他方面(如网站服务)的证明,可能值得改变默认GC。但是,请首先向我展示你实际项目的基准测试。

搜集器详解

以下我们先探讨一下单个垃圾搜集器的相关内容,最后我们再简单的谈一下组合之后,各个组合的特点。

结论

在 Java 8 中,对 OptaPlanner 用例来说,默认 GC(Parallel GC)通常情况是最好的选择。

Serial Garbage Collector

算法:采用复制算法

内存区域:针对新生代设计

执行方式:单线程、串行

执行过程:当新生代内存不够用时,先暂停全部用户程序,然后开启一条GC线程使用复制算法对垃圾进行回收,这一过程中可能会有一些对象提升到年老代

特点:由于单线程运行,且整个GC阶段都要暂停用户程序,因此会造成应用程序停顿时间较长,但对于小规模的程序来说,却非常适合。

适用场景:平时的开发与调试程序使用,以及桌面应用交互程序。

开启参数:-XX:+UseSerialGC(client模式默认值)

Serial Old Garbage Collector

这里针对serial old搜集器不再列举各个维度的特点,因为它与serial搜集器是一样的,区别是它是针对年老代而设计的,因此采用标记/整理算法。对于其余的维度特点,serial old与serial搜集器一模一样。

ParNew Garbage Collector

算法:采用复制算法

内存区域:针对新生代设计

执行方式:多线程、并行

执行过程:当新生代内存不够用时,先暂停全部用户程序,然后开启若干条GC线程使用复制算法并行进行垃圾回收,这一过程中可能会有一些对象提升到年老代

特点:采用多线程并行运行,因此会对系统的内核处理器数目比较敏感,至少需要多于一个的处理器,有几个处理器就会开几个线程(不过线程数是可以使用参数-XX:parallelGCThreads=<N>控制的),因此只适合于多核多处理器的系统。尽管整个GC阶段还是要暂停用户程序,但多线程并行处理并不会造成太长的停顿时间。因此就吞吐量来说,ParNew要大于serial,在处理器越多的时候,效果越明显。但是这并非绝对,对于单个处理器来说,由于并行执行的开销(比如同步),ParNew的性能将会低于serial搜集器。不仅是单个处理器的时候,如果在容量较小的堆上,甚至在两个处理器的情况下,ParNew的性能都并非一定可以高过serial。

适用场景:在中到大型的堆上,且系统处理器至少多于一个的情况

开启参数:-XX:+UseParNewGC