What is Stop-the-World in GC?
Fast recall
Quick revision
Core answer
Understanding of the real-world performance impact of garbage collection on production systems
Treating all GC work as concurrent, or saying a pause stops every JVM thread or every process rather than the Java application threads in one JVM
Collectors split work differently between paused and concurrent phases; no collector name alone guarantees a particular pause time
Interview-ready guide
Interview answer
A stop-the-world pause is an interval when the JVM suspends its Java application threads while collector or JVM work continues. Any in-process Java request that overlaps the pause is stalled for the overlapping interval, so pauses can appear in tail latency. Collectors use safe points, barriers, and different paused and concurrent phases to keep the object graph correct while references change. G1, ZGC, and Shenandoah move different amounts of work out of the pause, but none guarantees one fixed pause time for every heap and workload. I would correlate unified GC or safepoint logs with request traces, then compare pause percentiles, allocation rate, live-set size, CPU, and the service's latency objective before tuning.
What is Stop-the-World in GC
Direct Answer
A stop-the-world pause is an interval when Java application, or mutator, threads in one JVM are suspended while collector or other JVM work continues. In-process requests that overlap the pause cannot execute Java code during that interval, so the pause can affect latency.
Code Example
@RestController
public class OrderController {
private final OrderService orderService;
@GetMapping("/orders/{id}")
public ResponseEntity<Order> getOrder(@PathVariable Long id) {
long start = System.nanoTime();
var order = orderService.findById(id);
long elapsedNanos = System.nanoTime() - start;
// elapsedNanos includes any STW interval that overlapped this work.
return ResponseEntity.ok(order);
}
}
Use a monotonic clock for elapsed time and correlate request telemetry with unified GC logs, for example -Xlog:gc*:file=gc.log:time,uptime. One slow request does not prove that GC caused it.
Common Mistakes & Pitfalls
- Calling all GC work background work: Collectors can perform concurrent work, but they also use stop-the-world phases.
- Blaming every latency spike on GC: Correlate request traces, CPU, safepoint/GC logs, and allocation data before deciding on a cause.
- Promising a collector-specific pause number: Heap, live set, allocation, CPU, JVM version, flags, and workload all matter; benchmark the actual service.
Check your understanding
Answer these without looking back at the article.
- How does G1 GC reduce stop-the-world pauses?
- What is the difference between minor GC and major GC?
Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.