容器中仅配置org.gradle.jvmargs不够，因Docker内存限制（如-m 2g）会覆盖JVM堆设置，导致OOM崩溃；需协同设置-m、--cpus等容器资源参数，并使-Xmx≤容器内存75%，同时慎用parallel、关闭daemon。
容器里跑 Gradle 构建，为什么光配 org.gradle.jvmargs 不够？
因为 JVM 内存只是内层限制，而 Docker 容器本身有外层资源边界。如果你只在 gradle.properties 里设了 -Xmx4g，但容器被 -m 2g 限制住物理内存，JVM 就会 OOM 崩溃——它根本申请不到 4G。同理，CPU 权重没调，Gradle 并行任务再多也抢不到核。两层限制必须协同，否则要么卡死，要么报 java.lang.OutOfMemoryError: Java heap space 或 Killed（Linux OOM Killer 干的）。
怎么用 docker run 同时约束 CPU 和内存？
直接传参最可控，避免镜像内置默认值干扰：
-
-m 4g：硬性限制容器最多用 4GB 物理内存；不加--memory-swap时，默认允许再用等量 swap（即最多 8GB 虚拟内存），但生产环境建议显式禁用 swap：--memory-swap=4g -
--cpus=2.5：更直观的 CPU 限额（Docker 1.13+），表示最多占用 2.5 个逻辑核；旧版可用-c 2560（以 1024 为基准权重，2560 ≈ 2.5×1024） -
--ulimit memlock=-1:-1：防止 Gradle 的 native 编译器（如 Kotlin/Native、NDK）因内存锁限制失败
完整命令示例：docker run -m 4g --memory-swap=4g --cpus=3 -v $(pwd):/workspace -w /workspace gradle:8.10-jdk17 gradle build
gradle.properties 里的 JVM 参数怎么跟容器内存对齐？
原则是：JVM 堆上限 ≤ 容器内存的 75%，留空间给元空间、线程栈、native 内存。比如容器设了 -m 4g，gradle.properties 就该写：
org.gradle.jvmargs=-Xms2g -Xmx3g -XX:MetaspaceSize=512m -XX:MaxMetaspaceSize=1g
注意三点：
- 别写
-Xmx4g—— 容器内存不够，JVM 启动直接失败 - 要设
-Xms（初始堆）接近-Xmx，避免运行中频繁扩容触发 GC -
MetaspaceSize必须显式设，否则 JDK8+ 默认 20MB，大型项目一加载插件就爆java.lang.OutOfMemoryError: Metaspace
并行构建和配置缓存在容器里要不要开？
要开，但得看容器资源是否撑得住：
-
org.gradle.parallel=true：开启后每个模块独立 JVM 进程，内存消耗翻倍。如果容器只有 2 核 2G 内存，强行开反而更慢 -
org.gradle.configuration-cache=true：安全且推荐，它把build.gradle解析结果缓存到磁盘，不占运行时内存，还能跨构建复用 - 真正吃资源的是
org.gradle.daemon=true（默认已开），但容器里其实没必要——每次docker run都是新环境，守护进程活不过单次构建
所以容器场景下，优先保 configuration-cache，慎用 parallel，关掉 daemon 更干净（加 --no-daemon 参数）。
最容易被忽略的一点：Gradle 的 --profile 报告在容器里默认生成在 build/reports/profile，但如果不挂载卷或进容器取，报告就随容器销毁了。跑构建时记得加 -v $(pwd)/profiles:/workspace/build/reports/profile，不然你永远不知道瓶颈到底在哪儿。
