Understanding how Java manages memory is crucial for building applications that scale. While the JVM handles memory automatically, knowing what happens under the hood can mean the difference between an app that runs smoothly and one that stutters under load.
Understanding the Basics
Java’s garbage collection (GC) is essentially an automatic janitor for your application’s memory. When you create objects, the JVM allocates memory for them. When those objects are no longer needed, the garbage collector reclaims that memory. Simple in theory, but the devil is in the details.
The Memory Layout
Java divides heap memory into distinct regions, each serving a specific purpose:
| Region | Purpose | Typical Size |
|---|---|---|
| Young Generation | Short-lived objects | ~1/3 of heap |
| Old Generation | Long-lived objects | ~2/3 of heap |
| Metaspace | Class metadata | Grows as needed |
Most objects die young. Studies show that around 90% of objects become garbage shortly after creation. This observation drives the generational design of Java’s memory model.
The Garbage Collection Lifecycle
Let’s walk through what actually happens when GC kicks in.
Minor GC: The First Line of Defense
When the Young Generation fills up, a Minor GC occurs. Here’s the process:
- Identify live objects – The GC marks all objects still in use
- Copy survivors – Live objects move to a survivor space
- Clear everything else – The rest gets wiped clean
- Promote old-timers – Objects that survive multiple rounds move to Old Generation
This typically pauses your app for just milliseconds. You won’t even notice it.
Major GC: The Heavy Hitter
When the Old Generation fills up, things get more serious. A Major GC (also called Full GC) scans the entire heap. This can pause your application for seconds, which is noticeable and problematic for user-facing apps.
Timeline of a GC Event:
[App Running] → [GC Triggered] → [App Paused] → [Memory Reclaimed] → [App Resumed]
↑
This is "Stop-the-World"
Choosing Your Garbage Collector
Java offers several GC algorithms, each with trade-offs:
| Collector | Best For | Characteristics | JVM Flag |
|---|---|---|---|
| Serial GC | Small apps, single-threaded | Single-threaded, stops the world | -XX:+UseSerialGC |
| Parallel GC (Throughput Collector) | Batch processing, background tasks | Multi-threaded, maximizes throughput but can cause longer pauses | -XX:+UseParallelGC |
| G1 GC (Garbage First) | Large heaps (>4GB), balanced performance | Divides heap into regions, collects most garbage first, aims for predictable pauses | -XX:+UseG1GC -XX:MaxGCPauseMillis=200 |
| ZGC / Shenandoah | Ultra-low latency apps | Most work done concurrently, pause times under 10ms even with large heaps | -XX:+UseZGC (Java 1 |
Serial GC
Best for: Small applications, single-threaded environments
The simplest collector. It uses a single thread and stops the world while it works. Not suitable for anything beyond development or very small apps.
-XX:+UseSerialGC
Parallel GC (Throughput Collector)
Best for: Batch processing, background tasks
Uses multiple threads to speed up collection. Maximizes throughput but can cause longer pause times. This is the default in many JVM versions.
-XX:+UseParallelGC
G1 GC (Garbage First)
Best for: Large heaps (>4GB), balanced performance
Divides the heap into regions and collects the ones with the most garbage first. Aims to meet predictable pause time goals while maintaining good throughput.
-XX:+UseG1GC -XX:MaxGCPauseMillis=200
Example scenario: An e-commerce site with 8GB heap sees average pause times drop from 500ms to under 200ms after switching from Parallel to G1.
ZGC and Shenandoah
Best for: Applications requiring ultra-low latency
These modern collectors keep pause times under 10ms, even with multi-hundred gigabyte heaps. They do most work concurrently with your application.
-XX:+UseZGC # Available Java 15+
Monitoring and Tuning
You can’t optimize what you don’t measure. Here’s how to see what’s happening:
Essential JVM Flags for Visibility
# Log GC activity -Xlog:gc*:file=gc.log:time,uptime:filecount=5,filesize=100m # For older Java versions (pre-9) -XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:gc.log
Key Metrics to Watch
| Metric | What it Tells You | Action Threshold |
|---|---|---|
| GC Frequency | How often GC runs | >1 per second (minor) |
| Pause Time | Duration of app stop | >100ms (depends on SLA) |
| Memory After GC | Memory usage post-collection | >70% heap used |
| Allocation Rate | Speed of object creation | Steadily increasing |
Reading the Signs
If you see memory usage climbing after each GC without falling back down, you likely have a memory leak. If minor GCs happen constantly, your Young Generation might be too small. If Full GCs are frequent, you might need more heap or have inefficient object lifecycle patterns.
Practical Tuning Example
Let’s say you have a web application with these symptoms:
- 4GB heap (-Xmx4g)
- Response times spike every few minutes
- Logs show Full GC events taking 2+ seconds
Here’s a tuning approach:
# Before
java -Xmx4g -Xms4g -jar app.jar
# After: Switch to G1, set pause goal, increase heap
java -Xmx6g -Xms6g -XX:+UseG1GC -XX:MaxGCPauseMillis=200 \
-XX:G1HeapRegionSize=16m -jar app.jar
Results you might expect:
- Full GC events become rare
- Pause times drop to 150-200ms
- Throughput improves by 15-20%
Common Pitfalls
Oversizing the Heap
More memory isn’t always better. A 32GB heap means GC has more to scan, leading to longer pauses. Use what you need, not what you have.
Ignoring Young Generation Sizing
If objects are promoted to Old Gen too quickly, you’ll get more Full GCs. Tune the ratio:
-XX:NewRatio=2 # Old Gen twice the size of Young Gen
Not Setting Min and Max Heap Equal
When they differ, the JVM spends time resizing the heap. In production, always set:
-Xms4g -Xmx4g # Both set to 4GB
Useful Tools and Resources
Monitoring Tools
- VisualVM – Free profiler bundled with JDK, great for visualizing GC behavior
- Java Mission Control – Advanced profiling and diagnostics
- GCeasy.io – Upload GC logs for automated analysis and recommendations
- GCViewer – Open-source GC log analyzer with timeline visualizations
Official Documentation
- Oracle: HotSpot Virtual Machine Garbage Collection Tuning Guide
- Oracle: The Z Garbage Collector
- OpenJDK: Shenandoah GC
Learning Resources
Books Worth Reading
- “Java Performance: The Definitive Guide” by Scott Oaks
- “Optimizing Java” by Benjamin J. Evans, James Gough, and Chris Newland
Final Thoughts
Garbage collection isn’t something to fear or avoid thinking about. It’s a powerful tool that, when understood, gives you control over your application’s performance characteristics. Start with sensible defaults, measure actual behavior under realistic load, and tune based on data rather than assumptions.
premature optimization is the root of all evil, but understanding your GC behavior isn’t premature—it’s fundamental.
