面向大数据处理框架的JVM 优化技术综述*汪钇丞1,2, 曾鸿斌1,2, 许利杰1,2,3, 王 伟1,2,3, 魏 峻1,2,3, 黄 涛1,21(计算机科学国家重点实验室(中国科学院 软件研究所), 北京 100190)2(中国科学院大学, 北京 100049)3(中科南京软件技术研究院, 江苏 南京 211135)通信作者: 许利杰, E-mail: xulijie@otcaix.iscas.ac.cn; 王伟, E-mail: wangwei@otcaix.iscas.ac.cn摘　要: 当前, 以Hadoop、Spark 为代表的大数据处理框架, 已经在学术界和工业界被广泛应用于大规模数据的处理和分析. 这些大数据处理框架采用分布式架构, 使用Java、Scala 等面向对象语言编写, 在集群节点上以Java 虚拟机(JVM) 为运行时环境执行计算任务, 因此依赖JVM 的自动内存管理机制来分配和回收数据对象. 然而, 当前的JVM 并不是针对大数据处理框架的计算特征设计的, 在实际运行大数据应用时经常出现垃圾回收(GC) 时间长、数据对象序列化和反序列化开销大等问题. 在一些大数据场景下, JVM 的垃圾回收耗时甚至超过应用整体运行时间的50%, 已经成为大数据处理框架的性能瓶颈和优化热点. 对近年来相关领域的研究成果进行了系统性综述:(1) 总结了大数据应用在JVM 中运行时性能下降的原因; (2) 总结了现有面向大数据处理框架的JVM 优化技术,对相关优化技术进行了层次划分, 并分析比较了各种方法的优化效果、适用范围、使用负担等优缺点; (3) 探讨了JVM 未来的优化方向, 有助于进一步提升大数据处理框架的性能.关键词: 大数据系统; Java 虚拟机; 分布式系统; 自动内存管理中图法分类号: TP316中文引用格式: 汪钇丞, 曾鸿斌, 许利杰, 王伟, 魏峻, 黄涛. 面向大数据处理框架的JVM优化技术综述. 软件学报. http://www.jos.org.cn/1000-9825/6502.htm英文引用格式: Wang YC, Zeng HB, Xu LJ, Wang W, Wei J, Huang T. Survey on JVM Optimization for Big Data ProcessingFrameworks. Ruan Jian Xue Bao/Journal of Software (in Chinese). http://www.jos.org.cn/1000-9825/6502.htmSurvey on JVM Optimization for Big Data Processing FrameworksWANG Yi-Cheng1,2, ZENG Hong-Bin1,2, XU Li-Jie1,2,3, WANG Wei1,2,3, WEI Jun1,2,3, HUANG Tao1,21(State Key Laboratory of Computer Science (Institute of Software, Chinese Academy of Sciences), Beijing 100190, China)2(University of Chinese Academy of Sciences, Beijing 100049, China)3(Nanjing Institute of Software Technology, Nanjing 211135, China)Abstract: Nowadays, the big data processing frameworks such as Hadoop and Spark have been widely used for data processing andanalysis in industry and academia. These big data processing frameworks adopt the distributed architecture, generally developed in objectorientedlanguages like Java and Scala. These frameworks take Java virtual machine (JVM) as the runtime environment on cluster nodes toexecute computing tasks, i.e., relying on JVM’s automatic memory management mechanism to allocate and reclaim data objects. However,current JVMs are not designed for the big data processing frameworks, leading to many problems such as long garbage collection (GC)time and high cost of data serialization and deserialization. As reported by users and researchers, GC time can take even more than 50%of the overall application execution time in some cases. Therefore, JVM memory management problem has become the performancebottleneck of the big data processing frameworks. This study systematically reviews the recent JVM optimization research work for bigdata processing frameworks. The contributions include the following three outcomes. First, the root causes of the performance degradation* 基金项目: 国家重点研发计划(2017YFB1001804); 国家自然科学基金(61802377); 中国科学院青年创新促进会收稿时间: 2021-01-18; 修改时间: 2021-04-29, 2021-07-30; 采用时间: 2021-09-29软件学报 ISSN 1000-9825, CODEN RUXUEW E-mail: jos@iscas.ac.cnJournal of Software [doi: 10.13328/j.cnki.jos.006502] http://www.jos.org.cn©中国科学院软件研究所版权所有. Tel: +86-10-62562563网络首发时间：2022-11-15 10:06:40网络首发地址：https://kns.cnki.net/kcms/detail/11.2560.TP.20221113.1506.065.htmlof big data applications when executed in JVM are summarized. Second, the existing JVM optimization techniques are summarized for bigdata processing frameworks. These methods are also classified into categories, the advantages and disadvantages of each are compared andanalyzed, including the method’s optimization effects, application scopes, and burdens on users. Finally, some future JVM optimizationdirections are proposed, which will help the performance improvement of big data processing frameworks.Key words: big data system; Java virtual machine (JVM); distributed system; automatic memory management随着互联网技术的快速发展和普及, 互联网产生的数据量也呈现出爆炸式增长的趋势. 为了满足大规模数据处理的需求, 工业界和学术界开发出了多种分布式的编程模型及处理框架, 如MapReduce[1], Dryad[2]等. 这类编程模型采用分治的思想, 将大的数据处理作业(job) 拆分为多个小的计算任务(task), 分配调度到分布式集群的不同节点上并行执行. 当前主流的大数据分布式处理框架例如Hadoop[3]、Spark[4]、Flink[5]等, 基本继承了这类编程模型, 并选择了JVM 作为执行计算任务的具体运行时环境, 使计算任务以线程或是进程的方式在JVM 中执行, 依赖JVM 实现内存对象的分配和回收.这些大数据处理框架采用JVM 运行的原因在于: (1) 开发者可以利用JVM “一次编写, 到处运行”, 摆脱分布式集群中不同操作系统和硬件处理框架带来的束缚, 更加专注于代码逻辑; (2) JVM 提供了便捷的自动内存管理机制, 可以自动为新创建的对象进行内存分配, 以及对不再使用的对象进行回收, 减轻了开发者的编程负担; (3) Java作为一个成熟的面向对象编程语言, 拥有丰富的社区资源, 能够实现快速开发.然而, 在实际使用大数据处理框架的过程中, 学术界和工业界发现了一系列JVM 相关的性能瓶颈. 其中最主要的性能瓶颈来自JVM 长时间, 高频次的GC. 比如, 在一些大数据应用中, GC 暂停时间在大数据应用的总执行时间中占比可达50%[6]. 另外, 分布式节点间的网络传输需要JVM 序列化和反序列化数据对象, 用时占比可达30%[7]; JVM 冷启动的预热用时可达10–30 s[8]; JVM 内存溢出错误(out of memory, OOM) 会导致计算任务执行失败[9]. 这些问题严重影响到了大数据应用的执行效率, 使大数据处理框架难以实现低延迟、高吞吐率的目标. 回退到更基础的非托管运行时环境可以部分避免上述问题, 但目前主流的大数据处理框架都是基于JVM, 而在大数据框架的生态圈中, 一个框架的功能往往建立在之前框架功能的基础之上, 这使得选择JVM 已经成为了一个长期的趋势. 在这样的趋势之下, 对JVM 大数据环境适应性的优化至关重要, 已经成为近年来的研究热点方向.当前, 一些综述研究[10,11]介绍了大数据处理框架的内存使用技术, 但并没有关注运行时环境层面的内存管理问题. 也有综述研究[12]介绍了大数据处理框架通过GC 算法管理内存的过程, 从可拓展性的角度分析了GC 算法在管理大规模内存时存在的问题, 并对已有优化技术根据宏观优化目标进行了分类. 还有综述研究[13]从对象管理的角度, 分析了大数据处理框架下的内存管理问题, 并对各类解决方案的特点进行了总结和比较. 鉴于发表年份稍早, 这些综述研究[12,13]都未能包含近几年新出现的优化工作. 本文结合大数据处理框架的结构层次和计算特征, 深度分析了JVM 在分布式大数据环境下的性能瓶颈, 全面地整理和归纳了各个方向上的优化方法, 主要关注3 个核心研究问题: (1) JVM 在大数据处理框架中性能低下的原因是什么? (2) 可以从哪些层次和方面优化大数据处理框架中JVM 的性能, 现有的研究工作具体采用了怎样的优化方法? 这些优化方法有哪些优缺点? (3) 未来可以从哪些方向继续优化JVM, 提高其对大数据处理框架的适应性?针对这3 个核心研究问题, 本文对相关领域近年来的工作进行了广泛调研, 利用文献数据库和搜索引擎, 在国内外主流会议和期刊收录的论文当中进行了细致检索, 收集并阅读了上百篇论文, 最终筛选出了40 余篇高度相关的高质量文献进行综述研究. 本文的主要贡献在于: (1) 结合大数据应用的特点和模式, 总结了JVM 相关性能问题产生的原因, 如大数据应用内存使用量大、对象生命周期复杂、JVM 与上层框架存在隔阂; (2) 将面向大数据处理框架的JVM 优化技术系统地归纳为5 个层面, 包括大数据框架的内存管理、JVM 中数据对象的存储方法、JVM 的GC 算法、JVM 集群的协同、JVM 在新型硬件架构中的应用等, 分析了各个层面优化技术的目标问题、解决方法和局限性, 并对同一层面中的优化方法从实现过程、适用范围、开发者负担等方面进行了比较; (3) 提出进一步提升JVM 在大数据处理框架下性能表现的优化方向, 可以作为后续相关研究工作的参考.本文第1 节介绍了大数据处理框架、JVM、GC 算法的工作流程及关系. 第2 节总结了JVM 在大数据环境中存在的性能问题并分析了问题原因. 第3 节概述了面向大数据处理框架的JVM 优化技术方向. 第4 节介绍了大2 软件学报 ****年第**卷第*期数据框架内存管理的优化技术. 第5 节介绍了执行器集群协同的优化技术. 第6 节介绍了JVM 中数据对象存储方法的优化技术. 第7 节介绍了JVM 中GC 算法的优化技术. 第8 节介绍了新型硬件架构下JVM 的优化技术. 第9节对现有优化工作进行了总结, 并探讨了未来可能的研究方向.1 相关背景概述本节简述大数据处理框架以及JVM 相关概念, 包括大数据处理框架如何将大数据应用转化为可并行执行的计算任务, JVM 执行任务代码的流程, 以及JVM 的垃圾回收机制和相关的GC 算法.1.1 大数据处理框架的工作流程大数据处理框架为用户提供了简单且具有扩展性的编程模型, 能够将大数据应用转化为可并行运行在分布式集群上的计算任务, 实现大数据的高效处理[14]. 当前流行的大数据处理框架, 如Hadoop, Spark 等, 都是以Map-Reduce 编程模型为基础, 具体的流程如图1 所示, 可以简单表示如下.Map 阶段Shuffle 阶段Reduce 阶段输入数据中间数据任务分配到各个节点的 JVM 上执行输出数据Map() Reduce()Reduce()Map()Map(){a, b, a,...}<a, 1> <a, {1, 1, ...}><a, {1, ...}>......<c, {1, ...}>...<a, {1, ...}><b, {1, ...}><a, {1, 1, 1,...}>...<a, n>...<c, n>JVMJVMJVMJVMJVMJVMJVMJVMJVMJVMJVMJVM工作节点 1 工作节点 2 工作节点 3<b, n><c, {1, ...}>......<a, 1>...<a, 1>...<c, 1>...<b, 1>{c,...}{a,...}图 1　MapReduce 编程模型处理流程示例Map 阶段: map<K1, V1> ) list<K2, V2>混洗 (Shuffle) 阶段: list<K2, V2> ) <K2, list(V2)>Reduce 阶段: reduce<K2, list(V2)> ) list<K3, V3>Hadoop MapReduce 基本实现了标准的MapReduce 编程模型, 而Dryad 以有向无环图(DAG) 形式的数据流取代了MapReduce 固定的两阶段数据流, Spark 针对MapReduce 和Dryad 框架的一些问题, 提出了基于内存, 适用迭代计算的处理框架: 首先允许用户将可重用的数据缓存到内存中, 同时利用内存进行中间数据的聚合, 缩短数据处理和I/O 的时间; 另外将输入输出数据, 中间数据抽象为统一的数据结构, 命名为弹性分布式数据集(RDD),并在此数据结构上构建了一系列通用的数据操作, 实现复杂的数据处理流程.大数据应用通常以< 输入数据, 用户代码, 配置参数> 的形式提交给大数据处理框架. 大数据处理框架得到用户输入, 生成一个驱动器(driver) 程序, 将大数据应用分解为一个或多个作业(jobs). 如图1 所示, 一个作业通常会被划分为多个数据处理阶段(stage), 每个执行阶段包含有多个计算任务(task). 计算任务经由任务调度系统, 分配到集群的各个工作节点上, 以JVM 进程或者线程的方式运行. 如Hadoop 为每个计算任务启动一个执行器(executor)JVM 进行运行, Spark 为每个任务启动一个JVM 线程, 该线程运行在执行器JVM 中. 来源于分布式存储系统的输入数据经过转换, 以数据对象的形式存储在执行器JVM 的内存当中, 依赖JVM 的自动内存管理机制实现内存的汪钇丞 等: 面向大数据处理框架的JVM 优化技术综述3申请和回收.1.2 JVM 的运行过程JVM 是在各类计算机环境和各种操作系统上构建的一种统一的运行环境. JVM 为应用程序隐藏了对底层机器和操作系统的操作, 使得Java、Scala 等编程语言代码在编译成Java 字节码后, 能够“一次编写, 到处运行”. Java字节码在加载进JVM 之后, 经过类加载机制的校验, 解析, 初始化等步骤, 成为可以使用的Java 类型, 通过Java 解释器解释执行. 当JVM 发现部分代码运行频繁, 就会将这部分热点代码即时编译(JIT) 为本地机器码, 提高代码后续的执行效率. 类加载和热点代码的即时编译过程通常被认为是JVM 初始化的冷启动消耗.堆内存通常是JVM 的运行时数据内存中最大的一块, 用于存储所有的对象实例以及数组. JVM 的自动内存管理机制负责对堆内存进行维护, 创建新的对象, 保证存活的对象(还在被使用的对象) 保留在内存当中, 以及通过GC 算法清理掉不再使用的对象. 而在运行时数据内存之外, JVM 也可以在直接内存(也被称为堆外内存) 进行对象分配和引用, 而这部分内存则不由自动内存管理机制负责.1.3 JVM 垃圾回收机制OracleJDK/OpenJDK 所使用的HotSpot VM 是目前应用最广泛的JVM, 它所提供的GC 算法都是通过可达性分析来判断对象的存活情况[15]. GC Roots 根对象集是每一次可达性分析的起始节点, 包括了一系列必须存活的对象. 如图2 所示, GC 线程从根对象出发, 根据对象之间的引用关系, 通过深度优先算法向下扫描. 在JVM 堆内存中能够扫描到的对象被认为是存活的对象, 将在随后的阶段复制移动到新的内存位置; 而没有被扫描到的对象被认为是不再被使用的死亡对象, 最终被清理出内存. GC 流程的扫描和移动任务通常都被添加到GC 任务队列中,由GC 线程从任务队列中获取和执行.JVM 堆内存地址空间伊甸园区年轻代老年代幸存者区幸存者区对象头部死亡对象存活对象存活对象对象引用对象头部对象引用对象头部对象引I II 用根对象引用图 2　Parallel GC 算法下的JVM 堆内存划分及可达性分析示例HotSpot 中的GC 算法都是基于弱世代假说(weak generational hypothesis)[16]: 即绝大部分对象在创建后不久就不再被使用. 因而现有的GC 算法采用分代收集的思想, 将堆内存划分为年轻代(young generation) 和老年代(old generation), 分别用于存储短寿命对象和长寿命对象. 年轻代分为两部分: 伊甸园区(eden) 和幸存者区(survivor).对象最初被分配到年轻代的伊甸园区, 伊甸园区在空间耗尽时会触发Minor GC, 将存活的对象复制到幸存者区中, 并清空伊甸园区. 当一个对象经历的Minor GC 达到一定次数后依旧存活时, 将被晋升复制到老年代中存储,老年代在空间使用量到达一定比例之后, 触发Major GC 对整个堆内存空间进行标记和整理. 为了保证GC 结果的一致性和安全性, 所有的GC 算法都存在部分处理阶段需要中断所有工作线程, 称为全局暂停(stop-the-world, STW).Java 7 和Java 8 目前依旧是使用最广泛的Hotspot 版本, 因而它们的默认垃圾回收器Parallel GC 也是最常被使用的传统GC 算法. 相比于更早的Serial GC 算法, Parallel GC 的优势就在于允许多个GC 线程同时从GC 任务队列中获取任务并行执行. 如图2 所示, Parallel GC 在堆内存中采取整块划分, 每一个年代的空间都是整体连续的. 按照默认参数, JVM 堆的前1/4 被划分给年轻代, 后3/4 划分给老年代, 用户也可以通过参数自行指定. ParallelGC 默认开启动态自适应策略, 根据运行时的情况对各年代的空间大小进行动态调整, 以尽可能满足吞吐量和最大暂停时间的目标.从Java 9 开始到目前最新的Java 17 版本, garbage first (G1)[17]成为Hotspot 的默认垃圾回收器. 如图3 所示,G1 采用基于区域的堆内存划分方法, JVM 堆内存被划分成等大小的区域, 而每次GC 只处理其中一部分的区域,避免一次处理过多的对象, 解决了Full GC 处理量过大, 全局暂停时间过长的问题. G1 依旧采用年代划分法, 部分4 软件学报 ****年第**卷第*期区域会属于伊甸园区, 部分区域属于幸存者区, 部分区域属于老年代, 但区域的归属并不固定, 提供了更高的灵活性. 当一个老年代区域的存活对象比例低于一定阈值时, 该区域会被加入待GC 区域集, 待GC 区域集在数量达到一定比例时会触发混合GC (Mixed GC), 收集待GC 区域集中的老年代区域和所有年轻代区域. G1 通过记忆集(remember set) 快速处理区域之间的引用关系, 通过堆快照(snapshot) 和写屏障(write barrier), 使得G1 可以在部分处理阶段实现工作线程和GC 线程并发执行, 达到降低全局暂停时间的目的.JVM 堆内存地址空间未使用巨型对象伊甸园区幸存者区老年代区EEEE EOOO O OOOO SSSSH H HH图 3　G1 GC 算法下的JVM 堆内存划分Parallel 和G1 两种GC 算法尽管在实现方法上存在差异, 但都是针对一般Java 程序的对象使用特点设计的.大数据应用的对象使用有自身的特点, 使用这传统GC 算法进行内存管理时会产生严重的性能损失. 第2 节将分析当前的JVM 在应用于大数据处理框架时遇到的性能问题及原因.2 JVM 在大数据环境中存在的问题及原因分析大数据处理框架的性能分析和优化是一直以来的研究热点. JVM 作为大数据处理框架的运行时环境, 它的执行效率直接影响着大数据处理框架的性能表现. 本节介绍了JVM 在大数据环境中存在的问题, 并分析了问题的成因.2.1 JVM 在大数据环境中的性能问题工业界的实践和学术界的评测工作发现, GC 机制是对JVM 执行效率影响最大的因素. 具体表现包括:(1) GC 的占用时间长, 在一些大数据应用中, GC 时间可占应用总执行时间的50%[6,18].(2) GC 频率高, 造成任务执行频繁暂停, 大数据应用的吞吐率降低, 响应延迟升高[19].(3) GC 算法挤占了应用线程CPU 资源, 存在GC 线程竞争时, 大数据应用执行时间增加了60%[9,20].传统并行GC 算法下的全局暂停时间较长, 增加了大数据应用的延迟, 容易引发任务掉队, 与作业的尾延迟有着直接关系[20,21]; 传统并发GC 算法下虽然全局暂停时间可以得到一定控制, 但是以高CPU 使用率和高暂停频率为代价, GC 线程与并发执行的应用线程竞争降低了任务吞吐率, 也不能有效降低作业尾延迟[20].除了GC, JVM 的其他机制也会影响到大数据应用的整体表现.(1) JVM 中的数据对象在分布式节点间传输需要序列化和反序列化, 在大数据应用执行的用时占比可达30%[7,22].(2) JVM 冷启动时需要大量的类加载和代码即时编译工作, 在大数据应用执行的用时占比可达33%[8].(3) JVM 运行和维护需要内存消耗, 在内存紧张的环境下, 可能因内存耗尽或内存碎片触发OOM 错误[9,23].这些JVM 运行时代价严重干扰了大数据应用的执行. 我们将上述问题产生的原因总结为3 个方面: 大数据处理框架下的JVM 内存使用压力增大、JVM 内存管理模式与大数据应用的内存使用模式不匹配、JVM 与上层框架存在隔阂(gap).2.2 原因1: 内存使用压力增大在与普通的Java 应用不同, 大数据应用是“内存密集”的, JVM 的内存使用量更大. 在大数据处理框架下, 执行器JVM 的内存使用压力具体来源于:汪钇丞 等: 面向大数据处理框架的JVM 优化技术综述5(1) 大数据应用数据计算和存储产生的大量内存消耗. 大量数据在计算过程中需要同时被读取到内存当中, 当前流行的大数据处理框架为了更进一步加快处理速度, 将中间数据的聚合和可重用数据也缓存在内存当中, 这决定了执行器JVM 在执行大数据应用时将面对更大的内存使用量.(2) 数据在JVM 堆内存当中以对象的形式存储需要的额外内存占用. 对象在JVM 当中的数据结构包含了对象头以及对其他对象的引用, 而数据本身在对象中的空间占比往往不超过一半[6,22]. 这些对象的“外壳”伴随着数据缓存在内存当中, 也需要占用相当数量的空间.JVM 的自动内存管理机制以对象为单位, 数据和对象数量的增加意味着更大的内存管理负担, 相应的GC 机制会更频繁地触发更长时间的全局暂停. 这个问题并不能够通过简单地增减内存大小解决. 如果降低内存大小,GC 触发的频率则会增加, 对象被扫描和移动的次数增加, 应用程序的吞吐量相应降低. 可用内存不足还会影响到大数据应用的正常的缓存和处理机制, 甚至引发内存溢出; 如果提升内存大小, 单次GC 则需要处理更多的数据对象, 平均的暂停时间加长, 应用程序的最大延迟相应增加. 对于周期性标记扫描的GC 算法而言, 还会在最终触发GC 之前消耗更多CPU 时序进行不必要的标记.2.3 原因2: 内存使用模式变化大数据应用中数据在内存当中保留的时间周期与传统应用不尽相同. 在JVM 传统的应用场景下, 堆内存中创建的绝大部分对象在产生之后不久就不再被使用, 经典的GC 算法正是基于这种内存使用模式, 将堆内存进行粗粒度的年代划分, 绝大部分转瞬即逝的对象会在针对年轻代的Minor GC 当中很快被清理掉. 而大数据应用产生的对象类型有两种, 一种是由控制大数据处理框架运行逻辑的代码产生的, 称为控制路径对象, 它们的内存使用模式在通常情况下依旧符合弱世代假设; 另一种是输入数据和计算中间数据在大数据处理框架中封装产生的, 统称为数据路径对象[22,24]. 如表1 中对典型大数据应用的分析, 数据路径对象的内存使用模式要更加复杂, 它们可能在内存中长时间累积或缓存, 也可能在一个迭代轮次后被清理和输出. 通常来说, 数据路径对象的存活时间比控制路径对象更长, 但各自的生命周期也不尽相同. 尽管在代码数量上控制路径比数据路径多, 但数据路径所创建的对象数量远超控制路径. 传统GC 算法并不能适应大数据环境下内存使用模式的这种变化, 原因有如下两点.表 1 典型大数据应用的内存使用量和内存使用模式应用名称空间复杂度内存使用模式GroupBy reduceByKey(sum): O(1) Shuffle阶段累积大量中间数据 (具有相同key的数据行)Join join(): O(m + n)Shuffle阶段累积大量中间数据 (两张表具有相同key的数据行)计算产生大量即刻输出的临时对象 (两张表的笛卡尔积结果)SVM reduce(): O(|x|)部分巨型的数据对象 (高维度的参数向量)大量长时间缓存数据 (输入的训练数据)PageRank join(): O(m + n)每一次迭代中累积大量数据 (具有相同key的数据行)大量长时间缓存数据 (输入的图数据)注: m, n表示两个集合的元素数量, |x|表示数据的维度(1) 当前GC 算法下, 长时间存活的数据路径对象最终都会晋升到老年代中, 它们在数次Minor GC 当中幸存并最终晋升的过程中, 需要在内存中多次移动. 对象移动被认为是GC 循环当中最耗时的部分[25,26], 每一次移动都意味着内存读写, 而内存位置的改变也需要对相关引用的指针进行更新. 考虑到数据路径对象的庞大数量, 整个晋升过程会消耗大量CPU 时序, 触发多次GC 暂停.(2) 数据路径对象在晋升到老年代之后, 在作业执行的时间尺度上, 短时间内也不会被回收. 传统的GC 算法不会考虑这些对象的存活时间, 在涉及到老年代空间的Major GC 或者Mixed GC 之前还是会对整个堆内存空间进行标记扫描, 这些标记扫描过程对于长时间存活的数据对象来说是不必要的[9]. 当长时间存活对象占用老年代的比例过高, 每次付出较大代价的Major GC 就只能回收有限大小的空间, 可能造成Major GC 频繁触发, 部分缓存数据被迫转移到磁盘, 甚至出现OOM 错误, 浪费大量的CPU 时序和全局暂停时间, 影响到应用执行效率.6 软件学报 ****年第**卷第*期2.4 原因3: JVM 与上层框架存在隔阂大数据处理框架将计算任务分配调度到各个执行器JVM 节点之后, 并不会干预JVM 的具体执行过程. 每个执行器JVM 独立运行, 并不感知分布式集群中其他执行器JVM 的执行情况, 作业的整体进度, 以及集群和节点的内存资源使用情况, 只是根据自身的运行状态作出触发GC, 调整堆内存, 进行代码即时编译等决策, 而这些决策从历史和全局的角度上观察可能并不是最优的.(1) JVM 不清楚任务执行产生的数据对象特征, 例如对象数量、内存占用大小、生命周期等, 只能根据弱世代假说, 对所有对象进行一致的分配管理. 由于大数据应用产生的大量对象长时间存活, JVM 的内存管理效率会受到严重影响, 而这些对象本可以通过大数据框架对用户代码和数据流的全局静态分析进行甄别.(2) 大数据处理框架不考虑JVM 具体的内存管理机制, 将所有JVM 节点的内存当做连续的全局地址空间. 但实际上JVM 在GC 算法下对堆内存空间采取分代管理, 存在非连续区域, 对象在内存中离散分布. 另外大数据处理框架在采用全局地址空间的物理架构下, 可能产生大量跨节点对象引用, 给JVM 的GC 任务带来了远程内存访问的负担.(3) 大数据处理框架下的JVM 之间不清楚彼此的运行情况. 如果大数据操作需要在各个JVM 之间的同步, 由于JVM 独立进行GC 决策, 大数据操作的执行就可能被不同JVM 的GC 连续打断; 另外, 由于互相不感知, 处于同一物理节点的JVM 之间可能内存资源分配不合理, 而大数据框架在相关问题上缺少统筹协调.3 面向大数据处理框架的JVM 优化技术概览前述问题给JVM 带来的性能下降不可避免, 一些研究工作提出将运行时环境回退到非托管编程语言或者开发新的编程语言和运行时系统[27−29]. 然而用非托管编程语言编写的代码量更大, 调试难度更高, 将给框架开发者带来压力. 而目前成熟的大数据处理框架也都是基于JVM, 这使得选择JVM 已经成为了一个长期的趋势, 因而更多研究工作的目标依旧在于提升JVM 对大数据处理框架的适应性. 本节将从大数据处理框架的3 个层次出发, 概览面向大数据处理框架的JVM 优化技术.如图4 所示, 大数据处理框架可以划分为3 个层次: 用户层, 大数据框架层, 运行时环境层. 按照第1.1 节描述的流程, 用户层将应用代码和应用执行参数提交给大数据框架层, 将应用资源需求参数提交给运行时环境层. 大数据框架层由应用代码和应用执行参数, 构建出应用的逻辑处理流程和分布式的物理执行计划, 并根据集群节点的资源使用情况, 将任务调度到各个机器节点的JVM 上执行. JVM 所在的运行时环境层, 根据应用资源需求参数,获得相应的CPU 和内存等硬件资源, 具体执行计算任务. 输入数据和中间数据按照大数据处理框架和用户代码的定义, 封装为对象的形式存储在JVM 堆内存当中, 而JVM 的GC 算法负责在对象不再被使用时, 将对象从JVM的堆内存中清理回收. 上述3 个层次可以分别作为提高JVM 对大数据处理框架适应性的切入点, 主要存在6 种优化的方向.从用户层出发的主要优化手段是对应用执行参数和应用资源需求参数进行调优(tuning), 确定一个适应当前应用计算特征的配置, 使大数据应用的执行时间更短[30]. 由于大数据框架和JVM 的参数类型纷繁复杂, 有效的人工调优需要开发者丰富的工程经验[31,32]. 为了降低调优工作的门槛, 相关研究工作基于白盒(white-box) 和黑盒(black-box) 两种调优模型, 开发了一系列大数据处理框架和JVM 的自动调优工具[33−39]. 基于白盒的调优工具主要通过建立假设分析(what-if) 模型进行离线性能估计, 根据性能估计结果进行参数调优[40,41]. 基于黑盒的调优工具主要根据真实在线测试的结果, 对整个参数空间进行搜索和调优[42−44]. 尽管参数调优的方法可以取得不错的应用性能提升, 但基于白盒方法的调优工具在假设分析模型的创建方面存在很大挑战, 而基于黑盒方法的调优工具要获得足够好的结果需要耗费大量的时间进行测试, 即使采用一些优化加速方法依旧需要小时级别的时间[45]. 另外,经过调优的参数通常只针对固定硬件环境下的一种大数据应用, 并不能有效移植到其他应用和硬件环境中, 而不同的大数据应用在不同的处理阶段的计算特征和内存使用模式都存在差异, 静态的参数无法在运行时同时满足各个阶段的需求. 综上所述, 在用户层的参数调优并不能从本质上改善JVM 在大数据处理框架下的适应性问题, 因汪钇丞 等: 面向大数据处理框架的JVM 优化技术综述7而本文主要关注工作在大数据框架层和运行时环境层的优化技术, 这些优化技术可以在一定程度上解决第2 节描述的3 个问题, 如表2 所示.用户配置参数应用程序代码逻辑处理流程 物理执行计划 任务调度管理代码,应用执行参数应用资源需求参数数据转换为对象的形式存储Map() Reduce()Reduce()Map()Map()用户层大数据框架层JVM 堆内存CPU DRAM NVMJVM 堆内存内存磁盘操作系统运行时环境层JVM 堆内存GC 算法回收不再使用的对象表示不再使用的数据对象表示任务执行使用的总内存表示数据对象占用的内存应用参数调优(多次运行寻找最佳参数配置)大数据框架的内存管理优化(大数据框架层面调整内存划分和对象分配)执行器集群的协同优化(大数据框架对执行器集群统筹规划)JVM 中数据对象的存储方法优化(调整数据对象在内存的存储位置和方式)JVM 的 GC 算法优化(提高现有 GC 算法的可扩展性)新型硬件架构下的 JVM 优化(将新型硬件架构应用于 JVM){a, b, a,...}图 4　大数据处理框架的层次结构表 2 大数据处理框架下的JVM 优化技术分类优化层面优化方向优化技术代表工作解决问题大数据框架层大数据框架的内存管理优化大数据框架内存分配参数的动态调整MEMTUNE[31]内存使用模式变化基于生命周期的大数据框架对象管理Deca[46,47]执行器集群的协同优化基于全局协调的执行器GC时机决策Taurus[19]基于历史的执行器JVM重用 HotTub[8] JVM与上层框架隔阂基于动态规划的执行器内存弹性分配ElasticMem[48]运行时环境层JVM中数据对象的存储方法优化基于区域的数据对象存储和管理Yak[49]基于二进制的数据对象序列化存储 Gerenuk[22] 内存使用压力增大JVM的GC算法优化基于Parallel GC的算法并行度优化Platinum[20]基于G1 GC的年代划分数量拓展ROLP[50]内存使用模式变化新型硬件架构下的JVM优化基于内存分解架构的JVM数据本地化Semeru[51]基于非易失性存储器的JVM内存拓展Panthera[52]从大数据框架层出发: (1) 可以对大数据处理框架粗粒度的内存管理模式进行优化, 以对执行器JVM 更友好的策略进行对象申请, 应对变化的内存使用模式. 具体包括根据运行时状态信息, 对框架的内存分配参数进行动态调整; 根据对象在大数据框架中的用途和使用周期信息, 将对象基于生命周期进行申请和管理. (2) 可以对框架下的JVM 集群进行协调, 通过执行器JVM 和大数据框架在运行时的交互, 使得每一个JVM 的任务执行过程最有利于大数据框架的整体性能, 消除JVM 与上层框架的隔阂. 具体包括对所有执行器JVM 的GC 决策进行统筹; 对历8 软件学报 ****年第**卷第*期史的执行器JVM 进行重用; 对统一物理节点上的各个执行器JVM 的内存分配进行动态规划.从运行时环境层出发: (1) 可以对JVM 存储数据路径对象的方法进行优化, 提高数据在内存