JDK从8升级到11，使用 G1 GC，HBase性能下降20%。JDK 到底干了什么

编者按：笔者在 HBase 业务场景中尝试将 JDK 从 8 升级到 11，使用 G1 GC 作为垃圾回收器，但是性能下降 20%。到底是什么导致了性能衰退？又该如何定位解决？本文介绍如果通过使用 JFR、火焰图等工具确定问题，最后通过版本逐一验证找到了引起性能问题的代码。在毕昇 JDK 众人率先修复问题最后将修复推送到上游社区中。希望通过本文的介绍让读者了解到如何解决大版本升级中遇到的性能问题；同时也提醒 Java 开发者要正确地使用参数（使用前要理解参数的含义）。
HBase 从 2.3.x 开始正式默认的支持 JDK 11，HBase 对于 JDK 11 的支持指的是 HBase 本身可以通过 JDK 11 编译、同时相关的测试用例全部通过。由于 HBase 依赖 Hadoop 和 Zookeeper，而目前最新的 Hadoop 和 Zookeeper 尚未支持 JDK 11，所以 HBase 中仍然有一个 jira 来关注 JDK 11 支持的问题。

具体参考：
https://issues.apache.org/jira/browse/HBASE-22972。

G1 GC 从 JDK 9 以后就成为默认的 GC，而且 HBase 在新的版本中也采用 G1 GC，对于 HBase 是否可以在生产环境中使用 JDK 11？笔者尝试使用 JDK 11 来运行新的 HBase，验证 JDK 11 是否比 JDK 8 有优势。

1环境介绍

验证的方式非常简单，搭建一个 3 节点的 HBase 集群，安装 HBase，采用的版本为 2.3.2，关于 HBase 环境搭建可以参考官网。

另外为了验证，使用一个额外的客户端机器，通过 HBase 自带的 PerformanceEvaluation 工具（简称 PE）来验证 HBase 读、写性能。PE 支持随机的读、写、扫描，顺序读、写、扫描等。

例如一个简单的随机写命令如下：

hbase org.apache.hadoop.hbase.PerformanceEvaluation --rows=10000 --valueSize=8000 randomWrite 5

该命令的含义是：创建 5 个客户端，并且执行持续地写入测试。每个客户端每次写入 8000 字节，共写入 10000 行。

PE 使用起来非常简单，是 HBase 压测中非常流行的工具，关于 PE 更多的用法可以参考相关手册。

本次测试为了验证读写性能，采用如下配置：

org.apache.hadoop.hbase.PerformanceEvaluation --writeToWAL=true --nomapred --size=256 --table=Test1 --inmemoryCompaction=BASIC --presplit=50 --compress=SNAPPY sequentialWrite 120

JDK 采用 JDK 8u222 和 JDK 11.0.8 分别进行测试，当切换 JDK 时，客户端和 3 一 HBase 服务器统一切换。JDK 的运行参数为：

-XX:+PrintGCDetails -XX:+UseG1GC -XX:MaxGCPauseMillis=100 -XX:-ResizePLAB

注意：这里禁止 ResizePLAB 是业务根据 HBase 优化资料设置。

2测试结果：JDK 11性能下降

通过 PE 进行测试，运行结束有 TPS 数据，表示性能。

在相同的硬件环境、相同的 HBase，仅仅使用不同的 JDK 来运行。同时为了保证结果的准确性，多次运行，取平均值。测试结果如下：

从表中可以快速地计算得到吞吐量下降，运行时间增加。