skip to content

How do `gradle --status` and `gradle --stop` help you manage daemon reuse for build speed?

level: middleimportance: should knowfreq 45%

answer

  1. --status: PID/STATUS/INFO of daemons
  2. spot sprawl = many IDLE mismatched
  3. --stop: graceful shutdown, clean slate
  4. next build = one fresh warm daemon
  5. --stop scoped to current version's set

basics

~20 s

gradle --status lists running daemons with their PID, status, and Gradle/JVM info — useful to spot sprawl or idle/incompatible daemons. gradle --stop shuts them all down so the next build starts a clean, single warm daemon.

solid answer

~50 s

For the reuse/perf angle, these two commands are your diagnostic and reset tools. `gradle --status` prints the daemons Gradle knows about — PID, status (IDLE/BUSY), Gradle version, and JVM info — so you can see whether reuse is actually happening or whether you have **daemon sprawl** (many idle daemons with mismatched JVM args that never get reused). When you spot that — or when a daemon is behaving oddly and not being reused — `gradle --stop` gracefully terminates all compatible daemons. Your very next build then starts one fresh daemon, which becomes the single warm process everything reuses. The workflow is: notice slow/inconsistent starts → `--status` to confirm sprawl → `--stop` to clear → re-run with deterministic JVM args so a single daemon stays warm. Note `--stop` only stops daemons of the **current** Gradle version's compatible set; daemons from other versions may persist.

code

bash · 6 lines
bash
# See what daemons exist and whether reuse is sticking
./gradlew --status

# Clear sprawl / wedged daemons, then start clean
./gradlew --stop
./gradlew build   # starts ONE fresh daemon that stays warm for reuse

go deeper

for a junior

Know --status lists daemons and --stop shuts them down.

for a middle

Use --status to recognize sprawl and --stop to reset before re-running with consistent config.

for a senior

Drive a diagnose→reset→fix-root-cause loop and understand --stop's version scoping caveat.

for a principal

Bake these into onboarding/troubleshooting runbooks; treat persistent sprawl as a config-standardization gap to fix org-wide.

## The two perf-management commands Daemon reuse is invisible until something goes wrong (every build feels cold, or memory balloons). `--status` and `--stop` make it observable and resettable. ## `gradle --status` Prints a table of the daemons Gradle is tracking, typically including: - **PID** — the OS process id. - **STATUS** — `IDLE` (available for reuse) or `BUSY` (running a build). - **INFO** — the Gradle version and JVM the daemon runs. ```bash $ gradle --status PID STATUS INFO 41234 IDLE 8.7 41888 IDLE 8.7 42001 BUSY 8.7 ``` Reading it for **reuse**: ideally you want **one** IDLE daemon that every build lands on. Seeing several IDLE daemons — especially with differing JVM configs — is a sign reuse isn't sticking (often because of inconsistent `org.gradle.jvmargs` or JDKs). That sprawl wastes RAM and means new builds keep paying cold costs on fresh daemons. ## `gradle --stop` Gracefully stops the running daemons in the current Gradle version's compatible set: ```bash $ gradle --stop Stopping Daemon(s) 2 Daemons stopped ``` Use it to clear sprawl, recover from a wedged daemon, or force a clean slate before re-running with corrected JVM args. The next invocation starts exactly one fresh daemon, which then stays warm for subsequent reuse. **Caveat:** `--stop` targets daemons compatible with the Gradle version you invoke it with. Daemons started by a different Gradle version may not be stopped by it; you'd run `--stop` with that version (or just let them idle-timeout). ## Putting it together (the reuse loop) 1. Builds feel slow / memory high → suspect reuse isn't working. 2. `gradle --status` → confirm: many IDLE daemons, mismatched JVM info. 3. `gradle --stop` → wipe the slate. 4. Fix root cause: pin `org.gradle.jvmargs` and JDK so every invocation is identical. 5. Re-run → a single warm daemon now serves everything; `--status` shows one IDLE. These commands don't make builds faster by themselves — they let you **verify and restore** the conditions under which warm-daemon reuse delivers speed.

  • After `--stop`, is the next build slower?
    Yes, that one build pays cold costs because it starts a fresh daemon. But every build after it reuses that now-warm daemon, restoring speed.
  • Does `--stop` guarantee every Gradle daemon on the machine is gone?
    No. It stops daemons compatible with the Gradle version you invoked it with; daemons from other versions can persist until you stop them with that version or they idle-timeout.

saying these in an interview costs you the question

  • Claiming `--stop` makes builds faster directly — it resets state; reuse is what delivers speed.
  • Assuming `--stop` kills daemons of all Gradle versions on the machine.

context

resolving links…