1. 现状
maven其实并不是拖拉机。
相对于ant时代来说，maven是一辆大奔。但随着业务越来越复杂，我们为业务提供服务的软件也越来越复杂。虽然我们在提倡要降低软件复杂度，但对于复杂的业务来说，降低了复杂度的软件还是复杂的。
在这些年，随着业务竞争越来越激励，业务越来越复杂，软件也越来越复杂。而maven却还是几年的版本。在2012年推出maven3.0.0以来，直到现在的2022年，正好十年，但maven最新版本还是3系列3.8.6。所以在十年后的今天，站在复杂软件面前，maven变成了一辆拖拉机。
编码也是一种艺术，对于我们一线研发同学来说，每个人都期望变成一名艺术家，而不是一个码农。但如一次构建大于3分钟，会将我们从一名高雅的艺术家沦为一名焦虑的码农，因为项目的deadline是放的那么地显眼。
我们可能有过这样体验，编码几分钟，代码提交后，CI/CD中的构建却要10多分钟。特别是在项目联调阶段，代码修改会越频率，但一天解决不了几个BUG，因为时间都花在等待构建阶段上了。
我们曾经错过了多少个夏天的晚霞与秋天的朝霞，都是因为等待构建与编译而工作到凌晨。
2. 解决方案
在这十年，虽然maven还是停留在主版本号是3，但当今业界也不断出现了优秀的构建工具，如gradle，bazel。但因各工具的生态不同，同时工具间迁移有成本与风险，所以目前在Java服务端应用仍是以maven构建为主。所以我们在apache-maven的基础上，参照gradle，bazel等其它工具的思路，进行了优化，并以“amaven”命名。
因为amaven完全兼容apache-maven，所支持的命令与参数都兼容，所以对我们研发同学来说，只要修改一个maven的版本号。
3. 效果
从目前试验来看，对于mvn build耗时在3分钟以上的应用有效果。对于典型应用从2325秒降到188秒，提升了10倍多。
我们再来看持续了一个时间段后的总体效果，典型应用使用amaven后，构建耗时p95的时间有较明显下降，对比使用前后二个月的构建耗时降了50%左右。
4. 原理
如果说发动机是一辆车的灵魂，那依赖管理就是maven的灵魂。
因为maven就是为了系统化的管理依赖而产生的工具。使用过maven的同学都清楚，我们将依赖写在pom.xml中，而这依赖又定义了自己的依赖在自己的pom.xml。通过pom文件的层次化来管理依赖的确让我们方便很多。
我们平常说的maven其实指二样东西，一个是maven工具，一个是maven仓库。
maven工具主要是mvn命令，我们在执行mvn compile等命令时，maven会先不断解析pom中的依赖，如某个依赖本地没有则会从maven仓库下载到本地，再递归解析与下载“依赖的依赖”，最后生成一个dependencyGraph，然后再将graph中的依赖的jar列表成classPath中的参数，进行Javac，从而完成一次编译。如再加上一些插件执行，则一次典型的maven构建过程，会是这样：
从上图可以看出，maven构建主要有二个阶段，而第一阶段是第二阶段的基础，基本上大部分的插件都会使用第一阶段产生的依赖树：
• 解析应用的pom及依赖的pom，生成依赖树；在解析过程中，一般还会从maven仓库下载新增的依赖或更新了的snapshot包。
• 执行各maven插件。
我们也通过分析实际的构建日志，发现大于3分钟的maven构建，瓶颈都在“生成依赖树”阶段。而“生成依赖树”阶段慢的根本原因是一个module配置的依赖太多太复杂，它表现为：
• 依赖太多，则要从maven仓库下载的可能性越大。
• 依赖太复杂，则依赖树解析过程中递归次数越多。
既然说发动机是车子的灵魂，那要让车子跑的更快，最核心的就要不断改造发动机的性能；既然说依赖管理是maven的灵魂，那要让maven执行的快，最核心的就要不断“改造”依赖分析的性能。
在amaven中通过优化依赖分析算法，与提升下载依赖速度来提升依赖分析的性能。除此之外，性能优化的经典思想是缓存增量，与分布式并发，我们也遵循这个思想。
既然生成依赖树的代价大，那我们就将依赖树缓存起来（直接缓存与复用肯定比重新解析一次快），因为在实际开发过程中，修改自己的Java代码的概率远大于修改应用的pom。同时，如一个应用，特别是大库应用，当它的module可能有几十个，或几百个时，则要使用分布式并发构建的方案，将互不依赖的的module启多线程，甚至分配到不同的编译机上去同时构建。
因为maven自己也是Java程序，所以为了尽可能降低字节码在运行时转成机器码的开销，我们也考虑了daemon方案。所以总的加速思路如下：
而当以上思路在不断落地过程中，amaven也不断地C/S化了，即amaven不再是一个client，而有了server端，同时将部分复杂的计算从client端移到了server端。而当client越做越薄，server端的功能越来越强大时，server的计算所需要的资源也会越来越多，将这些资源用弹性伸缩来解决，慢慢地amaven云化了。
从单个client到C/S化再到云化，这也是一个工具不断进化的趋势所在。
1) 依赖树
a) 依赖树缓存
既然依赖树生成慢，那我们就将这依赖树缓存起来。缓存后，这依赖树可以不用重复生成，而且可以不同人，不同的机器的编译进行共享。使用依赖树缓存后，一次典型的mvn构建的过程如下：
从上图中可以看到amaven-server，它主要负责依赖树缓存的读写性能，保障存储可靠性，及保证缓存的正确性等。
b) 依赖树生成算法优化
虽在日常研发过程中，修改pom文件的概率较修改应用Java低，但还是有一定概率；同时当pom中依赖了较多SNAPSHOT且SNAPSHOT有更新时，依赖树缓存会失效掉。所以还是会有不少的依赖树重新生成的场景。所以还是有必要来优化依赖树生成算法。
在maven2及maven3版本中，包括最新的maven3.8.5中，maven是以深度优先遍历（DF）来生成依赖树的。
（在社区版本中，目前master上已经支持BF，但还未发release版本：
在遍历过程中通过debug与打日志发现有很多相同的gav或相同的ga会被重复分析很多次，甚至数万次。
树的经典遍历算法主要有二种：深度优先算法（DF）及广度优先算法（BF），BF与DF的效率其实差不多的。在有些场景，是DF更快，在有些场景，是BF更快。DF一般用stack数据结构，BF一般用queue数据结构。
树的二种遍历算法本没有根本的孰好孰坏之分，但当结合maven的版本仲裁机制考虑会发现有些差异。
我们再来看看maven的仲裁机制。
无论是maven2还是maven3，最主要的仲裁原则就是depth。相同ga或相同gav，谁更deeper，谁就skip。当然仲裁的因素还有scope、profile等。考虑根据depth来仲裁的机制，按层遍历会更优，因为可以比DF更容易结合按depth仲裁。如下图，如按层来遍历，则红色的二个D1，D2就会skip掉，不会重复解析。（注意，实际场景是C的D1还是会被解析，因为它更左）。按层遍历也就是BF。
所以小结下，对于树的遍历算法本身来说，DF与BF效率是差不多的。但对于maven3.5.0的依赖树生成逻辑来说，是因为在BF中可以先加上按depth仲裁逻辑，才会比DF快。
即算法优化的思路是：“提前修枝”。之前maven3的逻辑是先生成依赖树再版本仲裁，而优化后是边生成依赖树边仲裁。就好比一个树苗，要边生长边修枝，而如果等它长成了参天大树后则修枝要累死人。
c) 依赖下载优化
maven在编译过程中，会解析pom，然后不断下载直接依赖与间接依赖到本地。一般本地目录是.m2。对一线研发来说，本地的.m2不太会去删除，所以除非有大的重构，每次编译只有少量的依赖会下载。
但对于CICD平台来说，因为编译机一般不是独占的，而是多应用间共享的，所以为了应用间不相互影响，每次编译后可能会删除掉.m2目录。这样，在CICD平台要考虑.m2的隔离，及当.m2清理后要下载大量依赖包的场景。
而依赖包的下载，是需要经过网络，所以当一次编译，如要下载上千个依赖，那构建耗时大部分是在下载包，即瓶颈是下载。
• 增大下载并发数
依赖包是从maven仓库下载。maven3.5.0在编译时默认是启了5个线程下载。我们可以通过aether.connector.basic.threads来设置更多的线程如20个来下载，但这要求maven仓库要能撑得住翻倍的并发流量。所以我们对maven仓库进行了架构升级，根据包不同的文件大小区间使用了本地硬盘缓存，redis缓存等包文件多级存储来加快包的下载。
下表是对热点应用A用不同的下载线程数来下载5000多个依赖得到的下载耗时结果比较：
在amaven中我们加了对下载耗时的统计报告，包括下载多少个依赖，下载线程是多少，下载耗时是多少，方便大家进行性能分析。如下图：
同时为了减少网络开销，我们还采用了在编译机本地建立了mirror机制。
• 本地mirror
在CI/CD平台，构建时，为避免重复下载同一个依赖文件，架构可能是这样的：
（架构1.0：共享.m2）
这架构会有依赖包的准确性问题。
在一个node上，会编译很多应用，而每个应用编译时指定的maven仓库可能不一样。如果volume同一个.m2目录，当应用A下载从仓库a下载了maven-compiler-plugin:3.8.1后，应用B它指定了从仓库b下载依赖，但当它编译时发现.m2目录已经有maven-compiler-plugin:3.8.1了，就不会下载了。当仓库a与仓库b中maven-compiler-plugin:3.8.1的文件的checksum不同时，就会让应用B在构建或运行时出现问题。
更多精彩内容，欢迎观看：
《Java应用提速（速度与激情）》——一、maven构建提速（下）：https://developer.aliyun.com/article/1223854?groupCode=java
