京东JDK在大数据平台的探索与研究
|
JDK12特性，有效减少及控制G1停顿时间。G1GC的主要设计目标是保证G1的停顿时间在可控的范围内，用户可以通过-XX:MaxGCPauseMills参数来指定G1的最大停顿时间，G1GC会尽量尝试保证每次GC的时间不会超过-XX:MaxGCPauseMills。在JVM内部，G1GC在Concurrent 阶段会根据最大停顿时间来选择需要回收的集合(Collect Set)，然后在暂停阶段回收这些集合中的对象。 在JDK11版本中，Collection Set一旦确定就无法改变，但由于Collection Set是JVM根据历史GC信息推断出的，因此如果推断与真实情况的误差过大，会导致MixGC(oldGC)的暂停时间过长，远超过-XX:MaxGCPauseMills设定的目标。 京东JDK从JDK12引入了JEP344特性—Abortable Mixed Collections for G1,该特性可以将Collection Set分解为“必须回收”和“可选择回收”的两部分，在发生MixedGC时，GC在回收完“必须回收”的部分后，会根据目标暂停时间的剩余量循环的从“可选择回收”部分中选取回收集合进行回收，以保证GC整体暂停时间可控。 (8) 默认的类型信息共享文件(Class Data Sharing - CDS Archive)： Class Data Sharing (CDS)有助于加快Java程序启动时间，同时允许多JVM实例复用SharedArchive以减少memory footprint. JDK10对CDS进一步拓展，SharedArchive中保存应用程序数据：Application Class-data sharing (参见JEP 310) 对于CDS，JEP中的介绍如下：
京东JDK引入了最新的JDK12中关于CDS的新特性 - Default CDS Archives。该功能在编译阶段生成默认的Archive，并且无需用户指定JVM选项-Xshare:auto即可享受到CDS带来的优点。 (9) 并行的高效JMap Java堆分析工具： JMap作为Java开发人员常用工具，一般在调查OOM，查看堆对象分布时都能发挥重要作用。但是在日常工作中，发现对于大堆，例如堆内存配置为-Xmx200g时，在线上系统运行JMap histo时间非常长，并且影响整个JVM进程的响应速度，一旦JVM进程被KILL，运行中JMap histo也无法提供有效信息。 经过调研，JMap 工具在扫描Java堆时是单线程工作，并且只有在整个堆扫描完成时才会统计信息并输出。 针对JMap的问题，京东JDK团队对JMap进行了拓展，实现了其并行，增量式对扫描方案。对JMap histo在大堆上的扫描并行化，同时在运行中统计中间结果。使得JMap在200GB堆扫描性能提升2倍，同时能够使JMap在运行过程中不断输出中间结果，这样即使JVM进程退出，JMap仍能提供有效的信息用于分析内存使用情况。 2. 京东JDK优化效果 经过一系列的工作，目前京东JDK已经顺利应用于京东大数据平台HDFS的NameNode节点上，其对于管理结点优化达到50%， 见下图： 另一方面，JDJDK对于管理结点文件数承载能力从4亿上升到10亿，承载能力提升1.5倍。缓解了业务方的需求，节省了人力。 针对G1GC 也做了相关优化， 优化后的G1GC 对比之前JDK8的CMS的YoungGC暂停时间如下图： GC发生的次数对于如下： 在加/解锁及线程同步方面，京东JDK团队也进行了深入的研究及优化，除了上文提到的偏向锁以外，还利用JVM 的instrumentation等工具，对锁相关的bytecode进行线上优化，针对不同的HDFS访问，优化效果如下： Mkdir： Delete： Getfileinfo： Rename： 五、京东JDK的发展方向 在未来，京东JDK团队将更加注重于降本增效方面的工作，我们计划进行更多的尝试及创新，例如：
同时，京东JDK团队也将积极参与openJDK社区的开发及研究工作，尽可能将京东JDK的特性贡献到社区，让更多人能够使用到。 作者简介：臧琳，京东JVM专家，主要负责京东JDK针对京东大数据业务的定制化开发及优化工作。专注于JVM中内存管理，runtime运行时以及JIT编译器的性能分析及优化等领域。 【本文来自51CTO专栏作者张开涛的微信公众号(开涛的博客)，公众号id: kaitao-1234567】 戳这里，看该作者更多好文 （编辑：PHP编程网 - 金华站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
