Java GC Log Analysis: Decode Fields, Spot Anomalies, Fix Production Performance Issues

Why GC Problems Are the Hidden Killer of Production Performance

First, correct a common misconception: GC itself is not an error; frequent GC and long-duration GC are the failures. Normal GC is the JVM's self-optimization and does not affect business. However, abnormal GC directly causes:

Occasional business interface timeouts: During GC STW pauses, all business threads stop, requests time out directly.

System throughput drops: Large amounts of CPU are consumed by GC, drastically reducing business processing capacity.

Service jitter: Dense GC during peak hours causes interface response times to fluctuate wildly.

Triggers OOM: Extremely low GC efficiency leads to continuous memory accumulation until crash.

Unlike sudden failures, GC problems are progressively worsening — no errors early on, and by the time business visibly suffers, the service is often near paralysis. Reading GC logs is a core performance troubleshooting skill for senior developers.

Core Concepts: Clearly Distinguish Minor GC, Major GC, Full GC

To read logs, you must understand the essential differences among the three GC types — the foundation of GC troubleshooting.

1. Minor GC (Young Generation GC)

Targets only the young generation (Eden + Survivor); the most frequent GC type in daily operation.

Trigger: Eden space fills up, automatically triggered.

Characteristics: Extremely fast, very short duration, short STW pause, almost no business impact.

Normal: High-frequency Minor GC indicates healthy service operation; no worry needed.

Abnormal signal: Millisecond-level frequent triggers, multiple GCs per second, indicating massive short-lived object creation.

2. Major GC (Old Generation GC)

Primarily targets the old generation, usually accompanied by Minor GC.

Trigger: Old generation memory insufficient, objects promoted to old generation too quickly.

Characteristics: Duration far exceeds Minor GC, longer STW pauses, noticeable business impact.

Warning signal: Frequent Major GC is a core indicator of memory leaks or unreasonable object promotion.

3. Full GC (Full Heap GC)

Global collection of the entire heap (young + old + metaspace) — the most severe GC scenario .

Trigger: Severe old generation shortage, metaspace overflow, manual System.gc() calls, abnormal GC thresholds.

Characteristics: Long STW, all business threads paused, widespread interface timeouts, throughput plummets.

Judgment standard: Production must not allow frequent Full GC; every occurrence requires investigation.

Production GC Log Core Fields Fully Explained (Zero-Base Instant Understanding)

Many cannot read GC logs because they don't understand field meanings. Below is a universal field interpretation covering G1, Parallel, CMS mainstream collectors.

Standard GC log example:

2026-09-10T14:23:45.123+0800: 12345.678: [GC (Allocation Failure) [G1 Eden space: 2048M->128M(2048M)] 3072M->1152M(4096M), 0.0234567 secs]

1. Time Fields

2026-09-10T14:23:45.123+0800 : Exact GC occurrence time, used to locate corresponding business faults.

12345.678 : Seconds from service startup to GC trigger; determines whether the issue appears early or after long runtime.

2. GC Trigger Cause (Core Investigation Point)

Allocation Failure : Memory allocation failure — the most normal trigger; memory full, auto-recycle.

System.gc() : Code manually triggers GC — high-risk production issue ; business code must prohibit manual calls.

Metadata GC Threshold : Metaspace memory shortage triggers GC; likely class loading leaks or dynamic class generation issues.

3. Memory Change Data (Core Judgment Basis)

G1 Eden space: 2048M->128M(2048M) : Young generation memory before GC, after GC, and total size.

3072M->1152M(4096M) : Whole heap memory before GC, after GC, and total size.

0.0234567 secs : Total GC duration for this event, in seconds.

Normal GC vs Abnormal GC Precise Judgment Standards (Direct Production Application)

Understanding fields is just the basics; developers must quickly judge whether a GC is normal or a hidden fault. Below are production-ready judgment standards.

1. Normal GC Characteristics (No Action Needed)

Predominantly Minor GC; Full GC extremely rare (a few times per day at most).

