Why Does Your Java App Freeze? Uncover Full GC Causes and Fixes

Java’s widespread adoption is tightly linked to its automatic memory management, but the JVM’s garbage‑collection mechanisms can also become a major source of performance problems.

1. Memory Reclamation Is a Persistent Pain Point in Java

Java’s automatic memory reclamation frees developers from manual object cleanup, yet it introduces overhead. Algorithms like mark‑copy and mark‑sweep can trigger stop‑the‑world pauses, making it difficult to build cache‑intensive products (e.g., Redis) directly in Java.

2. Why Full GC Keeps Happening

2.1 When Does GC Occur?

When a new object is allocated, the JVM first tries to reserve heap space. If insufficient, a young‑generation GC (YGC) runs; if YGC cannot free enough space, a full GC (FGC) is triggered. If FGC still fails, the process repeats until enough memory is obtained.

2.2 Common Causes of Repeated Full GC

Memory leaks

Too many concurrent requests causing thread explosion

Metaspace exhaustion

Constant‑pool entries filling the heap

Off‑heap memory exhaustion

When request latency spikes (e.g., from 1 ms to 100 ms), the number of concurrent requests can increase dramatically, leading to many threads allocating objects, which mimics a memory‑leak effect and exhausts system memory. Repeated FGC further degrades performance, creating a snowball effect.

3. How to Keep the System Alive After a Full GC

3.1 Eliminate Memory Leaks

Typical leaks arise from misuse of collections (e.g., storing configuration data in a List instead of a Set). Adopting disciplined coding habits and careful review can prevent many hidden issues.

3.2 Concurrency Limiting: Prevent the System from Being Overwhelmed

Each server has a maximum parallel request capacity. Exceeding this limit causes crashes regardless of request speed. Implementing per‑server concurrency limits—using tools such as Alibaba’s Sentinel or Netflix’s Hystrix—helps maintain stability.

3.3 Adaptive Rate Limiting: Avoid Being “Mopped” by Traffic Surges

Two reasons motivate adaptive limits: (a) server environments differ (different hardware, VM co‑location, etc.), so a uniform limit is sub‑optimal; (b) even correctly set limits can be overwhelmed by traffic spikes 6–20× higher, leading to “mop‑down” failures. Dynamically lowering the limit during such spikes keeps the service alive.

3.4 Abnormal Traffic Monitoring: Guard Against Long‑Tail Requests

Monitoring usually focuses on the 99th percentile, but long‑tail requests (e.g., huge payloads) can still trigger FGC and degrade performance. Identifying and throttling these outliers is essential for robust systems.

In summary, understanding the root causes of full GC, eliminating memory leaks, applying proper concurrency controls, using adaptive rate limiting, and monitoring abnormal traffic are key to building stable Java backend services.

References

JVM tuning summary: https://hllvm-group.iteye.com/group/wiki/?category_id=301

Noah adaptive rate limiting: https://www.atatech.org/articles/149208