关于后端:java应用提速速度与激情

简介：本文将论述通过基础设施与工具的改良，实现从构建到启动全方面大幅提速的实际和实践。

作者 | 阿里巴巴 CTO 技术起源 | 阿里开发者公众号联结作者：道延 微波 沈陵 梁希 大熊 断岭 北纬 未宇 岱泽 浮图一、速度与效率与激情什么是速度？速度就是快，快有很多种。有小李飞刀的快，也有闪电侠的快，当然还有周星星的快：（船家）” 我是出了名够快 ”。（周星星）“这船如同在下沉？”（船家）“是呀！沉得快嘛”。并不是任何事件越快越好，而是那些有价值有意义的事才越快越好。对于这些越快越好的事来说，快的体现是速度，而本质上是提效。明天咱们要讲的 java 利用的研发效率，即如何放慢咱们的 java 研发速度，进步咱们的研发效率。提效的形式也有很多种。但能够分成二大类。咱们应用一些工具与平台进行利用研发与交付。当一小部分低效利用的用户找工具与平台负责人时，负责人倡议提效的计划是：你看看其余利用都这么快，阐明咱们平台没问题。可能是你们的利用架构的问题，也可能是你们的利用中祖传代码太多了，要本人好好重构下。这是大家最常见的第一类提效形式。而明天咱们要讲的是第二类，是从工具与平台方面进行降级。即通过根底研发设施与工具的微翻新改良，实现研发提效，而用户要做的可能就是换个工具的版本号。买了一辆再好的车，带来的只是速度。而本人一直钻研与革新发动机，让车子越来越快，在带来一直冲破的“速度”的同时还带来了“激情”。因为这是一个一直用本人双手发明奇观的过程。所以咱们明天要讲的不是买一辆好车，而是讲如何革新“发动机”。在阿里团体，有上万多个利用，大部分利用都是 java 利用，95% 利用的构建编译工夫是 5 分钟以上，镜像构建工夫是 2 分钟以上，启动工夫是 8 分钟以上，这样意味着研发同学的一次改变，大部分须要期待 15 分钟左右，能力进行业务验证。而且随着业务迭代和工夫的推移，利用的整体编译构建、启动速度也越来越慢，公布、扩容、混部拉起等等一系列动作都被拖慢，极大的影响了研发和运维整体效力，利用提速迫不及待。咱们将论述通过基础设施与工具的改良，实现从构建到启动全方面大幅提速的实际和实践，置信能帮忙大家。

 二、maven 构建提速 2.1 现状 maven 其实并不是拖拉机。绝对于 ant 时代来说，maven 是一辆大奔。但随着业务越来越简单，咱们为业务提供服务的软件也越来越简单。尽管咱们在提倡要升高软件复杂度，但对于简单的业务来说，升高了复杂度的软件还是简单的。而 maven 却还是几年的版本。在 2012 年推出 maven3.0.0 以来，直到现在的 2022 年，正好十年，但 maven 最新版本还是 3 系列 3.8.6。所以在十年后的明天，站在简单软件背后，maven 变成了一辆拖拉机。2.2 解决方案在这十年，尽管 maven 还是停留在主版本号是 3，但当今业界也一直呈现了优良的构建工具，如 gradle,bazel。但因各工具的生态不同，同时工具间迁徙有老本与危险，所以目前在 java 服务端利用仍是以 maven 构建为主。所以咱们在 apache-maven 的根底上，参照 gradle,bazel 等其它工具的思路，进行了优化，并以“amaven”命名。因为 amaven 齐全兼容 apache-maven，所反对的命令与参数都兼容，所以对咱们研发同学来说，只有批改一个 maven 的版本号。2.3 成果从目前试验来看，对于 mvn build 耗时在 3 分钟以上的利用有成果。对于典型利用从 2325 秒降到 188 秒，晋升了 10 倍多。咱们再来看继续了一个时间段后的总体成果，典型利用应用 amaven 后，构建耗时 p95 的工夫有较显著降落，比照应用前后二个月的构建耗时降了 50% 左右。

 2.4 原理如果说发动机是一辆车的灵魂，那依赖治理就是 maven 的灵魂。因为 maven 就是为了系统化的治理依赖而产生的工具。应用过 maven 的同学都分明，咱们将依赖写在 pom.xml 中，而这依赖又定义了本人的依赖在本人的 pom.xml。通过 pom 文件的层次化来治理依赖确实让咱们不便很多。一次典型的 maven 构建过程，会是这样：

