飞书 Android 升级 JDK 11 引发的 CI 构建性能问题

动手点关注干货不迷路 👆

一、摘要

本文从飞书 Android 升级 JDK 11 意外引发的 CI 构建性能劣化谈起,结合高版本 JDK 在 Docker 容器和 GC 方面的新特性,深挖 JVM 和 Gradle 的源码实现,抽丝剥茧地介绍了分析过程和修复方法,供其他升级 JDK 的团队参考。

二、背景

最近飞书适配 Android 12 时把 targetSdkVersion 和 compileSdkVersion 改成了 31,改完后遇到了如下的构建问题。

a7345d14a8fcae48abe2ad06caa6930b.png

在 StackOverflow 上有不少人遇到同样的问题,简单无侵入的解决方案是把构建用的 JDK 版本从 8 升到 11。

1efb142fe13a58b4e31fe6231141ffe2.png

飞书目前用的 AGP 是 4.1.0,考虑到将来升级 AGP 7.0 会强制要求 JDK 11,而且新版 AS 已经做了铺垫,所以就把构建用的 JDK 版本也升到了 11。

62c99450a54948875bc980ba478b3033.png

三、问题

升级后不少同学反馈子仓发组件(即发布 AAR)很慢,看大盘指标确实上涨了很多。

c2ccf30c250950da75236a220a353b84.png

除了子仓发组件指标明显上升,每周例行分析指标时发现主仓打包指标也明显上升,从 17m上升到了 26m,涨幅约 50%。

7be0a276ce28582eca46ba7d17977279.png

四、分析

1.主仓打包和子仓发组件变成了单线程

子仓发组件指标和主仓打包指标,都在 06-17 劣化到了峰值,找了 06-17 主仓打包最慢的 10 次构建进行分析。

f0dbe763e5036c02d177b9da95ee8b2f.png

初步分析就有一个大发现:10 次构建都是单线程。

8dd17315d4568b7539b70e5aa1c405ef.png

而之前正常的构建是并发的

2e50eb2ce03f839ae1efaa47d8c5ea20.png

子仓发组件的情况也一样,由并发发布变成了单线程发布。

c0ea1de2c68effaea9f0ac1ab15dcdf5.png

4f4408db64f038a8549b2ab45cca1d53.png

2.并发变单线程和升级 JDK 有关

查了下并发构建相关的属性,org.gradle.parallel 一直为 true,并没有更改。然后对比机器信息,发现并发构建用的是JDK 8,可用核心数是 96;单线程构建用的是 JDK 11,可用核心数是 1。初步分析,问题应该就在这里,从 JDK 8 升到 JDK 11 后,由并发构建变成了单线程构建,导致耗时明显上升。而且升级 JDK 11 的修改是在 06-13 合入主干的,06-14 构建耗时明显上升,时间上吻合。

898b259e7f40f94248bb07417400a248.png

53047b49d388c09a44c6d9c44d174fdf.png

3.整体恢复了并发,但指标没下降

为了恢复并发构建,容易联想到另一个相关的属性 org.gradle.workers.max。

35355b600e5b45366af8a3403d35050d.png

由于 PC 和服务器可用核心数有差异,为了不写死,就试着在 CI 打包时动态指定了 --max-workers 参数。设置参数后主仓打包恢复了并发构建,子仓发组件也恢复了并发。

bfae7fe63b1872e4624d06511b44d7d5.png

但观察了一周大盘指标后,发现构建耗时并没有明显的回落,稳定在 25 m,远高于之前 17 m的水平。

575d2e681465d237e64b3ed31741895d.png

4.重点 Task 的耗时没下降

细化分析,发现 ByteXTransform(ByteX是字节推出的基于 AGP Transform 的开源字节码处理框架,通过把多个串行执行重复 IO 的 Transform 整合成一个 Transform 和并发处理 Class来优化 Transform 性能,详见相关资料)和 DexBuilder 的走势和构建整体的走势一致,06-21 后都维持在高位,没有回落。ByteXTransform 劣化了约 200 s,DexBuilder 劣化了约 200 s,而且这两个 Task 是串行执行,合在一起劣化了约 400 s,接近构建整体的劣化9 m。GC 情况在 06-21 后也没有好转。

