京东JDK在大数据平台的探索与研究

本文旨在概述京东在JDK方向上的尝试与探索，以及京东JDK项目背景，基本特性以及未来的工作方向。对于JDK特性的技术讨论，实现细节及效果，将在后续系列文章中深入讨论。

一、HDFS简介

HDFS是作为最底层的分布式存储服务而存在的，是Hadoop的分布式文件系统组件。HDFS是高容错的，被设计成在低成本硬件上部署。HDFS为应用数据提供高吞吐量的访问，适用于具有大规模数据集的应用程序。HDFS采用了基于Master/Slave主从架构的分布式文件系统, 一个HDFS集群包含的Master节点(NameNode)和多个Slave节点(DataNode)服务器，文件以block的形式存储在DataNode节点。NameNode主要负责响应客户端请求，进行文件的打开、关闭、重命名文件和目录，同时决定block到具体Datanode节点的映射。Datanode在Namenode的指挥下进行block的创建、删除和复制。

二、JVM对HDFS的作用

由于HDFS采用Java开发，并运行于JVM上，因此如何从JVM角度提高HDFS的能力是主要研究的方向之一。 从JVM角度看，NameNode节点的特点是进程生命周期长，对象创建频繁，资源利用率高，对于内存的资源要求较高，，NameNode的性能是HDFS性能的关键。DataNode节点的特点是进程生命周期短，多数进程创建后进行对文件块的操作后即退出。如何对JVM进行优化，才能使其更加适用于HDFS NameNode和DataNode的工作特点是京东JDK研发的主要方向。

三、京东对通用JDK的尝试

1. 使用Oracle JDK 1.8的经验

在京东，曾经尝试使用Oracle的JDK1.8做为HDFS的JDK解决方案。经过不断的工作与参数调优，已经使HDFS稳定的运行在OracleJDK1.8环境中。但是，随着京东业务的不断增长，对于HDFS的要求也在不断提高，OracleJDK1.8在以下问题上并不能提供更多的帮助：

• 性能优化：虽然OracleJDK1.8 的JVM中具备很多先进的优化功能，比如tiered compiler, 高效的CMS垃圾收集器等，但其主要针对通用Java程序的性能进行优化，缺少针对分布式工作环境的特定优化。由于无法对oracle JDK1.8的源代码进行修改，通过参数调整并不能从根本上解决问题。
• 不可控的GC： 虽然OracleJDK1.8提供的相当优秀的CMS垃圾收集器，可以有效的提高GC暂停时间带来的性能损失，但在实际使用过程中，发现GC停顿时间仍然不能满足要求，比如YoungGC的时间仍在1秒左右，而OldGC消耗在60秒左右，如果一旦发生FullGC，则经常会导致NameNode暂停时间过长从而导致系统假死，结果往往是灾难性的。
• 内存利用率低：对于NameNode节点，能够使用的物理内存在512GB，而为了避免JVM中老年代GC和Full GC时间过长而导致的灾难性后果，NameNode节点只能配置Java堆在200GB左右。通常NameNode节点的机器上只运行NameNode进程和一个轻量级的ZKFC进程，所以物理内存不能得到有效利用。另一方面，NameNode的承载能力受到Java堆大小的制约，导致HDFS的总体承载能力受限。
• JDK版本更新：随着以上问题的不断显现，同时JDK1.8将在2019年停止更新，同时需要尝试新的JDK以及OpenJDK能否帮助解决问题。

2. 尝试openJDK11

随着openJDK的不断演进，为了缓解上面提到的问题，也尝试了OpenJDK11, 相对于openJDK1.8，发现openJDK11在以下方面可能具备优势：

G1GC： open JDK11采用G1作为默认的GC算法，相对于CMS，G1具备以下优点：

• 更小的内存碎片：由于CMS老年代采用Mark-sweep算法，并不是每次做OldGC都进行Compact，所以CMS老年代空间常常会引入碎片问题。而G1采用分块Copy算法，使得内存碎片问题仅仅在G1的分块中存在，相对于CMS，其内存的利用率更高，发生FullGC和OOM的可能性更低。
• 可控的GC暂停时间：G1算法最大的特点就是它可以让用户提供期望的GC最大暂停时间，在其内部通过统计预测的方法对下一次即将发生的GC算法进行有效的暂停时间的控制，从而优化GC对于性能的损耗。
• 更丰富的性能分析工具：OpenJDK11引入了Java Frame Recorder(JFS)，这是原来oracle JDK1.8商业版才具备的特性，JFR可以在不损耗，或轻微损耗性能的情况下，对Java程序进行sampling，从而帮助分析性能、功能瓶颈和指导优化。
• HDFS更高的负载能力：OpenJDK11由于采用G1作为默认的GC算法，其可以更高效的利用堆内存，同时由于G1算法的设计及优化，其发生FullGC的几率非常低，并且FullGC的暂停时间也得到了优化，所以相对于oracle JDK1.8的CMS，对于HDFS NameNode来说，其负载能力受到堆大小的限制更加宽松。

虽然OpenJDK11能够帮助缓解一系列问题，但对于京东大数据来说，仅使用原生的OpenJDK11仍然缺少针对性的优化，目前主要存在以下问题：

• 针对大堆的优化：由于openJDK上G1内部的一些限制，其针对大堆，如360GB的堆的性能并没有达到最优。
• 针对大堆的工具开发：以JMap为例，当堆内存很大的时候，一次JMap操作便利整个堆内存耗时巨大，我们经常遇到JMap导致假死的情况。
• 针对HDFS的定制化工作：另外，目前仍然希望JDK具备一些可利用的特性帮助我们对HDFS在问题分析，危机处理以及线上分析方面的能力进行增强。

四、京东定制化JDK

经过以上尝试，结合HDFS业务特点及优化需求。最终决定在OpenJDK11的基础上，对openjdk进行有针对性的开发和优化，打造京东的定制化JDK。

1. 京东JDK特性介绍

除openJDK11具备的特性外，目前京东JDK主要具备以下能力：

(1) JDK8 兼容性支持 javah：

由于JDK8具备Javah工具能供根据Java的类定义文件生成相应JNI实现所需的C/C++头文件。在大型项目中，如Hadoop，Yarn都会利用Javah进行JNI头文件的生成。从JDK10开始，javah工具在JDK中被移除，取而代之的是javac –h功能，但由于javac –h在使用上不同于javah，并且在复杂的项目中，要想用javac –h 代替javah, 必须要修改编译系统，工作量和难度都比较大。为了在京东内部流畅的进行JDK升级，重写了javah，使其能成功的利用javac –h进行JNI头文件的生成。

(2) 扩大G1 region size：

（编辑：青岛站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!