简介: Java 应用部署到预发一般都要等待漫长的编译打包时间,本文将为你们讲解提高编译速度的方法。缓存
原文连接
以前我司每一个 Java 应用部署到预发都要等待漫长的编译打包时间,很是地痛苦!大项目编译时间经常达到接近 10 分钟,生命短暂啊,人生有多少个 10 分钟能够等待,因而咱们的效能团队针对编译做了一些优化,提速很是明显,对某个应用的测试来看,编译时间从 160 s 缩短到了 50 s 左右,提高近 70%,你们纷纷点赞,那么效能团队作了哪些措施来让编译速度提高这么明显呢?
首先要说的是咱们用的 Gradle 来做为咱们的构建工具,因此主要是针对 Gradle 的命令来做了一些优化。分布式
什么是 build cache(构建缓存),在 Gradle 中,每个待编译的工程叫 Project,每个 Project 在构建时都包含一系列的 task。
每一个 task 的输入均可以做为下一个 task 的输出,build cache 作的事就是把能够缓存(注:并非全部的 task 输出都能缓存)的 task 输出都缓存住,这样在构建过程当中,若是发现这个 task 的输入不变,就不必从新执行任务了,直接从 task ouput 缓存里拿便可,以下图示,Build 2 的构建输入直接从 Build Cache 中拿,这样 Build 1 就不用构建了。
效果怎么样呢,看下图,下面图分别显示了 Gradle 持续集成时使用构建缓存和不使用构建缓存两种状况下的聚合的构建时间,能够看到使用了 cache 的 Gradle 构建速度明显快于不使用 cache 的状况。
更骚的是这个 Buiid Cache 支持分布式的,能够统一把这些 cache 丢到一台机器上,本地机器要编译时统一去这台机器拉 cache,这样若是咱们切换分支时执行构建也能用 Build Cache 来加快构建速度。
--build-cache 的具备使用须要注意一些事项,好比得 Gradle 4.3 以上才有效,建议你们直接去官网查查看。模块化
并行执行在多项目编译的项目中能有效提高编译的速度,可是并行执行的前提是每一个项目已经被模块化,每一个项目之间没有耦合。工具
原来 gradle build 有加这个参数,这个参数会忽略缓存,强制从新下载,显然是编译的瓶颈。测试
原来 Jenkins 中执行 Gradle 编译任务,每一个 Task 是串行执行的,总编译耗时是每一个任务执行时间的总和。
如今把它改为了并行的
显然并行执行会快得多。gradle
对于业务方来讲,采用这种方式也是提高编译速度的有效手段 ,将大量代码抽成 jar 包,意味着它们自己就是字节码了,在 gradle build 时就不用编译啦。天然能提高整个工程的编译打包时间。优化
来源 | 码海 做者 | 码海