可用CPU核心数需通过nproc（Linux/macOS）或wmic cpu get NumberOfCores（Windows）获取物理核心数，Gradle并行构建推荐设为物理核心数的1～1.5倍，避免因上下文切换、GC压力和IO瓶颈导致性能下降。
怎么查自己机器的可用 CPU 核心数
并发数不是拍脑袋定的，得先知道硬件底子。Gradle 并行构建用的是 org.gradle.workers.max，它控制的是工作线程上限，而这个值设太高反而会因上下文切换和内存争抢拖慢整体速度。
Linux/macOS 下直接运行：nproc 或 sysctl -n hw.ncpu（macOS）
Windows 命令行可执行：wmic cpu get NumberOfCores
注意：别直接用逻辑线程数（比如 16 线程的 CPU），优先从物理核心数起步——实测中，设为物理核心数的 1～1.5 倍最稳。8 核 CPU 推荐从 org.gradle.workers.max=8 开始试，再观察构建日志里的线程占用情况。
为什么不能无脑设成 CPU 线程总数
Gradle 的 worker 线程要跑编译、资源处理、ProGuard、Kotlin 编译器等任务，很多环节本身是内存/IO 密集型，不是纯 CPU 计算。线程开太多会导致：
- JVM GC 压力陡增，尤其
-Xmx没配够时频繁 Full GC - 磁盘 IO 成瓶颈（特别是 SSD 性能一般或项目含大量 assets）
- Android 项目里 AAPT2、D8/R8 多实例抢占内存，反而触发 OOM 或降频
建议搭配 --scan 或 --profile 构建一次，打开 build/reports/profile/index.html，重点看 “Task Execution” 阶段的并行热力图——如果大量任务显示“waiting for worker”，说明线程不够；如果“worker busy time” 很低但“GC time” 占比高，大概率是线程过载了。
CI 环境下怎么调更稳妥
CI 机器（如 GitHub Actions、GitLab Runner）常被限制 vCPU 数量，且不保证独占。硬写死 org.gradle.workers.max=16 可能让构建在 4 核 runner 上卡死。
推荐做法：
- 在 CI 脚本里动态传参：
./gradlew build --parallel -Dorg.gradle.workers.max=4 - 或者在
gradle.properties中留空，靠 CI 环境变量注入：org.gradle.workers.max=${GRADLE_WORKERS_MAX:-4}（需 Gradle 7.4+ 支持环境变量展开） - 对 Android 项目，额外加
android.enableJetifier=false和android.useAndroidX=true（如果已迁移），避免 Jetifier 在并行时反复解析 jar 包引发锁竞争
模块依赖混乱时，并行数再合适也白搭
并行生效的前提是模块间依赖图清晰。如果你的 moduleA 没在 dependencies 里声明却通过反射加载 moduleB 的类，Gradle 无法识别隐式依赖，可能让两个模块被错误并行执行，导致 ClassNotFoundException 或构建结果不一致。
检查方式：
- 执行
./gradlew :app:dependencies，确认所有 runtime 依赖都显式声明 - 禁用并行（
--no-parallel）构建一次，若成功，再开并行失败，大概率是隐式耦合问题 - Android 项目中，特别注意
implementation project(':lib')是否漏写，或误用compileOnly导致编译期看不到符号
真正卡点往往不在参数数字本身，而在模块边界是否干净——线程数只是放大镜，照出的是架构真实状态。
