Maven依赖解析之倍增提速，eBay Velocity实践的开源新算法

1

缘  起

Maven 作为程序员所熟悉的构建工具，在eBay内部同样被广泛使用。maven-resolver 是Maven的核心组件。它将项目声明的所有依赖 (dependency) 予以解析，算得依赖图 (dependency graph) 并调解冲突，最终整合成项目编译和部署所需的classpath，这个过程叫依赖解析 (dependency resolution)。在eBay开展的 Build Velocity 项目实践中，通过对Maven Build数据进行分解和可视化分析，我们惊讶地发现maven-resolver在解析复杂依赖时存在严重的性能瓶颈。

为突破瓶颈并加速Maven Build，我们对maven-resolver的依赖解析算法作了大幅改造，并实现了一个全新的算法： BF (广度优先遍历) + Skipper 。 其意义是Maven可以无视依赖图的复杂度，甚至有大量循环依赖的情况下，可通过最小运算量计算出项目所需的最终依赖项。经测试，该算法可以让依赖比较复杂的项目的纯build时间缩短 30-70% ！

目前该算法已被Apache Maven社区正式接受并纳入maven-resolver v1.8.0 (该组件将随Maven 3.9.0发布)。以下使用说明来自 Maven官方文档:

新算法甫一亮相，来自阿里的开发人员便试用并给出了以下反馈：

目前我们已经应用到5 - 6个需要花长时间build的工程，build时间可以缩短一半，后续我们会把这个算法应用到更多的工程并及时反馈。

这个算法的诞生可谓历经艰辛。从发现问题、解决问题到贡献回社区，每一步都倾注了eBay Applciation Framework 团队的心血。

本文将以算法的起源和演进为轴线，为大家重温个中细节。

注：本文提及的测试数据均基于纯build，指本地Maven repository有full cache并跳过全部测试的情况下跑的Maven Build (mvn clean install -DskipTests)，故不涉及任何Maven artifacts下载。

2

发  现

2021年3月，eBay启动Velocity项目，旨在加速开发迭代。 其子项目Build Velocity的设立旨在加速开发周期的重要一环：Maven Build。其前期共60+ pilot 项目参与。eBay Application Framework Team负责技术攻关。

摆在我们面前的问题有两点：一是缺乏数据，二是不清楚Maven Build具体慢在哪里。

工欲善其事，必先利其器。我们首先打造了 Zeus产品 。该产品以一个Maven Extension为核心，实时参与用户build，收集数据并汇总成报表。通过分析报表、诊断热点（hotspot）、开发特性（feature）以解决热点、Extension自我升级并启用特性、再用新收集的数据体现优化效果，至此形成一个可持续运行的调优闭环。

每条数据量化了Maven Build的各个步骤，并统计以下指标：

Zeus应用到上述pilot项目后，我们发现有一个项目跑一次纯build竟然需要 30+ 分钟才能完成。内存配置甚至需要 20G ，否则Maven Build会因内存溢出而终止。我们通过分析收集到的build数据，发现上述依赖解析部分时间（相当于跑一次mvn dependency:tree）几乎 等同于纯build时间 。 通过Zeus报表发现，有不少项目在依赖解析上花了不少时间 ( 5～10分钟 )，虽然没有上述项目严重，但至少说明Maven依赖解析慢是个共同的问题！

3

探  究

Maven 依赖解析过程简介

Maven 依赖的声明使用大家都很熟悉了&#x