The scenario is OrderService: a Java 21 service that builds an order response (about 200 line items, serialised to JSON, roughly a hundred kilobytes of short-lived garbage per request) and keeps a large catalog cache of five million product objects (about 1.1 GB live) in memory. GcLab reproduces that shape in plain Java: four request threads, requests arriving on a fixed schedule (an open model, so a pause is charged to every request that should have started during it), JDK 21.0.2 on a 12-core laptop-class machine.

Two diagrams explain almost every GC symptom: where memory lives in the process, and how an object travels from allocation to old generation.

Before changing a single flag, read what the collector is already telling you. A GC log line answers four questions: why the pause happened, how long it stopped the application, how much heap it freed, and how often it recurs.

Same code, same heap (3 GB), same load; one variable changes: the collector. Each configuration ran three times with the GC log on. Two load levels tell different stories: a saturating closed loop (how much work can the JVM do?) and an unsaturated open loop at 1,600 req/s (how long are the stops when the machine is not overloaded?).

What the data says. At the unsaturated rate the collectors that reclaim memory concurrently show the shortest stops, and generational ZGC is the only concurrent collector that also keeps G1-class throughput. The older non-generational ZGC and Shenandoah were consistently the slowest in the closed loop (see the throughput chart: every one of the three repetitions was lower than every G1 repetition), because with a 1.1 GB live set each cycle must re-mark everything while the application keeps allocating; at 4,800 req/s - above their capacity - the open-loop queue exploded (median p99 of 4850 ms for ZGC and 7727 ms for Shenandoah, from the first matrix). That is overload, not a pause: when a concurrent collector cannot keep up it stalls allocating threads ("Allocation Stall").

The second variable that decides GC cost is how much room the collector has. A garbage collector does work proportional to the live set; the more free heap it has, the less often it must run. The classic mistake in both directions: a heap barely larger than the live set (constant collections), and a giant heap "to be safe" (longer pauses, more memory, higher bill).

Chapters 4-5 tuned the collector and the heap. The cheapest GC tuning is not creating the garbage. OrderService's response builder is deliberately wasteful, like many real ones: it copies every line item into a temporary list, concatenates strings for titles, and calls String.format (which builds a Formatter, a regex-free parser and several temporary strings) once per line item.

The container limit applies to the whole process. A service with -Xmx512m can legitimately use 900 MB: Netty/NIO direct buffers, 500 thread stacks, metaspace, the JIT code cache, GC remembered sets and native libraries are all outside the heap. NativeLab allocates 200 MB of heap objects, 300 direct buffers of 1 MB and 500 threads, then asks the JVM where the memory went with Native Memory Tracking.

A leak is memory that is still reachable but will never be used again. The collector cannot help; it correctly keeps what is referenced. LeakLab implements three leaks that appear in real Spring services and runs each with -Xmx256m until it dies.

Putting the pieces together for an OrderService task on ECS/Fargate or an EKS pod. The method is arithmetic you can check with NMT, not guesswork.

Everything above is plain Java; compile with javac and run with JDK 21. Absolute numbers will differ on your machine - what should reproduce is the shape: pause timelines, the ranking by stopped time, the effect of headroom, the staircase of a leak.

• Q: How do you decide between G1, ZGC and Parallel?
  By the metric you pay for. Throughput-first batch work: Parallel. General services on 2+ CPUs: G1 (default). Strict p99 on big heaps with spare CPU: generational ZGC (JDK 21: -XX:+ZGenerational; default in JDK 23). Measure stopped time from -Xlog:safepoint on your live set: here max stops were ~19 ms (G1, median) vs under 1 ms (ZGC) vs ~100 ms (Parallel/Serial).
• Q: What is the generational hypothesis and why does it matter for tuning?
  Most objects die young, so a young collection copies only the small live fraction and its cost depends on live objects, not garbage. It means short-lived garbage is cheap while long-lived churn (a cache that keeps replacing entries) is expensive - and that allocation rate sets collection frequency.
• Q: p99 spikes every few seconds but CPU is fine. First step?
  Turn on GC logging and line the pause timestamps up with the latency spikes. If they match, change one variable at a time: reduce allocation, add heap headroom, then consider another collector.
• Q: Why can a pod be OOMKilled with a half-empty heap?
  The cgroup limit covers heap + metaspace + code cache + thread stacks + direct buffers + GC structures + native libraries. NMT showed 300 MB of direct buffers, 75 MB of GC structures and 53 MB of thread stacks outside a 1 GB heap in our lab.
• Q: What do -Xms, -Xmx and MaxRAMPercentage do and what are good values?
  -Xms/-Xmx set initial/max heap; MaxRAMPercentage (default 25) sets max as a fraction of the container/host RAM. For servers pin initial = max and leave 30-45% of the container for non-heap.
• Q: How do you find a memory leak without a profiler?
  Watch the post-GC floor in the GC log, take two jcmd PID GC.class_histogram snapshots minutes apart and diff, then a heap dump analysed in MAT (dominator tree) to find the owning reference.
• Q: What does a Full GC in the log mean?
  The collector failed to reclaim fast enough (heap too small, promotion failure, humongous allocation, leak) and fell back to a single full compaction. Fix the cause: headroom, allocation rate or leak - not the pause.
• Q: Does G1's MaxGCPauseMillis guarantee a pause limit?
  No, it is a soft goal G1 tries to meet by sizing the young generation and choosing regions; a large live set or high allocation rate will exceed it. Our G1 median max stop was ~19 ms against the default 200 ms goal, with outliers.
• Q: Why are ThreadLocals dangerous in pooled threads?
  Pool threads live as long as the JVM, so values left in a ThreadLocal live too (8 MB x 28 threads exhausted a 256 MB heap in our run). Always remove() in finally; with virtual threads avoid heavy per-thread state.