38ef39b3f72f4f871cab8acfe6ac723d.png

3d8f6f78b3abd18cb6e4d4befa7ae56b.png

6041991740912e36e2262fd82b084bd9.png

5.获取 CPU 核心数的 API 有变化

进一步分析发现其他 Transform (由于历史原因,有些 Transform 还没有接入 ByteX)并没有劣化,只有 ByteXTransform 明显劣化了 200s。联想到 ByteXTransform 内部使用了并发来处理 Class,而其他 Transform 默认都是单线程处理 Class,排查的同学定位到了一行可能出问题的代码。

0683a4341a032a3030f958477c338ff6.png

调试 DexBuilder 时发现核心逻辑 convertToDexArchive 也是并发执行。

9ea96c7f30bf8a09a3faacaa0bc781f9.png

再联想到虽然使用 --max-workers 恢复了并发构建,但 OsAvailableProcessors 字段仍然为 1,而这个字段在源码中是通过下面的 API 获取的ManagementFactory.getOperatingSystemMXBean().getAvailableProcessors()

939293840edd6ebef37660055d8c7acb.png

ManagementFactory.getOperatingSystemMXBean().getAvailableProcessors() 和Runtime.getRuntime().availableProcessors() 的效果一样,底层也是 Native 方法。综上推断,可能是 JDK 11 的 Native 实现导致了获取核心数的 API 都返回了 1,从而导致虽然构建整体恢复了并发,但依赖 API 进行并发设置的 ByteXTransform 和 DexBuilder 仍然有问题,进而导致这两个 Task 的耗时一直没有回落。

a90bea083ea21c8f2687a8e846cebe83.png

直接在 .gradle 脚本中调用这两个 API 验证上面的推断,发现返回的核心数果然从 96 变成了 1。

f97c6ccfb4dd50ff81f623fa0425487c.png

542eee1b369a10c9af3d96e3915d0735.png

另外有同学发现并不是所有的 CI 构建都发生了劣化,只有用 Docker 容器的 CI 构建发生了明显的劣化,而 Linux 原生环境下的构建正常。所以获取核心数的 Native 实现可能和 Docker 容器有关。

GC 劣化推断也是同样的原因。下面用 -XX:+PrintFlagsFinal 打印所有的 JVM 参数来验证推断。可以看到单线程构建用的是 SerialGC,GC 变成了单线程,没能利用多核优势,GC 耗时占比高。并发构建用的是 G1GC,而且 ParallelGCThreads = 64,ConcGCThreads = 16(约是 ParallelGCThreads 的 1/4),GC 并发度高,兼顾 Low Pause 和 High Throughput,GC 耗时占比自然就低。

// 单线程构建时 GC 相关的参数值
bool UseG1GC              = false       {product} {default}
bool UseParallelGC        = false       {product} {default}
bool UseSerialGC          = true        {product} {ergonomic}
uint ParallelGCThreads    = 0           {product} {default}  
uint ConcGCThreads        = 0           {product} {default}
// 并发构建时 GC 相关的参数值
bool UseG1GC              = true         {product} {ergonomic}
bool UseParallelGC        = false        {product} {default}
bool UseSerialGC          = false        {product} {default}
uint ParallelGCThreads    = 63           {product} {default}
uint ConcGCThreads        = 16           {product} {ergonomic}

22cabe65e3cbaed36ab230765851cf4e.png

7a5e762da5e0c8b7cc4d83f6f9a42f6a.png

6.Native 源码分析

下面分析下 JDK 8 和 JDK 11 获取可用核心数的 Native 实现,由于 AS 默认使用 OpenJDK,这里就用OpenJDK 的源码进行分析。

JDK 8 实现

fa59f5efd80aa2e6d346b8c0f82ce896.png

JDK 11 实现

cc097273b20678529b55d22909107cb1.png

JDK 11 默认没有设置可用核心数并开启了容器化,所以可用核心数由 OSContainer::active_processor_count() 决定。

查询 Docker 环境下的 CPU 参数并代入计算逻辑,很容易得出可用核心数是 1,从而导致 Native 方法返回 1

cat /sys/fs/cgroup/cpu/cpu.cfs_quota_us
cat /sys/fs/cgroup/cpu/cpu.cfs_period_us
cat /sys/fs/cgroup/cpu/cpu.shares

a012afc01c9546763c619860b0f0e2b2.png

五、修复

1.设置相关的 JVM 参数

总结上面的分析可知,问题的核心是在 Docker 容器默认的参数配置下 JDK 11 获取核心数的 API 返回值有了变化。Gradle 构建时 org.gradle.workers.max 属性的默认值、ByteXTransform 的线程数、DexBuilder 设置的 maxWorkers、OsAvailableProcessors 字段、GC 方式都依赖了获取核心数的 API,用 JDK 8 构建时 API 返回 96,用 JDK 11 构建时返回 1,修复的思路就是让 JDK 11 也能正常返回 96。

从源码看,修复该问题主要有两种办法:

a649957b74f44ce91217b60c59a2260b.png

  1. 设置 -XX:ActiveProcessorCount=[count],指定 JVM 的可用核心数

  2. 设置 -XX:-UseContainerSupport,让 JVM 禁用容器化

设置 -XX:ActiveProcessorCount=[count]

fcd6dee8af2fc4ac08123f0c74af1360.png

根据 Oracle 官方文档和源码,可以指定 JVM 的可用核心数来影响 Gradle 构建。

这个方法适用于进程常驻的场景,避免资源被某个 Docker 实例无限占用。例如 Web 服务的常驻进程,若不限制资源,当程序存在 Bug 或出现大量请求时,JVM 会不断向操作系统申请资源,最终进程会被 Kubernetes 或操作系统杀死。

设置 -XX:-UseContainerSupport

47e90753b82d420e35a060f87e2e68c3.png

根据 Oracle 官方文档和源码,通过显式设置 -XX:-UseContainerSupport 可以禁用容器化,不再通过 Docker 容器相关的配置信息来设置 CPU 数,而是直接查询操作系统来设置。

这个方法适用于构建任务耗时不长的场景,应最大程度调度资源快速完成构建任务。目前 CI 上均为短时间的构建任务,当任务完成后,Docker 实例会视情况进行缓存或销毁,资源也会被释放。

选择的参数

对于 CI 构建,虽然可以查询物理机的可用核心数,然后设置-XX:ActiveProcessorCount。但这里根据使用场景,选择了设置更简单的 -XX:-UseContainerSupport 来提升构建性能。

2.怎么设置参数

通过命令行设置

这个是最先想到的方法,但执行命令 "./gradlew clean, app:lark-application:assembleProductionChinaRelease -Dorg.gradle.jvmargs=-Xms12g -Xss4m -XX:-UseContainerSupport" 后有意外发现。虽然 OsAvailableProcessors 字段和 ByteXTransform 的耗时恢复正常;但构建整体仍然是单线程且 DexBuilder 的耗时也没回落。

这个和 Gradle 的构建机制有关。

  • 执行上面的命令时会触发 GradleWrapperMain#main 方法启动 GradleWrapperMain 进程(下面简称 wrapper 进程)

  • wrapper 进程会解析 org.gradle.jvmargs 属性,然后通过 Socket 传递给 Gradle Daemon 进程(下面简称 daemon 进程),所以上面的 -XX:-UseContainerSupport 只对 daemon 进行有效,对 wrapper 进程无效,同时 wrapper 进程也会初始化DefaultParallelismConfiguration#maxWorkerCount 然后传给 daemon 进程

  • daemon 进程禁用了容器化,所以能通过 API 获取到正确的核心数,从而正确显示 OsAvailableProcessors 字段和并发执行 ByteXTransform;但 wrapper 进程没有禁用容器化,所以获取的核心数是 1 ,传给 daemon 进程后导致构建整体和 DexBuilder 都是单线程执行。

fc4923fe782c9d378145e4e2f07980d0.png

a419fbb4ee94aee560ff1a7835e17257.png

5aec77f6cb66cba5f9c6de46407bd654.png

这里有个不好理解的点是 ByteXTransform 和 DexBuilder 都是 daemon 进程中执行的 Task,为什么 ByteXTransform 恢复正常了,而 DexBuilder 没有?

因为 ByteXTransform 内部主动调了 API ,能获取到正确的核心数,所以 ByteXTransform 可以并发执行;但 DexBuilder 受 Gradle Worker API (详见相关资料)的调度,执行时的 maxWorkers 是被动设置的(wrapper 进程传给 daemon 进程的)。如果通过 -XX:ActiveProcessorCount=[count] 给 wrapper 进程指定核心数,然后断点,会发现 maxWorkers = count 。所以当 wrapper 进程没有禁用容器化时,获取的核心数是 1,DexBuilder 会单线程执行,因而没有恢复正常。

e3cdab6db3d14735870dc234eb2063c2.png

53e1e18a59c2ee6dfc229e13af71bcaf.png

上面引出来的一个点是既然构建整体和 DexBuilder 都受 Gradle Worker API 调度,为什么之前在 CI 上执行“./gradlew clean, app:lark-application:assembleProductionChinaRelease --max-workers=96”时,构建整体恢复了并发,但 DexBuilder 仍然没有恢复正常?

因为 DexBuilder 的并发度除了受 maxWorkers 影响,还受 numberOfBuckets 的影响。

对于 Release 包,DexBuilder 的输入是上游 MinifyWithProguard (不是MinifyWithR8,因为显式关闭了R8)的输出(minified.jar),minified.jar 会分成 numberOfBuckets 个 ClassBucket,每个 ClassBucket 会作为 DexWorkActionParams 的一部分设置给 DexWorkAction,最后把 DexWorkAction 提交给 WorkerExecutor 分配的线程完成 Class 到 DexArchive 的转换

d62847799557b87195fe631bb1fbe14c.png

254bebe92fc862ddab08f73eb01cd6ea.png

14870dbc3cefe8b37574e516f5d989f4.png

默认情况下,numberOfBuckets = DexArchiveBuilderTask#DEFAULT_NUM_BUCKETS = Math.max(12 / 2, 1) = 6

da66c80c73fd5cfb4341b33633bac0e0.png

虽然通过 --max-workers 把 DexBuilder 的 maxWorkers 设置成了12,但由于 daemon 进程默认开启了容器化,通过 Runtime.getRuntime().availableProcessors() 获取的可用核心数是 1,因此 numberOfBuckets 并不是预期的 6 而是 1,所以转 dex 时不能把 Class 分组然后并发处理,导致 DexBuilder 的耗时没有恢复正常。CI 上也是一样的逻辑,numberOfBuckets 从 48 变成了 1,极大的降低了并发度。

ad65a994a15f2b734ef01113e0973340.png

所以要让构建整体恢复并发,让DexBuilder 的耗时恢复正常,还需要让 daemon进程接收的 maxWorkers 恢复正常,即让wrapper 进程获取到正确的核心数。通过给工程根目录下的 gradlew 脚本设置 DEFAULT_JVM_OPTS 可以达到这个效果。

c2a6517a9f43c23191fdd562d07420e2.png

所以最终执行如下构建命令时,wrapper 进程和 daemon 进程都能通过 API 获取到正确的核心数,从而让构建整体、ByteXTransform、DexBuilder、OsAvailableProcessors 字段显示都恢复正常。

6e0e64ec5cd4a839807892fc2021d89e.png

但上面的命令在 CI Docker 容器中执行时正常,在本地 Mac 执行时会报无法识别 UseContainerSupport。通过判断构建机器和环境(本地 Mac,CI Linux 原生环境,CI Docker 容器)动态设置参数可以解这个问题,但显然比较麻烦。

7a4af2f759f6a504134f22e261612721.png

通过环境变量设置

后来发现环境变量 JAVA_TOOL_OPTIONS 在创建 JVM 时就会检测,简单设置后对 wrapper 进程和 daemon 进程都有效,也可以解决上面所有的问题。

ad985580fb6a15ae91eb2007a699a5ce.png

选择的设置方法

对比上面两种设置方法,这里选择了更简单的即通过环境变量来设置 -XX:-UseContainerSupport。

3.新老分支同时可用

由于飞书自身的业务特点,老分支也需要长期维护,老分支上存在和 JDK 11 不兼容的构建逻辑,为了新老分支都能正常出包,需要动态设置构建用的 JDK 版本。

另外 UseContainerSupport 是 JDK 8u191 引入的(也就是说高版本的 JDK 8 也有上面的问题,教育团队升 AGP 4.1.0 时把 JDK 升到了 1.8.0_332,就遇到上面的问题),直接设置给 JDK 1.8.0_131 会无法识别,导致无法创建 JVM。

fcae29e67039309fddd4d4a96db7a8c4.png

所以飞书最终的解决方案是根据分支动态设置构建用的 JDK 版本,并且只在使用 JDK 11 时显式设置JAVA_TOOL_OPTIONS 为 -XX:-UseContainerSupport。对于其他团队,如果老分支用 JDK 11 也能正常构建,可以选择默认使用 JDK 11 且内置了该环境变量的 Docker 镜像,无需修改构建逻辑。

六、效果

06-30 22点以后合入了修改,07-01 的构建整体耗时明显下降,恢复到了 06-13(合入了 JDK 11 的升级)之前的水平,ByteXTransform 和 DexBuilder 的耗时也回落到了之前的水平,构建指标恢复正常,OsAvailableProcessors 字段也恢复正常,GC 情况恢复正常,世界又清静了。

7b9a84bb2ff579ff4cae628c3b7d6048.png

e5563f49cec4390848d58a918c0c6255.png

9e8f26bb9f94b91933ae85a3a36efecc.png

dd70da2192f6dfb73c50b1bd2ceaae25.png

ae0abd9c090215e8dad910cdf0d99b52.png

七、总结

虽然最后解决了构建性能劣化的问题,但在整个引入问题-->发现问题-->分析问题的流程中还是有不少点可以改进。比如对基础构建工具(包括Gradle、AGP、Kotlin、JDK)变更进行更充分的测试可以事前发现问题,完善的防劣化机制可以有效拦截问题,有区分度的监控报警可以及时发现劣化,强大的自动归因机制可以给分析问题提供更多输入,后面会持续完善这些方面来提供更好的研发体验。

八、致谢

在分析和修复问题的过程中,有不少同学提供线索、提出疑问、探讨修复方向,正是这些沟通和讨论促成了全面深入的归因和更优的解决方案,在此特别感谢这些同学。同时也特别感谢投稿后 Leader 的审核、评委的建议、技术学院和 PR 相关同学的支持。

九、相关资料

https://stackoverflow.com/questions/68344424/unrecognized-attribute-name-module-class-com-sun-tools-javac-util-sharednametab/69250502#69250502

https://developer.android.com/studio/releases/gradle-plugin#jdk-11

https://github.com/bytedance/ByteX

https://docs.oracle.com/en/java/javase/11/docs/api/java.management/java/lang/management/OperatingSystemMXBean.html

https://docs.oracle.com/cd/E40972_01/doc.70/e40973/cnf_jvmgc.htm#autoId2

https://www.oracle.com/technical-resources/articles/java/g1gc.html

https://docs.oracle.com/en/java/javase/11/gctuning/available-collectors.html#GUID-F215A508-9E58-40B4-90A5-74E29BF3BD3C

https://github.com/openjdk/jdk/blob/jdk8-b01/hotspot/src/os/linux/vm/os_linux.cpp

https://github.com/openjdk/jdk/blob/jdk-11%2B8/src/hotspot/os/linux/os_linux.cpp

https://github.com/openjdk/jdk/blob/jdk-11%2B8/src/hotspot/os/linux/osContainer_linux.cpp

https://www.oracle.com/java/technologies/javase/8u191-relnotes.html

https://mp.weixin.qq.com/s/AU-7IuMnRN5GQ6mx5Pht7Q

https://docs.oracle.com/en/java/javase/11/troubleshoot/environment-variables-and-system-properties.html#GUID-BE6E7B7F-A4BE-45C0-9078-AA8A66754B97

  • 1
    点赞
  • 0
    收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值