JVM garbage collection: the collectors, the defaults and the few flags worth setting

What it is

The HotSpot tuning guide lists four collectors. Serial uses a single thread and suits small data sets (the guide says up to approximately 100 MB) or single-processor machines. Parallel, also called the throughput collector, is generational with several GC threads and stop-the-world pauses. G1 is mostly concurrent, aims at a pause-time goal with high probability while keeping throughput, and is selected by default on most hardware. ZGC keeps pauses under a millisecond independent of heap size at some throughput cost; in JDK 21 its generational mode is enabled with -XX:+UseZGC -XX:+ZGenerational. The ergonomics chapter states the defaults: G1 on server-class machines, meaning two or more processors and physical memory of at least 1792 MB, Serial otherwise; an initial heap of 1/64 and a maximum heap of 1/4 of physical memory; tiered compilation with C1 and C2.

Why it matters

Coming from Go or .NET, the surprise is how much JVM memory behaviour is decided at start-up from the visible CPU count and memory. A container limited to one CPU gets the Serial collector; a container with 512 MB gets a maximum heap of about 128 MB. Pause time versus throughput is a real trade: the guide describes a maximum pause-time goal (-XX:MaxGCPauseMillis) and a throughput goal (-XX:GCTimeRatio), says the collector adjusts heap and generation sizes to meet the preferred goal, and warns that this may make collections more frequent or fail to reach the goal at all.

How to apply

• Set the maximum heap explicitly (-Xmx or -XX:MaxRAMPercentage; see the container sizing article) so the process footprint is a decision, not an accident.
• Let the VM choose the collector first, as the guide recommends. Move to Parallel when a batch job's throughput matters and longer stop-the-world pauses are acceptable, keep G1 when response time matters, choose ZGC when pauses must stay in the sub-millisecond range.
• Turn on GC logging from day one: -Xlog:gc*:file=/var/log/app/gc.log:time,uptime:filecount=5,filesize=20m. Every later tuning decision in this list depends on that log.
• Set a pause goal only after reading logs, and measure the throughput cost.
• Restart-test any flag change under load before it reaches production; ergonomics differ between a laptop and a container.

Pitfalls

Copying flag sets from material written for JDK 8: JEP 363 removed the CMS collector in JDK 14 and states that -XX:+UseConcMarkSweepGC is then ignored with a warning while the JVM continues on the default collector. Setting a heap larger than the container allows. Hand-tuning young and old generation sizes before the logs show a problem. Reading a full GC as a memory leak without a heap histogram or dump.