从上图能够看出，maven 构建次要有二个阶段，而第一阶段是第二阶段的根底，基本上大部分的插件都会应用第一阶段产生的依赖树：解析利用的 pom 及依赖的 pom，生成依赖树；在解析过程中，个别还会从 maven 仓库下载新增的依赖或更新了的 SNAPSHOT 包。执行各 maven 插件。咱们也通过剖析理论的构建日志，发现大于 3 分钟的 maven 构建，瓶颈都在“生成依赖树”阶段。而“生成依赖树”阶段慢的根本原因是一个 module 配置的依赖太多太简单，它体现为：依赖太多，则要从 maven 仓库下载的可能性越大。依赖太简单，则依赖树解析过程中递归次数越多。在 amaven 中通过优化依赖剖析算法，与晋升下载依赖速度来晋升依赖剖析的性能。除此之外，性能优化的经典思维是缓存增量，与分布式并发，咱们也遵循这个思维作了优化。在一直优化过程中，amaven 也一直地 C / S 化了，即 amaven 不再是一个 client，而有了 server 端，同时将局部简单的计算从 client 端移到了 server 端。而当 client 越做越薄，server 端的性能越来越弱小时，server 的计算所须要的资源也会越来越多，将这些资源用弹性伸缩来解决，缓缓地 amaven 云化了。从单个 client 到 C / S 化再到云化，这也是一个工具一直进化的趋势所在。2.4.1 依赖树 2.4.1.1 依赖树缓存既然依赖树生成慢，那咱们就将这依赖树缓存起来。缓存后，这依赖树能够不必反复生成，而且能够不同人，不同的机器的编译进行共享。应用依赖树缓存后，一次典型的 mvn 构建的过程如下：

 从上图中能够看到 amaven-server，它次要负责依赖树缓存的读写性能，保障存储可靠性，及保障缓存的正确性等。2.4.1.2 依赖树生成算法优化虽在日常研发过程中，批改 pom 文件的概率较批改利用 java 低，但还是有肯定概率；同时当 pom 中依赖了较多 SNAPSHOT 且 SNAPSHOT 有更新时，依赖树缓存会生效掉。所以还是会有不少的依赖树从新生成的场景。所以还是有必要来优化依赖树生成算法。在 maven2, 及 maven3 版本中，包含最新的 maven3.8.5 中，maven 是以深度优先遍历（DF）来生成依赖树的（在社区版本中，目前 master 上曾经反对 BF，但还未发 release 版本[1]。在遍历过程中通过 debug 与打日志发现有很多雷同的 gav 或雷同的 ga 会被反复剖析很屡次，甚至数万次。树的经典遍历算法次要有二种：深度优先算法（DF）及 广度优先算法（BF）,BF 与 DF 的效率其实差不多的，但当联合 maven 的版本仲裁机制思考会发现有些差别。咱们来看看 maven 的仲裁机制，无论是 maven2 还是 maven3，最次要的仲裁准则就是 depth。雷同 ga 或雷同 gav，谁更 deeper，谁就 skip，当然仲裁的因素还有 scope,profile 等。联合 depth 的仲裁机制，按层遍历（BF）会更优，也更好了解。如下图，如按层来遍历，则红色的二个 D1,D2 就会 skip 掉，不会反复解析。（留神，理论场景是 C 的 D1 还是会被解析，因为它更左）。

 算法优化的思路是：“提前修枝”。之前 maven3 的逻辑是学生成依赖树再版本仲裁，而优化后是边生成依赖树边仲裁。就好比一个树苗，要边成长边修枝，而如果等它长成了参天大树后则修枝老本更大。

 2.4.1.3 依赖下载优化 maven 在编译过程中，会解析 pom，而后一直下载间接依赖与间接依赖到本地。个别本地目录是.m2。对一线研发来说，本地的.m2 不太会去删除，所以除非有大的重构，每次编译只有大量的依赖会下载。但对于 CICD 平台来说，因为编译机个别不是独占的，而是多利用间共享的，所以为了利用间不相互影响，每次编译后可能会删除掉.m2 目录。这样，在 CICD 平台要思考.m2 的隔离，及当.m2 清理后要下载大量依赖包的场景。而依赖包的下载，是须要通过网络，所以当一次编译，如要下载上千个依赖，那构建耗时大部分是在下载包，即瓶颈是下载。1) 增大下载并发数依赖包是从 maven 仓库下载。maven3.5.0 在编译时默认是启了 5 个线程下载。咱们能够通过 aether.connector.basic.threads 来设置更多的线程如 20 个来下载，但这要求 maven 仓库要能撑得住翻倍的并发流量。所以咱们对 maven 仓库进行了架构降级，依据包不同的文件大小区间应用了本地硬盘缓存，redis 缓存等包文件多级存储来放慢包的下载。下表是对热点利用 A 用不同的下载线程数来下载 5000 多个依赖失去的下载耗时后果比拟：

 在 amaven 中咱们加了对下载耗时的统计报告，包含下载多少个依赖，下载线程是多少，下载耗时是多少，不便大家进行性能剖析。如下图：

 同时为了缩小网络开销，咱们还采纳了在编译机本地建设了 mirror 机制。2) 本地 mirror 有些利用有些简单, 它会在 maven 构建的仓库配置文件 settings.xml(或 pom 文件)中指定下载多个仓库。因为这利用的要下载的依赖确实来自多个仓库. 当指定多个仓库时, 下载一个依赖包, 会顺次从这多个仓库查找并下载。尽管 maven 的 settings.xml 语法反对多个仓库, 但 localRepository 却只能指定一个。所以要看下 docker 是否反对将多个目录 volume 到同一个容器中的目录，但初步看了 docker 官网文档, 并不反对。为解决按仓库隔离.m2, 且利用依赖多个仓库时的问题, 咱们当初通过对 amaven 的优化来解决。

  (架构 5.0:repo_mirror) 当 amaven 执行 mvn build 时, 当一个依赖包不在本地.m2 目录, 而要下载时, 会先到 repo_mirror 中对应的仓库中找, 如找到, 则从 repo_mirror 中对应的仓库中将包间接复制到.m2, 否则就只能到近程仓库下载, 下载到.m2 后, 会同时将包复制到 repo_mirror 中对应的仓库中。通过 repo_mirror 能够实现同一个构建 node 上只会下载一次同一个仓库的同一个文件。2.4.1.4 SNAPSHOT 版本号缓存其实在 amavenServer 的缓存中，除了依赖树，还缓存了 SNAPSHOT 的版本号。咱们的利用会依赖一些 SNAPSHOT 包, 同时当咱们在 mvn 构建时加上 - U 就会去检测这些 SNAPSHOT 的更新. 而在 apache-maven 中检测 SNAPSHOT 须要屡次申请 maven 仓库，会有一些网络开销。当初咱们联合 maven 仓库作了优化，从而让屡次申请 maven 仓库，换成了一次 cache 服务间接拿到 SNAPSHOT 的最新版本。

 2.4.2 增量增量是与缓存非亲非故的，增量的实现就是用缓存。maven 的开放性是通过插件机制实现的，每个插件实现具体的性能，是一个函数。当输出不变，则输入不变，即复用输入，而将每次每个函数执行后的输入缓存起来。下面讲的依赖树缓存，也是 maven 自身（非插件）的一种增量形式。要实现增量的要害是定义好一个函数的输出与输入，即要保障定义好的输出不变时，定义好的输入必定不变。每个插件本人是分明输出与输入是什么的，所以插件的增量不是由 amaven 对立实现，而是 amaven 提供了一个机制。如一个插件按约定定义好了输出与输入，则 amaven 在执行前会检测输出是否变动，如没变动，则间接跳过插件的执行，而从缓存中取到输入后果。增量的成果是显著的，如依赖树缓存与算法的优化能让 maven 构建从 10 分钟降到 2 分钟，那增量则能够将构建耗时从分钟级降到秒级。2.4.3 daemon 与分布式 daemon 是为了进一步达到 10 秒内构建的实现路径。maven 也是 java 程序，运行时要将字节码转成机器码，而这转化有工夫开销。虽这开销只有几秒工夫，但对一个 mvn 构建只有 15 秒的利用来说，所占比例也有 10% 多。为升高这工夫开销，能够用 JIT 间接将 maven 程序编译成机器码，同时 mvn 在构建实现后，常驻过程，当有新构建工作来时，间接调用 mvn 过程。个别，一个 maven 利用编译不会超过 10 分钟，所以，看上去没必要将构建工作拆成子工作，再调度到不同的机器上执行分布式构建。因为散布式调度有工夫开销，这开销可能比间接在本机上编译耗时更大，即得失相当。所以分布式构建的应用场景是大库。为了简化版本治理，将二进制依赖转成源码依赖，将依赖较亲密的源码放在一个代码仓库中，就是大库。当一个大库有成千上万个 module 时，则非用分布式构建不可了。应用分布式构建，能够将大库几个小时的构建降到几分钟级别。三、本地 idea 环境提速 3.1 从盲侠说起已经有有一位盲人叫座头市，他双目失明，但却是一位顶尖的剑客，江湖上称他为“盲侠”。在咱们的一线研发同学中，也有不少盲侠。这些同学在本地进行写代码时，是盲写。他们写的代码只管全都显示红色警示，写的单测只管在本地没跑过，但还是照写不误。咱们个别的开发流程是，接到一个需要，从骨干拉一个分支，再将本地的代码切到这新分支，再刷新 IDEA。但有些分支在刷新后，只管等了 30 分钟，只管本人电脑的 CPU 沙沙直响，热的冒泡，但 IDEA 的工作区还是有很多红线。这些红线逼咱们不少同学走上了“盲侠”之路。一个 maven 工程的 java 利用，IDEA 的导入也是应用了 maven 的依赖剖析。而咱们剖析与理论观测，一个需要的开发，即在一个分支上的开发，在本地应用 maven 的次数相对比在 CICD 平台上应用的次数多。所以本地的 maven 的性能更须要晋升，更须要革新。因为它能带来更大的人效。3.2 解决方案 amaven 要联合在本地的 IDEA 中应用也很不便。1. 下载 amaven 最新版本。2. 在本地解压，如目录 /Users/userName/soft/amaven-3.5.0。3. 设置 Maven home path: 

 4. 重启 idea 后，点 import project. 

 最初咱们看看成果，对热点利用进行 import project 测试，用 maven 要 20 分钟左右，而用 amaven3.5.0 在 3 分钟左右，在命中缓存状况下最佳能到 1 分钟内。简略四步后，咱们就不必再当“盲侠”了，在本地能够流畅地编码与跑单元测试。除了在 IDEA 中应用 amaven 的依赖剖析能力外，在本地通过命令行来运行 mvn compile 或 dependency:tree，也齐全兼容 apache-maven 的。3.3 原理 IDEA 是如何调用 maven 的依赖分析方法的？在 IDEA 的源码文件 [2] 中 979 行，调用了 dependencyResolver.resolve(resolution)办法：

 dependencyResolver 就是通过 maven home path 指定的 maven 目录中的 DefaultProjectDependenciesResolver.java。

 而 DefaultProjectDependenciesResolver.resolve()办法就是依赖剖析的入口。IDEA 次要用了 maven 的依赖剖析的能力，在“maven 构建提速”这一大节中，咱们曾经讲了一些 amaven 减速的原理，其中依赖算法从 DF 换到 BF，依赖下载优化，整个依赖树缓存，SNAPSHOT 缓存这些个性都是与依赖剖析过程相干，所以都能用在 IDEA 提速上，而依赖仓库 mirror 等因为在咱们本人的本地个别不会删除.m2，所以不会有所体现。amaven 能够在本地联合 IDEA 应用，也能够在 CICD 平台中应用，只是它们调用 maven 的办法的形式不同或入口不同而已。但对于 maven 协定来说“灵魂”的还是依赖治理与依赖剖析。四、docker 构建提速 4.1 背景自从阿里巴巴团体容器化后，开发人员常常被镜像构建速度困扰，每天要公布很屡次的利用体感尤其不好。咱们几年前曾经按最佳实际举荐每个利用要把镜像拆分成根底镜像和利用镜像，然而高频批改的利用镜像的构建速度仍然不尽如人意。为了跟上支流技术的倒退，咱们打算把 CICD 平台的构建工具降级到 moby-buildkit，docker 的最新版本也打算把构建切换到 moby- buildkit 了，这个也是业界的趋势。同时在 buildkit 根底上咱们作了一些加强。4.2 加强 4.2.1 新语法 SYNC 咱们先用增量的思维，绝对于 COPY 减少了一个新语法 SYNC。咱们剖析 java 利用高频构建局部的镜像构建场景，高频状况下只会执行 Dockerfile 中的一个指令：COPY appName.tgz /home/appName/target/appName.tgz 发现大多数状况下 java 利用每次构建尽管会生成一个新的 app.war 目录，然而外面的大部分 jar 文件都是从 maven 等仓库下载的，它们的创立和批改工夫尽管会变动然而内容的都是没有变动的。对于一个 1G 大小的 war，每次公布变动的文件均匀也就三十多个，大小加起来 2 -3 M，然而因为这个 appName.war 目录是全新生成的，这个 copy 指令每次都须要全新执行，如果全副拷贝，对于略微大点的利用这一层就占有 1G 大小的空间，镜像的 copy push pull 都须要解决很多反复的内容，耗费无谓的工夫和空间。如果咱们能做到定制 dockerfile 中的 copy 指令，拷贝时像 Linux 下面的 rsync 一样只做增量 copy 的话，构建速度、上传速度、增量下载速度、存储空间都能失去很好的优化。因为 moby-buildkit 的代码架构分层比拟好，咱们基于 dockerfile 前端定制了外部的 SYNC 指令。咱们扫描到 SYNC 语法时，会在前端生成原生的两个指令，一个是从基线镜像中 link 拷贝原来那个目录（COPY），另一个是把两个目录做比拟（DIFF），把有变动的文件和删除的文件在新的一层下面失效，这样在基线没有变动的状况下，就做到了高频构建每次只拷贝上传下载几十个文件仅几兆内容的这一层。而用户要批改的，只是将原来的 COPY 语法批改成 SYNC 就行了。如将：COPY appName.tgz /home/admin/appName/target/appName.tgz 批改为：SYNC appName.dir /home/admin/appName/target/appName.war 咱们再来看看 SYNC 的成果。团体最外围的热点利用 A 切换到 moby-buildkit 以及咱们的 sync 指令后 90 分位镜像构建速度曾经从 140 秒左右升高到 80 秒左右：

 4.2.2 none-gzip 实现为了让 moby- buildkit 能在 CICD 平台下面用起来，首先要把 none-gzip 反对起来。这个需要在 docker 社区也有很多探讨[3]，外部环境网络速度不是问题，如果有 gzip 会导致 90% 的工夫都花在压缩和解压缩下面，构建和下载工夫会加倍，公布环境拉镜像的时候主机上一些 CPU 也会被 gzip 解压打满，影响同主机其它容器的运行。尽管 none-gzip 后，CPU 不会高，但会让上传下载等传输过程变慢，因为文件不压缩变大了。但绝对于 CPU 资源来说，内网状况下带宽资源不是瓶颈。只须要在上传镜像层时按配置跳过 gzip 逻辑去掉，并把镜像层的 MediaType 从 application/vnd.docker.image.rootfs.diff.tar.gzip 改成 application/vnd.docker.image.rootfs.diff.tar 就能够在内网环境下充沛提速了。4.2.3 单层内并发下载在 CICD 过程中，即便是同一个利用的构建，也可能会被调度到不同的编译机上。即便构建调度有肯定的亲和性。为了让新构建机，或利用换构建机后能疾速拉取到根底镜像，因为咱们以前的最佳实际是要求用户把镜像分成两个（根底镜像与利用镜像），而根底镜像个别单层就有超过 1G 大小的，多层并发拉取对于单层特地大的镜像曾经没有成果。所以咱们在“层间并发拉取”的根底上，还减少了“层内并发拉取”，让拉镜像的速度晋升了 4 倍左右。当然实现这层内并发下载是有前提的，即镜像的存储须要反对分段下载。因为咱们公司是用了阿里云的 OSS 来存储 docker 镜像，它反对分段下载或多线程下载。4.2.4 无核心 P2P 下载当初都是用 containerd 中的 content store 来存储镜像原始数据，也就是说每个节点自身就存储了一个镜像的所有原始数据 manifest 和 layers。所以如果多个相邻的节点，都须要拉镜像的话，能够先看到核心目录服务器上查看街坊节点下面是否曾经有这个镜像了，如果有的话就能够间接从街坊节点拉这个镜像。而不须要走镜像仓库去取镜像 layer，而 manifest 数据还必须从仓库获取是为了避免镜像名对应的数据曾经产生了变动了，只有取到 manifest 后其它的 layer 数据都能够从相邻的节点获取，每个节点能够只在每一层下载后的五分钟内（工夫可配置）提供共享服务，这样大概率还能用到本地 page cache，而不必真正读磁盘。

 核心 OSS 服务总共只能提供最多 20G 的带宽，从历史拉镜像数据能看到每个节点的下载速度都很难超过 30M，然而咱们当初每个节点都是 50G 网络，节点相互之间共享镜像层数据能够充分利用到节点本地的 50G 网络带宽，当然为了不影响其它服务，咱们把镜像共享的带宽管制在 200M 以下。4.2.5 镜像 ONBUILD 反对社区的 moby-buidkit 曾经反对了新的 schema2 格局的镜像的 ONBUILD 了，然而团体外部还有很多利用 FROM 的根底镜像是 schema1 格局的根底镜像，这些根底镜像中很多都很奇妙的用了一些 ONBUILD 指令来缩小 FROM 它的 Dockerfile 中的公共构建指令。如果不能解析 schema1 格局的镜像，这部分利用的构建尽管会胜利，然而其实很多应该执行的指令并没有执行，对于这个能力缺失，咱们在外部补上的同时也把这些批改回馈给了社区 [4]。五、JDK 提速 5.1 AppCDS5.1.1 现状 CDS(Class Data Sharing)[5] 在 Oracle JDK1.5 被首次引入，在 Oracle JDK8u40[6]中引入了 AppCDS，反对 JDK 以外的类，然而作为商业个性提供。随后 Oracle 将 AppCDS 奉献给了社区，在 JDK10 中 CDS 逐步欠缺，也反对了用户自定义类加载器 (又称 AppCDS v2[7])。目前 CDS 在阿里的落地状况：热点利用 A 应用 CDS 缩小了 10 秒启动工夫云产品 SAE 和 FC 在应用 Dragonwell11 时开启 CDS、AOT 等个性减速启动通过十年的倒退，CDS 曾经倒退为一项成熟的技术。然而很容易令人不解的是 CDS 不论在阿里的业务还是业界(即使是 AWS Lambda) 都没能被大规模应用。要害起因有两个:5.1.1.1 AppCDS 在实践中成果不显著 jsa 中存储的 InstanceKlass 是对 class 文件解析的产物。对于 boot classloader(加载 jre/lib/rt.jar 上面的类的类加载器)和 system(app) 类加载器 (加载 -classpath 上面的类的类加载器)，CDS 有外部机制能够跳过对 class 文件的读取，仅仅通过类名在 jsa 文件中匹配对应的数据结构。Java 语言还提供用户自定义类加载器(custom class loader) 的机制，用户通过 Override 本人的 Classloader.loadClass() 查找类，AppCDS 在为 customer class loade 时加载类是须要通过如下步骤: 调用用户定义的 Classloader.loadClass()，拿到 class byte stream 计算 class byte stream 的 checksum，与 jsa 中的同类名构造的 checksum 比拟如果匹配胜利则返回 jsa 中的 InstanceKlass，否则持续应用 slow path 解析 class 文件 5.1.1.2 工程实际不敌对应用 AppCDS 须要如下步骤: 针对以后版本在生产环境启动利用，收集 profiling 信息基于 profiling 信息生成 jsa(java shared archive) dump 将 jsa 文件和利用自身打包在一起，公布到生产环境因为这种 trace-replay 模式的复杂性，在 SAE 和 FC 云产品的落地都是通过公布流程的定制以及开发简单的命令行工具来解决的。5.1.2 解决方案针对上述的问题 1，在热点利用 A 上 CDS 配合 JarIndex 或者应用编译器团队开发的 EagerAppCDS 个性 (原理见 5.1.3.1) 都能让 CDS 施展最佳成果。教训证，在热点利用 A 曾经应用 JarIndex 做优化的前提下进一步应用 EagerAppCDS 仍然能够取得 15 秒左右的启动减速成果。5.1.3 原理面向对象语言将对象 (数据) 和办法 (对象上的操作) 绑定到了一起，来提供更强的封装性和多态。这些个性都依赖对象头中的类型信息来实现，Java、Python 语言都是如此。Java 对象在内存中的 layout 如下：