Single GC duration very short, typically 10-50 ms.

Memory reclamation effect obvious; heap usage drops significantly.

GC trigger intervals even, no dense clustering.

2. Abnormal GC Characteristics (Must Investigate Urgently)

Frequent Full GC: Multiple triggers in short time; abnormal regardless of duration.

Excessive GC duration: Single GC >100 ms lightly impacts business; >500 ms likely causes interface timeouts.

Ineffective reclamation: Memory barely drops after GC — severe memory leak.

Dense GC triggers: GC every few seconds; CPU saturated by GC threads.

Old generation continuously grows: After each GC, old generation memory only increases, objects not reclaimed normally.

Four Major Production GC Anomaly Scenarios + Root Cause Location + Solutions

Combining high-frequency production incidents, four most common GC anomaly problems are summarized. Match against your own services for rapid location and resolution.

Scenario 1: Frequent Minor GC, Slight Interface Jitter

Phenomenon: Young generation GC multiple times per second; duration not long but continuously consumes CPU; occasional minor interface timeouts.

Root cause: Code contains massive short-lived temporary objects : object creation inside loops, frequent string concatenation, frequent IO stream object creation, high-concurrency interfaces with large temporary parameters.

Solution: Optimize loop logic, reuse objects, use StringBuilder, unify IO resource closing, reduce temporary object creation frequency.

Scenario 2: Old Generation Memory Only Rises, Gradually Triggers Major GC

Phenomenon: Longer service runs, higher old generation occupancy; each GC reclaims very little; gradually triggers Major GC.

Root cause: Typical memory leak : static collections holding objects permanently, ThreadLocal not cleaned, caches without expiration, object references not released.

Solution: Combine jmap and MAT to analyze heap snapshots, locate resident large objects, add expiration policies, manually release references, clean invalid caches.

Scenario 3: Unexplained Frequent Full GC

Phenomenon: No memory explosion, yet frequent Full GC triggers; widespread business timeouts.

Root cause: Code contains manual System.gc() calls, metaspace memory insufficient, unreasonable JVM parameter configuration.

Solution: Globally scan code to block manual GC, increase max metaspace size, optimize JVM generational ratios.

Scenario 4: Extremely Long GC Duration, Single Pause Exceeds 1 Second

Phenomenon: GC count not high, but single duration extremely high; peak hours batch interface timeouts.

Root cause: Heap size set too large, inappropriate garbage collector choice, large objects abundant in old generation, excessive GC fragmentation.

Solution: Optimize heap size, switch to G1 collector, optimize large object generation logic, enable memory fragmentation compaction.

Production GC Log Troubleshooting Standard Process (Direct Work Reuse)

A universal GC problem troubleshooting process — when encountering service stalls, interface jitter, performance degradation, follow these steps:

Check frequency: Count Minor GC and Full GC triggers; judge normal fluctuation vs abnormal density.

Check duration: Verify single GC pause time; determine if long STW blocking exists.

Check reclamation effect: Compare memory delta before/after GC; judge ineffective reclamation or memory leak.

Check trigger cause: Distinguish normal allocation failure, manual GC, or metaspace shortage.

Correlate with business: Verify whether GC peak periods correspond to business peaks or specific interface call spikes.

Implement optimization: Code optimization + JVM parameter tuning dual-dimension solution; long-term monitoring to observe effect.

Summary

GC logs are the JVM's "physical examination report" . Reading GC logs lets you discover potential performance hazards in advance, optimize before failures erupt, transforming from a post-firefighting investigator into a pre-emptive optimizer .

This article thoroughly covers GC classification, log field interpretation, abnormal GC judgment, and high-frequency GC fault solutions — closing the core gap in JVM performance troubleshooting.

Next Episode Preview

Next we enter Server Basic Troubleshooting Commands Practice , hands-on mastery of top, free, df, netstat, tcpdump — core server commands to resolve CPU, memory, disk, and network four major resource bottlenecks, achieving full-chain troubleshooting from application layer to server layer.