GC Pressure

JVM garbage collection runs frequently and reclaims little heap, or produces stop-the-world pauses, causing latency spikes in Java and Scala services (Kafka brokers, Elasticsearch, Cassandra, HBase).

GC pressure and GC pauses are distinct but related failure modes. GC pressure occurs when the GC runs continuously but the heap is not reclaimed fast enough to keep up with object allocation: the JVM spends an increasing fraction of CPU time on collection rather than application work. GC pause occurs when the JVM must stop all application threads (stop-the-world) to perform a collection phase: threads freeze for the pause duration, and in-flight requests accumulate.

G1GC (the default collector since JDK 9): performs concurrent marking but requires stop-the-world phases for certain operations. Under heap pressure (heap utilization > 80%), G1 may initiate Full GC, which is entirely stop-the-world and can pause JVM threads for 100–500ms on large heaps. This is long enough to trigger upstream timeouts and health check failures.

ZGC and Shenandoah (JDK 11+): designed for sub-millisecond pauses even on multi-gigabyte heaps. They achieve this by doing most work concurrently with application threads. On Kafka brokers running JDK 17+, ZGC is the recommended collector.

Elasticsearch is particularly GC-sensitive: long GC pauses cause nodes to appear unavailable to the cluster coordinator, triggering shard relocation storms that compound the original problem. Cassandra: GC pauses exceeding the Phi Accrual failure detector threshold cause the node to be marked as DOWN by peers, triggering unnecessary re-reads and hints.

Common triggers at the application level: - Returning very large result sets that require all objects to be live

simultaneously (the entire list in memory during serialization)

- Unbounded cache growth inside the JVM heap (in-process caches without

eviction policy)

- String interning abuse or large byte array allocations without pooling