Why GC affects latency
A managed runtime reclaims unused memory automatically. When the collector runs, it may pause application threads, and those pauses land squarely in the latency tail.
The core tradeoffs
GC tuning balances three forces.
- Throughput is how much CPU goes to your code versus collection.
- Latency is how long pauses are.
- Footprint is how much heap you keep.
You cannot maximize all three. A bigger heap collects less often but uses more memory, while a low pause collector spends more CPU to keep pauses short.
Levers that help
- Reduce allocation so the collector runs less, often the biggest win.
- Size the heap so collections are not constant nor rare and huge.
- Choose a low pause collector when tail latency matters more than raw throughput.
- Tune generation sizes so short lived objects die cheaply in the young space.
Measure first
Watch pause counts, pause durations, and allocation rate before changing knobs. Often cutting allocation beats any flag.
Key idea
GC tuning trades throughput, latency, and footprint, and the most durable win is allocating less so the collector runs and pauses less.