Garbage Collector: Do not use the default
Do you know what the Garbage Collector (GC) in the JVM is?
If not, you can think of it as the silent hero of memory management. It quietly frees unused memory and saves developers from manual memory deallocation.
I won’t explain how it works here. If you’d like a deep dive on that, leave a comment, and I’ll write about it.
What I want to talk about today is something practical: don’t just rely on the default Garbage Collector.
How Many Garbage Collectors Do We Have?
Depending on your Java version, OpenJDK offers five main Garbage Collectors:
Serial GC
Parallel GC
G1 GC
ZGC
Shenandoah
Each GC is designed for different goals. Some focus on throughput, others on low latency. They also manage heap memory differently, which can significantly impact your application’s performance.
Choosing the wrong GC for your workload can cost you performance, stability, or memory efficiency.
What Is the Default GC?
The answer is: it depends 😅
According to the OpenJDK source code:
If you have one processor or up to ~1.8 GB of RAM, the JVM uses Serial GC.
If you have 2 or more processors and 1.8 GB+ of RAM, it uses G1 GC.
The default choice may work well, but that does not mean it is optimal for your system.
What About Microservices?
If you are running microservices, especially in containers, memory configuration becomes critical.
Many teams experience memory issues because they rely on defaults without understanding how the JVM behaves inside Kubernetes or Docker.
In many microservice scenarios, G1 GC is a solid and balanced choice. It provides good throughput and predictable pause times.
You can configure it explicitly, for example:
-XX:+UseG1GC
-XX:MaxRAMPercentage=75
-XX:InitialRAMPercentage=75Heap sizing and RAM percentage tuning can make a big difference in container environments.
Learn More
If you want to understand how Java behaves in containers, I recommend these articles:
https://learn.microsoft.com/en-us/azure/developer/java/containers/overview
https://docs.oracle.com/en/java/javase/21/gctuning/ergonomics.html
And also this great talk by Bruno Borges: Secrets of Performance Tuning Java on Kubernetes
Final Thought
The Garbage Collector is not just an internal JVM detail. It directly affects performance, latency, and stability.
Don’t just use the default.
Understand your workload.
Test different configurations.
Measure the impact.
Performance tuning starts with awareness.