Skip to content

Instantly share code, notes, and snippets.

@tw-Frey
Created August 16, 2023 09:56
Show Gist options
  • Save tw-Frey/9915b2f48d0f2bc4de3467abcbc6b5ce to your computer and use it in GitHub Desktop.
Save tw-Frey/9915b2f48d0f2bc4de3467abcbc6b5ce to your computer and use it in GitHub Desktop.
JDK 18 GC垃圾回收机制比较

https://www.jdon.com/61051.html

从 JDK 18 开始,JDK 附带了四个垃圾收集器 (GC);串行 GC、并行 GC、G1 GC 和 ZGC。在大多数情况下,默认的 GC G1 GC 将是最佳选择。但是,了解 GC 的设计目标可能会有所帮助,并且可能会帮助您实现应用程序的性能目标。本文将对每个 GC 以及何时应该使用它们进行高级研究。

串行垃圾收集器

Serial GC 是 GC 中“最简单的”。它在单个线程上执行所有工作,因此它被命名为“串行”。 Serial GC 最适合在资源有限且 live set 不超过 100 MB 的环境中运行的应用程序。 可以使用 VM 标志启用串行 GC -XX:+UseSerialGC

并行垃圾收集器

Parallel GC 在架构上类似于 Serial GC,但在执行其工作时可以使用多个线程。 并行 GC 旨在最大限度地提高吞吐量。因此,吞吐量是最高优先级的应用程序,即使以更长的暂停时间为代价,也是理想的用例。 可以使用 VM 标志启用并行 GC -XX:+UseParallelGC

G1 垃圾收集器

Garbage-First, (G1) GC 被指定为 JDK 9 1的默认 GC 。G1 GC 主要是并发 GC,这意味着它可以在应用程序运行时执行工作。 G1 GC 试图在延迟和吞吐量之间取得平衡,并且可以从资源最少的环境扩展到具有大量资源的环境。 G1 GC 是默认 GC,但可以使用 VM 标志显式启用:-XX:+UseG1GC

Z 垃圾收集器

最新的 GC ZGC 作为 JDK 15 中的生产特性引入。ZGC 也是并发 GC。 ZGC 专注于低延迟,暂停时间很少超过 250 微秒,并且可以将堆大小从 8MB 扩展到 16TB。 可以使用 VM 标志启用 ZGC -XX:+UseZGC

be57eaa7d4734da1ba407c103dbb1e57~tplv-obj 2048 1152

@tw-Frey
Copy link
Author

tw-Frey commented Aug 16, 2023

Java 8 最快的垃圾搜集器是什么?

https://m.imooc.com/article/42809

PS
原文链接(已失效)

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

基准测试方法

运行相同的代码六次,每次使用不同的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 之后就会回收这些对象。

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

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

基准测试结果

执行结果

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

5b421f6f00018d2b08000600

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

原始基准测试数据

5b421f700001f5cd09690329

相对基准测试数据

5b421f700001bdfb09060289

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)通常情况是最好的选择。

其他參考
https://www.optaplanner.org
https://www.optaplanner.org/code/sourceCode.html
https://github.com/kiegroup/optaplanner

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment