Gradle多模块构建卡在processResources任务的解决求助
Gradle多模块项目processResources任务卡顿问题排查与解决
核心症状
- 多模块项目(包含adminutils-common、adminutils-fabric、adminutils-bukkit)执行
build任务时,任意子项目的processResources任务会无响应卡顿,最长持续18分钟未结束 - 跳过adminutils-bukkit模块后,仍会卡在adminutils-fabric的
processResources任务 - 开启
--debug参数后,日志持续输出HttpClient及资源锁相关内容 - 清空
processResources代码块内容仍会卡顿,移除整个代码块则构建正常,但需要保留资源处理逻辑
可能原因分析
资源处理逻辑中的隐式网络请求
如果processResources配置了动态替换资源文件(如fabric.mod.json、plugin.yml)中的变量(例如远程拉取版本号、依赖元数据),Gradle会通过HttpClient发起网络请求。若网络环境差、远程服务超时/无响应,会导致请求挂起,结合文件资源锁的持有,形成阻塞。跨模块资源锁竞争
多模块构建时,若processResources任务跨模块访问或修改同一资源文件(比如共享的配置文件),会触发文件读写锁的竞争,导致任务陷入无限等待。Gradle资源处理流程冲突
自定义processResources逻辑与Gradle默认资源处理流程重叠(比如重复处理同一资源文件),可能触发增量构建的异常检测,导致无限循环或锁死。
解决步骤
1. 排查并移除网络依赖
- 检查
processResources代码块中是否存在远程数据拉取逻辑(例如动态获取Fabric API版本、第三方依赖信息),将这类数据改为本地静态配置:- 在
gradle.properties中预定义变量(如fabric_api_version=0.86.1+1.20.1) - 资源替换时直接引用本地变量,避免构建时发起网络请求
- 在
- 示例修改:
processResources { inputs.property "version", project.version inputs.property "fabricApiVersion", project.properties["fabric_api_version"] filesMatching("fabric.mod.json") { expand(inputs.properties) } }
2. 优化资源锁与文件访问
- 确保每个子项目的
processResources仅处理自身src/main/resources目录下的文件,禁止跨模块访问其他子项目的资源 - 对需要修改的资源文件,使用临时目录完成处理后再复制到目标位置,缩短原文件的锁持有时间:
processResources { def tempDir = file("$buildDir/tmp/resources") copy { from "src/main/resources" into tempDir // 资源替换逻辑 } from tempDir into "$buildDir/resources/main" }
3. 调整Gradle资源处理配置
- 显式指定
processResources的输入输出范围,避免Gradle自动检测时的模糊匹配:processResources { inputs.files fileTree("src/main/resources") outputs.dir "$buildDir/resources/main" // 你的资源处理逻辑 } - 禁用构建缓存或强制刷新缓存,排除缓存异常导致的阻塞:
./gradlew build --no-build-cache
4. 验证资源文件格式合法性
- 检查fabric.mod.json、plugin.yml是否存在语法错误(比如JSON逗号遗漏、YAML缩进错误),这类错误可能导致Gradle解析时陷入无限重试
验证方法
- 先注释掉
processResources中的动态替换逻辑,仅保留基础资源复制,执行./gradlew :adminutils-fabric:processResources,确认是否仍卡顿 - 逐个恢复逻辑代码,定位到具体导致卡顿的代码行
- 执行
./gradlew :adminutils-fabric:processResources --debug --info,查看日志中HttpClient的请求目标,确认是否为网络问题
内容的提问来源于stack exchange,提问作者ElectricSteve
相关产品推荐
相关产品推荐