mark 示意了对象的状态，包含是否被加锁、GC 年龄等等。而 Klass* 指向了形容对象类型的数据结构 InstanceKlass : 

 基于这个构造，诸如 o instanceof String 这样的表达式就能够有足够的信息判断了。要留神的是 InstanceKlass 构造比较复杂，蕴含了类的所有办法、field 等等，办法又蕴含了字节码等信息。这个数据结构是通过运行时解析 class 文件取得的，为了保障安全性，解析 class 时还须要校验字节码的合法性 (非通过 javac 产生的办法字节码很容易引起 jvm crash)。CDS 能够将这个解析、校验产生的数据结构存储(dump) 到文件，在下一次运行时重复使用。这个 dump 产物叫做 Shared Archive，以 jsa 后缀(java shared archive)。为了缩小 CDS 读取 jsa dump 的开销，防止将数据反序列化到 InstanceKlass 的开销，jsa 文件中的存储 layout 和 InstanceKlass 对象齐全一样，这样在应用 jsa 数据时，只须要将 jsa 文件映射到内存，并且让对象头中的类型指针指向这块内存地址即可，非常高效。

 5.1.3.1 Alibaba Dragonwell 对 AppCDS 的优化上述 AppCDS for custom classloader 的加载流程更加简单的起因是 JVM 通过 (classloader, className) 二元组来惟一确定一个类。对于 BootClassloader、AppClassloader 在每次运行都是惟一的，因而能够在屡次运行之间确定惟一的身份对于 customClassloader 除了类型，并没有显著的惟一标识。AppCDS 因而无奈在加载类阶段通过 classloader 对象和类型去 shared archive 定位到须要的 InstanceKlass 条目。Dragonwell 提供的解决办法是让用户为 customClassloader 标识惟一的 identifier，加载雷同类的 classloader 在屡次运行间放弃惟一的 identifier。并且扩大了 shared archive，记录用户定义的 classloader identifier 字段，这样 AppCDS 便能够在运行时通过 (identifier, className) 二元组来迅速定位到 shared archive 中的类条目。从而让 custom classloader 下的类加载能和 buildin class 一样快。在常见的微服务 workload 下，咱们能够看到 Dragonwell 优化后的 AppCDS 将根底的 AppCDS 的减速成果从 10% 晋升到了 40%。5.2 启动 profiling 工具 5.2.1 现状目前有很多 Java 性能分析工具，但专门用于 Java 启动过程剖析的还没有。不过有些现有的工具，能够间接用于启动过程剖析，因为不是专门的工具，每个都存在这样那样的有余。比方 async-profiler，其强项是适宜诊断 CPU 热点、墙钟热点、内存调配热点、JVM 内锁争抢等场景，展示模式是火焰图。能够在利用刚刚启动后，马上开启 aync-profiler，继续分析直到利用启动实现。async-profiler 的 CPU 热点和墙钟热点能力对于剖析启动过程有很大帮忙，能够找到占用 CPU 较多的办法，进而领导启动减速的优化。async-profiler 有 2 个次要毛病，第 1 个是展示模式较繁多，关联剖析能力较弱，比方无奈抉择特定工夫区间，也无奈反对选中多线程场景下的火焰图聚合等。第 2 个是采集的数据品种较少，看不到类加载、GC、文件 IO、SocketIO、编译、VM Operation 等方面的数据，没法做精密的剖析。再比方 arthas，arthas 的火焰图底层也是利用 async-profiler，所以 async-profiler 存在的问题也无奈回避。最初咱们天然会想到 OpenJDK 的 JDK Flight Recorder，简称 JFR。AJDK8.5.10+ 和 AJDK11 反对 JFR。JFR 是 JVM 内置的诊断工具，相似飞机上的黑匣子，能够低开销的记录很多要害数据，存储到特定格局的 JFR 文件中，用这些数据能够很不便的还原利用启动过程，从而领导启动优化。JFR 的毛病是有肯定的应用门槛，须要对虚拟机有肯定的了解，高级配置也较简单，同时还须要搭配桌面软件 Java Mission Control 能力解析和浏览 JFR 文件。面对上述问题，JVM 工具团队进行了深刻的思考，并逐渐迭代开发出了针对启动过程剖析的技术产品。5.2.2 解决方案 1、咱们抉择 JFR 作为利用启动性能分析的根底工具。JFR 开销低，内建在 JDK 中无第三方依赖，且数据丰盛。JFR 会周期性记录 Running 状态的线程的栈，能够构建 CPU 热点火焰图。JFR 也记录了类加载、GC、文件 IO、SocketIO、编译、VM Operation、Lock 等事件，能够回溯线程的要害流动。对于晚期版本 JFR 可能存在性能问题的个性，咱们也反对主动切换到 aync-profiler 以更低开销实现雷同性能。2、为了升高 JFR 的应用门槛，咱们封装了一个 javaagent，通过在启动命令中减少 javaagent 参数，即可疾速应用 JFR。咱们在 javaagent 中内置了文件收集和上传性能，买通数据收集、上传、剖析和交互等关键环节，实现开箱即用。3、咱们开发了一个 Web 版本的分析器（或者平台），它接管到 javaagent 收集上传的数据后，便能够间接查看和剖析。咱们开发了性能更丰盛和易用的火焰图和线程流动图。在类加载和资源文件加载方面咱们也做了专门的剖析，相似 URLClassLoader 在大量 Jar 包场景下的 Class Loading 开销大、Tomcat 的 WebAppClassLoader 在大量 jar 包场景下 getResource 开销大、并发管制不合理导致锁争抢线程期待等问题都变得不言而喻，将来还将提供评估开启 CDS（Class Data Sharing）以及 JarIndex 后能够节省时间的预估能力。5.2.3 原理当 Oracle 在 OpenJDK11 上开源了 JDK Flight Recorder 之后，阿里巴巴也是作为次要的贡献者，与社区包含 RedHat 等，一起将 JFR 移植到了 OpenJDK 8。JFR 是 OpenJDK 内置的低开销的监控和性能分析工具，它深度集成在了虚拟机各个角落。JFR 由两个局部组成：第 1 个局部散布在虚拟机的各个要害门路上，负责捕捉信息；第 2 个局部是虚拟机内的独自模块，负责接管和存储第 1 个局部产生的数据。这些数据通常也叫做事件。JFR 蕴含 160 种以上的事件。JFR 的事件蕴含了很多有用的上下文信息以及工夫戳。比方文件拜访，特定 GC 阶段的产生，或者特定 GC 阶段的耗时，相干的要害信息都被记录到事件中。只管 JFR 事件在他们产生时被创立，但 JFR 并不会实时的把事件数据存到硬盘上，JFR 会将事件数据保留在线程变量缓存中，这些缓存中的数据随后会被转移到一个 global ring buffer。当 global ring buffer 写满时，才会被一个周期性的线程长久化到磁盘。尽管 JFR 自身比较复杂，但它被设计为低 CPU 和内存占用，总体开销非常低，大概 1% 甚至更低。所以 JFR 适宜用于生产环境，这一点和很多其它工具不同，他们的开销个别都比 JFR 大。JFR 不仅仅用于监控虚拟机本身，它也容许在应用层自定义事件，让应用程序开发者能够不便的应用 JFR 的根底能力。有些类库没有预埋 JFR 事件，也不不便间接批改源代码，咱们则用 javaagent 机制，在类加载过程中，间接用 ASM 批改字节码插入 JFR 事件记录的能力。比方 Tomcat 的 WebAppClassLoader，为了记录 getResource 事件，咱们就采纳了这个办法。整个零碎的构造如下：

 六、ClassLoader 提速 6.1 现状团体整套电商零碎曾经运行好多年了，机器上运行的 jar 包，不会因为最近大环境不好而缩小，只会逐年递增，而中台的几个外围利用，所有业务都在下面开发，收缩得更加显著，比方热点利用 A 机器上运行的 jar 包就有三千多个，jar 包中蕴含的资源文件数量更是达到了上万级别，通过工具剖析，启动有 180 秒以上是花在 ClassLoader 上，占总耗时的 1 / 3 以上，其中占比大头的是 findResource 的耗时。不论是 loadClass 还是 getResource，最终都会调用到 findResource，慢次要是慢在资源的检索上。当初 spring 框架简直是每个 java 必备的，各种 annotation，各种扫包，尽管极大的不便开发者，但也给利用的启动带来不少的累赘。目前团体有上万多个 Java 利用，ClassLoader 如果能够进行优化，将带来十分十分可观的收益。6.2 解决方案优化的计划能够简略的用一句话概括，就是给 URLClassLoader 的资源查找加索引。6.3 提速成果目前中台外围利用都已降级，根本都有 100 秒以上的启动提速，占总耗时的 20~35%，成果非常明显！6.4 原理 6.4.1 原生 URLClassLoader 为什么会慢 java 的 JIT(just in time)即时编译，想必大家都不生疏，JDK 里不仅仅是类的装载过程按这个思维去设计的，类的查找过程也是一样的。通过研读 URLClassPath 的实现，你会发现以下几个个性：URLClassPath 初始化的时候，所有的 URL 都没有 open；findResources 会比 findResource 更快的返回，因为理论并没有查找，而是在调用 Enumeration 的 next() 的时候才会去遍历查找，而 findResource 去找了第一个；URL 是在遍历过程一一 open 的，会转成 Loader，放到 loaders 里（数组构造，决定了程序）和 lmap 中(Map 构造, 避免反复加载)；一个 URL 能够通过 Class-Path 引入新的 URL（所以，实践上是可能存在新 URL 又引入新的 URL，有限循环的场景）；因为 URL 和 Loader 是会在遍历过程中动静新增，所以 URLClassPath#getLoader(int index) 里加了两把锁；

 这些个性就是为了按需加载（懒加载），遍历的过程是 O(N)的复杂度，按程序从头到尾的遍历，而且遍历过程可能会随同着 URL 的关上，和新 URL 的引入，所以，随着 jar 包数量的增多，每次 loadClass 或者 findResources 的耗时会线性增长，调用次数也会增长（加载的类也变多了），启动就慢下去了。慢的另一个主要起因是，getLoader(int index)加了两把锁。6.4.2 JDK 为什么不给 URLClassLoader 加索引跟数据库查问一样，数量多了，加个索引，立杆奏效，那为什么 URLClassLoader 里没加索引。其实，在 JDK8 里的 URLClassPath 代码外面，是能够看到索引的踪影的，通过加“-Dsun.cds.enableSharedLookupCache=true”来关上，然而，换各种姿态尝试了数次，发现都没失效，lookupCacheEnabled 始终是 false，通过 debug 发现 JDK 启动的过程会把这个变量从 System 的 properties 里移除掉。另外，最近都在升 JDK11，也看了一下它外面的实现，发现这块代码间接被删除的干干净净，不见踪影了。通过仔细阅读 URLClassPath 的代码，JDK 没反对索引的起因有以下 3 点：起因一：跟按需加载相矛盾，且 URL 的加载有不确定性建索引就得提前将所有 URL 关上并遍历一遍，这与原先的按需加载设计相矛盾。另外，URL 的加载有 2 个不确定性：一是可能是非本地文件，须要从网络上下载 jar 包，下载可能快，可能慢，也可能会失败；二是 URL 的加载可能会引入新的 URL，新的 URL 又可能会引入新的 URL。起因二：不是所有 URL 都反对遍历 URL 的类型能够归为 3 种：1. 本地文件目录，如 classes 目录；2. 本地或者近程下载下来的 jar 包；3. 其余 URL。前 2 种是最根本最常见的，能够进行遍历的，而第 3 种是不肯定反对遍历，默认只有一个 get 接口，传入确定性的 name，返回有或者没有。起因三：URL 里的内容可能在运行时被批改比方本地文件目录（classes 目录）的 URL，就能够在运行时往改目录下动静增加文件和类，URLClassLoader 是能加载到的，而索引要反对动静更新，这个十分难。6.4.3 FastURLClassLoader 如何进行提速首先必须抵赖，URLClassLoader 须要反对所有场景都能建索引，这是有点不太事实的，所以，FastURLClassLoader 设计之初只为满足绝大部分应用场景可能提速，咱们设计了一个 enable 的开关，敞开则跟原生 URLClassLoader 是一样的。另外，一个 java 过程里常常会存在十分多的 URLClassLoader 实例，不能将所有实例都开打 fast 模式，这也是没有间接在 AliJDK 里批改原生 URLClassLoader 的实现，而是新写了个类的起因。FastURLClassLoader 继承了 URLClassLoader，外围是将 URLClassPath 的实现重写了，在初始化过程，会将所有的 Loader 进行初始化，并遍历一遍生成 index 索引，后续 findResources 的时候，不是从 0 开始，而是从 index 里获取须要遍历的 Loader 数组，这将原来的 O(N)复杂度优化到了 O(1)，且查找过程是无锁的。FastURLClassLoader 会有以下特色：特色一：初始化过程不是懒加载，会慢一些索引是在构造函数里进行初始化的，如果 url 都是本地文件（目录或 Jar 包），这个过程不会暂用过多的工夫，3000+ 的 jar，建索引耗时在 0.5 秒以内，外部会依据 jar 包数量进行多线程并发建索引。这个耗时，懒加载形式只是将它打散了，理论并没有少，而且团体大部分利用都应用了 spring 框架，spring 启动过程有各种扫包，第一次扫包，所有 URL 就都关上了。特色二：目前只反对本地文件夹和 Jar 类型的 URL 如果蕴含其余类型的 URL，会间接抛异样。尽管如 ftp 协定的 URL 也是反对遍历的，但得针对性的去开发，而且 ftp 有网络开销，可能懒加载更适宜，后续有须要再反对。特色三：目前不反对通过 META-INF/INDEX.LIST 引入更多 URL 以后正式版本反对通过 Class-Path 引入更多的 URL，但还不反对通过 META-INF/INDEX.LIST 来引入，目前还没碰用到这个的场景，但能够反对。通过 Class-Path 引入更多的 URL 比拟常见，比方 idea 启动，如果 jar 太多，会因为参数过长而无奈启动，转而抉择应用 ”JAR manifest” 模式启动。

 特色四：索引是初始化过程创立的，除了被动调用 addURL 时会更新，其余场景不会更新比方在 classes 目录下，新增文件或者子目录，将不会更新到索引里。为此，FastURLClassLoader 做了一个兜底爱护，如果通过索引找不到，会降级逐个到本地目录类型的 URL 里找一遍（大部分场景下，目录类型的 URL 只有一个），Jar 包类型的 URL 个别不会动静批改，所以没找。6.5 注意事项索引对内存的开销：索引的是 jar 包和它目录和根目录文件的关系，所以不是特地大，热点利用 A 有 3000+ 个 jar 包，INDEX.LIST 的大小是 3.2M 同名类的仲裁：tomcat 在没有 INDEX.LIST 的状况下，同名类应用哪个 jar 包中的，存在肯定不确性，增加索引后，仲裁优先级是 jar 包名称按字母排序来的，保险起见，能够对启动后利用加载的类进行比照验证。七、阿里中间件提速在阿里团体的大部分利用都是依赖了各种中间件的 Java 利用，通过对外围中间件的集中优化，晋升了各 java 利用的整体启动工夫，提速 8%。7.1 Dubbo3 启动优化 7.1.1 现状 Dubbo3 作为阿里巴巴应用最为宽泛的分布式服务框架，服务团体内数万个利用，它的重要性天然显而易见；然而随着业务的倒退，利用依赖的 Jar 包 和 HSF 服务也变得越来越多，导致利用启动速度变得越来越慢，接下来咱们将看一下 Dubbo3 如何优化启动速度。7.1.2 Dubbo3 为什么会慢 Dubbo3 作为一个优良的 RPC 服务框架，当然可能让用户可能进行灵便扩大，因而 Dubbo3 框架提供各种各样的扩大点一共 200+ 个。Dubbo3 的扩大点机制有点相似 JAVA 规范的 SPI 机制，然而 Dubbo3 设置了 3 个不同的加载门路，具体的加载门路如下：

 也就是说，一个 SPI 的加载，一个 ClassLoader 就须要扫描这个 ClassLoader 下所有的 Jar 包 3 次。以 热点利用 A 为例，总的业务 Bundle ClassLoader 数达到 582 个左右，那么所有的 SPI 加载须要的次数为: 200(spi) 3(门路) 582(classloader) = 349200 次。能够看到扫描次数靠近 35 万 次! 并且整个过程是串行扫描的，而咱们晓得 java.lang.ClassLoader#getResources 是一个比拟耗时的操作，因而整个 SPI 加载过程耗时是十分久的。7.1.3 SPI 加载慢的解决办法由咱们后面的剖析能够晓得，要想缩小耗时，第一是须要缩小 SPI 扫描的次数，第二是晋升并发度，缩小有效等待时间。第一个缩小 SPI 扫描的次数，咱们通过剖析得悉，在整个团体的业务利用中，应用到的 SPI 集中在不到 10 个 SPI，因而咱们疏理出一个 SPI 列表，在这个 SPI 列表中，默认只从 Dubbo3 框架所在 ClassLoader 的限定目录加载，这样大大降落了扫描次数，使热点利用 A 总扫描计数降落到不到 2 万 次，占原来的次数 5% 这样。第二个晋升了对多个 ClassLoader 扫描的效率，采纳并发线程池的形式来缩小期待的工夫，具体代码如下：

 7.1.4 其余优化伎俩 1、去除启动要害链路的非必要同步耗时动作，转成异步后盾解决。2、缓存启动过程中查问第三方可缓存的后果，重复重复使用。7.1.5 优化后果热点利用 A 启动工夫从 603 秒 降落到 220 秒，总体工夫降落了 383 秒 => 603 秒 降落到 220 秒，总体工夫降落了 383 秒。7.2 TairClient 启动优化背景介绍：1、tair：阿里巴巴外部的缓存服务，相似于私有云的 redis；2、diamond：阿里巴巴外部配置核心，目前曾经升级成 MSE，和私有云一样的中间件产品 7.2.1 现状目前中台根底服务应用的 tair 集群均应用独立集群，独立集群中应用多个 NS（命名空间）来辨别不同的业务域，同时局部小的业务也会和其余业务共享一个公共集群内单个 NS。晚期 tair 的集群是通过 configID 进行初始化，起初为了容灾及设计上的思考，调整为应用 username 进行初始化拜访，但 username 外部还是会应用 configid 来确定须要链接的集群。整个 tair 初始化过程中读取的 diamond 配置的流程如下：1、依据 userName 获取配置信息，从配置信息中能够取得 TairConfigId 信息，用于标识所在集群 dataid：ocs.userinfo.{username}group : DEFAULT_GROUP 

 2、依据 ConfigId 信息，获取以后 tair 的路由规定，规定某一个机房会拜访的集群信息。dataId: {tairConfigId}group : {tairConfigId}.TGROUP 通过该配置能够确定以后机房会拜访的指标集群配置，以机房 A 为例，对应的配置集群 tair.mdb.mc.XXX. 机房 A 

 3、获取对应集群的信息，确定 tair 集群的 cs 列表 dataid：{tairConfigId} // tair.mdb.mc.uicgroup : {tairClusterConfig} // tair.mdb.mc.uic. 机房 A 

 从下面的剖析来看，在每次初始化的过程中，都会拜访雷同的 diamond 配置，在初始化多个同集群的 namespace 的时候，局部要害配置就会屡次拜访。但理论这部分 diamond 配置的数据自身是完全一致。因为 diamond 自身为了爱护本身的稳定性，在客户端对拜访单个配置的频率做了管制，超过肯定的频率会进入期待超时阶段，这一部分导致了利用的启动提早。在一分钟的工夫窗口内，限度单个 diamond 配置的拜访次数低于 -DlimitTime 配置，默认配置为 5，对于超过限度的配置会进入期待状态。

 7.2.2 优化计划 tair 客户端进行革新，启动过程中，对 Diamond 的配置数据做缓存，配置监听器保护缓存的数据一致性，tair 客户端启动时，优先从缓存中获取配置，当缓存获取不到时，再重新配置 Diamond 配置监听及获取 Diamond 配置信息。7.3 SwitchCenter 启动优化背景介绍：SwitchCenter：阿里巴巴团体外部的开关平台，对应阿里云 AHAS 云产品 [8]7.3.1 现状 All methods add synchronized made this class to be thread safe. switch op is not frequent, so don’t care about performance here. 这是 switch 源码里寄存各个 switch bean 的 SwitchContainer 中的正文，可见过后的作者认为 switch bean 只需初始化一次，自身对性能的影响不大。但没有预料到随着业务的增长，switch bean 的初始化可能会成为利用启动的瓶颈。业务平台的定位导致了平台启动期间有大量业务容器初始化，因为 switch 中间件的大部分办法全副被 synchronized 润饰，因而所有利用容器初始化到了加载开关配置时(入口为 com.taobao.csp.switchcenter.core.SwitchManager#init()) 就须要串行执行，重大影响启动速度。7.3.2 解决方案去除了要害门路上的所有锁。7.3.3 原理本次降级将寄存配置的外围数据结构批改为了 ConcurrentMap，并基于 putIfAbsent 等 j.u.c API 做了小重构。值得关注的是批改后原先串行的对 diamond 配置的获取变成了并行，触发了 diamond 服务端限流，在大量获取雷同开关配置的状况下有很大概率抛异样启动失败。

  (如图: 去锁后，配置获取的总次数不变，然而申请速率变快) 为了防止上述问题: 在本地缓存 switch 配置的获取 diamond 监听 switch 配置的变更，确保即便 switch 配置被更新，本地的缓存仍然是最新的 7.4 TDDL 启动优化背景介绍：TDDL：基于 Java 语言的分布式数据库系统，外围能力包含：分库分表、通明读写拆散、数据存储平滑扩容、成熟的管控零碎。7.4.1 现状 TDDL 在启动过程，随着分库分表规定的减少，启动耗时呈线性上涨趋势，在国际化多站点的场景下，耗时增长会特地显著，未优化前，咱们一个外围利用 TDDL 启动耗时为 120 秒 +（6 个库），单个库启动耗时 20 秒 +，且通过多个库并行启动，无奈无效升高耗时。7.4.2 解决方案通过工具剖析，发现将分库分表规定转成 groovy 脚本，并生成 groovy 的 class，这块逻辑总耗时十分久，调用次数十分多，且 groovy 在 parseClass 外头有加锁（所以并行无成果）。调用次数多，是因为生成 class 的个数，会剩以物理表的数量，比方配置里只有一个逻辑表 + 一个规定（不同表的规定也存在大量反复），分成 1024 张物理表，理论启动时会产生 1024 个规定类，存在大量的反复，不仅启动慢，还节约了很多 metaspace。优化计划是新增一个全局的 GuavaCache，将规定和生成的规定类实例寄存进去，防止雷同的规定去创立不同的类和实例。

 八、其余提速除了后面几篇文章提到的优化点（ClassLoader 优化、中间件优化等）以外，咱们还对中台外围利用做了其余启动优化的工作。8.1 aspectj 相干优化 8.1.1 现状在进行启动耗时诊断的时候，意外发现 aspectj 耗时特地久，达到了 54 秒多，不可承受。

通过定位发现，如果利用里有应用到通过注解来判断是否增加切面的规定，aspectj 的耗时就会特地久。以下是热点利用 A 中的例子：

8.1.2 解决方案将 aspectj 相干 jar 包版本升级到 1.9.0 及以上，热点利用 A 降级后，aspectj 耗时从 54.5 秒降到了 6.3 秒，提速 48 秒多。

另外，须要被 aspectj 辨认的 annotation，RetentionPolicy 须要是 RUNTIME，不然会很慢。

8.1.3 原理通过工具采集到老版本的 aspectj 在判断一个 bean 的 method 上是否有 annotation 时的代码堆栈，发现它去 jar 包里读取 class 文件并解析类信息，耗时耗在类搜寻和解析上。当看到这个的时候，第一反馈就是，java.lang,Method 不是有 getAnnotation 办法么，为什么要绕一圈本人去从 jar 包里解析进去。不太了解，就尝试去看看最新版本的 aspectj 这块是否有改变，最终发现降级即可解决。aspectj 去 class 原始文件中读取的起因是 annotation 的 RetentionPolicy 如果不是 RUNTIME 的话，运行时是获取不到的，详见：java.lang.annotation.RetentionPolicy 的正文

1.8.8 版本在判断是否有注解的逻辑：

1.9.8 版本在判断是否有注解的逻辑：与老版本的差别在于会判断 annotation 的 RetentionPolicy 是不是 RUNTIME 的，是的话，就间接从 Method 里获取了。

老版本 aspectj 的相干执行堆栈：（格局：工夫 | 类名 | 办法名 | 行数）

8.2 tbbpm 相干优化（javassist & javac）8.2.1 现状中台大部分利用都应用 tbbpm 流程引擎，该引擎会将流程配置文件编译成 java class 来进行调用，以晋升性能。tbbpm 默认是应用 com.sun.tools.javac.Main 工具来实现代码编译的，通过工具剖析，发现该过程特地耗时，交易利用 A 这块耗时在 57 秒多。8.2.2 解决方案通过采纳 javassist 来编译 bpm 文件，利用 A 预编译 bpm 文件的耗时从 57 秒多降到了 8 秒多，快了 49 秒。8.2.3 原理 com.sun.tools.javac.Main 执行编译时，会把 classpath 传进去，自行从 jar 包里读取类信息进行编译，一样是慢在类搜寻和解析上。而 javassist 是应用 ClassLoader 去获取这些信息，依据后面的文章“ClassLoader 优化篇”，咱们对 ClassLoader 加了索引，极大的晋升搜寻速度，所以会快十分多。javac 编译相干执行堆栈：（格局：工夫 | 类名 | 办法名 | 行数）

九、继续地 … 激情一辆车，能够从直升机上跳伞，也能够飞驰在冰海上，甚至能够装置上火箭引擎上太空。上天入地没有什么不可能，只有有设想，有翻新。咱们的研发基础设施与工具还在路上，还在一直革新的路上，还有很多的速度与激情能够谋求。参考链接：[1]https://github.com/apache/mav…[2]https://github.com/JetBrains/…[3]https://github.com/moby/moby/…[4]https://github.com/moby/build…[5]https://docs.oracle.com/javas…[6]https://docs.oracle.com/javas…[7]https://openjdk.java.net/jeps…[8]https://help.aliyun.com/docum… 举荐浏览 1. 研发效力的思考总结 2. 对于技术能力的思考和总结 3. 如何结构化和清晰地进行表白《Java 开发手册（嵩山版）》《Java 开发手册》始于阿里外部规约，在寰球 Java 开发者共同努力下，已成为业界广泛遵循的开发标准，手册涵盖编程规约、异样日志、单元测试、平安规约、MySQL 数据库、工程规约、设计规约七大维度。《Java 开发手册（嵩山版）》通过一直地精进与苦练终于出山啦，它的内功晋升之处在于根据约束力强弱及故障敏感性，规约顺次分为【强制】、【举荐】、【参考】三大类。最初，祝各位码林高手可能码出高效，码出品质！点击这里，查看详情。原文链接：https://click.aliyun.com/m/10… 本文为阿里云原创内容，未经容许不得转载。