Return to site

🗑️📈 GC LOGGING IN JAVA: READ YOUR MEMORY STORY (WITHOUT GUESSING)

· java

🔸 TLDR

▪️ GC logging is your JVM’s “black box recorder” for memory and pause events.

▪️ Use GC logs for deep debugging, and JMX for ongoing monitoring—they complement each other. 🤝

Section image

🔸 WHAT IS GC LOGGING?

▪️ GC logging = the JVM writing garbage collection events to logs (console or file).

▪️ It tells you when GC happened, what kind, how long it took, and often before/after heap sizes.

▪️ Goal: understand latency spikes, throughput impact, and memory pressure patterns. 🧠

🔸 JAVA COMMAND SWITCHES (CLASSIC FLAGS)

▪️ -Xloggc:👉 Writes GC logs to a dedicated file (instead of mixing with app logs).

▪️ -XX:+PrintGCDetails👉 Adds details: heap regions, generations, pause phases, memory before/after.

▪️ -XX:+PrintTenuringDistribution👉 Shows how objects “age” and when they get promoted to old gen (useful to tune survivor spaces / tenuring).

▪️ -XX:+PrintGCTimeStamps👉 Adds timestamps as “seconds since JVM start” (great to correlate with app warmup/load tests).

▪️ -XX:+PrintGCDateStamps👉 Adds real wall-clock timestamps (great to correlate with incident timelines & distributed logs).

✅ Example (legacy style):

java \

-Xloggc:gc.log \

-XX:+PrintGCDetails \

-XX:+PrintTenuringDistribution \

-XX:+PrintGCTimeStamps \

-XX:+PrintGCDateStamps \

-jar app.jar

🔸 GC LOGGING VS JMX (THE REAL DIFFERENCE)

▪️ GC logs: event-by-event truth → pauses, phases, promotion, allocation pressure, “what happened exactly?” 🔍

▪️ JMX metrics: aggregated counters & gauges → “how much / how often?” 📊

▪️ GC logs are best for root-cause (why the 800ms spike?), JMX is best for continuous monitoring (trend alerts, dashboards).

🔸 BENEFITS ✅

▪️ Post-mortem friendly: you can analyze incidents after the fact.

▪️ High signal for latency: reveals pause times and their causes.

▪️ Tuning insight: tenuring, promotion failures, allocation rates.

▪️ Works everywhere: no extra agent required (just flags). 🚀

🔸 DRAWBACKS ⚠️

▪️ Overhead: logging is usually small, but can matter at very high throughput.

▪️ Log volume: can become huge without rotation. 🧻

▪️ Interpretation cost: raw GC logs aren’t always intuitive (tools help).

▪️ Not a full observability replacement: doesn’t show business impact, only JVM behavior.

🔸 TAKEAWAYS

▪️ Enable GC logging early in environments where latency matters.

▪️ Prefer date stamps for incident correlation, time stamps for performance testing.

▪️ Combine GC logs + JMX + app latency metrics for the full picture. 📈

▪️ Rotate GC logs like any production log to avoid disk surprises.

#Java #JVM #GarbageCollection #Performance #Observability #SRE #DevOps #SpringBoot #Monitoring #JMX

Go further with Java certification:

Java👇

Spring👇

SpringBook👇

JavaBook👇