--max-workers=n命令行参数可临时限制总工作线程数，覆盖org.gradle.workers.max配置且仅本次生效；后者在gradle.properties中持久化设置，影响所有守护进程构建，二者共同决定实际并发度。
用 --max-workers 临时限制工作进程数
命令行直接控制最灵活，适合调试或 CI 环境按需压测。执行构建时加 --max-workers=N 即可强制限制总工作线程数（含并行任务、编译、测试等所有后台 worker）：
./gradlew build --max-workers=4
这个参数会覆盖 org.gradle.workers.max 的配置，且只对本次执行生效。注意它不等于模块并行数——即使项目有 10 个子模块，--max-workers=2 也会让 Gradle 尽量串行调度，避免资源争抢。
org.gradle.workers.max 在 gradle.properties 中持久化设置
想长期生效，就写进项目根目录的 gradle.properties：
org.gradle.workers.max=6
这个值影响所有使用守护进程的构建，包括 IDE 内触发的构建（如 Android Studio 的 Make Project）。常见搭配：
- 8 核 CPU + 大型 Android 项目：设为
8或12，再高容易触发 GC 频繁或元空间耗尽 - CI 机器内存紧张（比如 4GB 可用堆）：建议 ≤
4，否则JVM OOM比构建慢更致命 - 纯 Kotlin 多模块项目：Kotlin 编译器本身开销大，
max值比 Java 项目建议低 1～2
和 org.gradle.parallel 的关系别搞混
org.gradle.parallel=true 控制的是「是否允许不同模块同时执行」，而 org.gradle.workers.max 控制的是「整个 Gradle 进程最多能开多少个线程干活」。两者叠加时，实际并发度取较小值。
比如：parallel=true 且 workers.max=2，哪怕你有 5 个独立模块，也最多只有 2 个在编译；但若 workers.max=8 而模块只有 2 个，那也不会硬拉满 8 个线程。
容易踩的坑：
- 只开
parallel=true却不调workers.max：在高核机器上可能瞬间拉起 16+ 线程，JVM 堆和元空间扛不住 - 把
workers.max设得比物理核心数还小（比如设成 1），并行模块形同虚设，build 时间反而更长
验证当前生效的 worker 数
加 --info 参数看日志里有没有这行：
Using <code>6 worker threads.
或者构建完后查 build/reports/profile/ 下的 HTML 报告，在 “Thread usage” 表格里能直观看到峰值线程数。别光看配置写了没——守护进程可能缓存旧配置，改完 gradle.properties 后最好加 --no-daemon 跑一次确认。
