./gradlew --stop 是 gradle 官方推荐的唯一标准方式，可精准终止当前版本所有守护进程，避免手动杀进程导致锁文件残留或版本混淆。
直接用 ./gradlew --stop 就能终止当前版本的所有 Daemon 进程
这是 Gradle 官方推荐的唯一标准方式，不需要手动查 PID 或杀进程。它会自动定位并终止所有由**相同 Gradle 版本**启动的守护进程（比如你用的是 gradle-6.7.1，--stop 就只关掉这一版的 Daemon）。
常见错误是误以为 Ctrl+C 或关闭终端就能结束 Daemon —— 实际上它在后台继续运行，直到 3 小时空闲超时才自动退出。如果构建卡住、内存暴涨或出现 Gradle build daemon disappeared unexpectedly，大概率是旧 Daemon 残留导致的。
- 执行前确保你在项目根目录下（有
gradlew文件） - 命令不依赖 JDK 环境变量，但需要
gradlew可执行权限（Linux/macOS 下可能需先chmod +x gradlew） - Windows 用户用
gradlew.bat --stop效果相同
为什么不用 jps + kill 手动杀？
虽然 jps | grep GradleDaemon 能看到进程，但手动 kill -9 容易出问题：
- 多个 Gradle 版本共存时，
jps列出的GradleDaemon进程无法区分对应哪个版本，--stop才能精准匹配 -
kill -9强制终止会跳过 Daemon 的清理逻辑，可能导致.gradle/daemon/下的锁文件残留，下次启动时报Address already in use - CI 环境（如 Jenkins）中，
jps可能因权限或容器隔离根本看不到进程，而--stop始终有效
CI/CD 场景下更该禁用 Daemon 而非频繁停止
Jenkins、GitLab CI 等环境通常使用临时容器或干净工作区，每次构建都是全新上下文。此时 Daemon 不仅没加速效果，反而因缓存无效、JVM 内存占用高引发崩溃（典型报错：Could not reserve enough space for 1572864KB object heap）。
- 在构建命令里加
--no-daemon：例如./gradlew assembleDebug --no-daemon - 也可在
gradle.properties中设org.gradle.daemon=false，但 CI 脚本里显式传参优先级更高 - 注意：禁用后每次构建都会新建 JVM，耗时略增，但稳定性大幅提升
停止后仍不生效？重点检查 .gradle/daemon/ 缓存目录
--stop 成功后，如果下次构建仍复用旧状态（比如编译速度异常快或报缓存冲突），说明 Daemon 相关元数据没清干净。
- Linux/macOS：删掉
~/.gradle/daemon/目录（不是整个.gradle） - Windows：
C:\Users\<username>\.gradle\daemon\</username> - 删除后无需重启机器，再跑一次
./gradlew --stop+ 正常构建即可重建干净 Daemon
这个目录存放的是各 Gradle 版本的守护进程通信 socket 和状态文件，残留会导致新 Daemon 启动失败或行为异常——这点最容易被忽略。
