Java garbage collection (GC) performs automatic memory management for Java programs which can be compiled to bytecodes that can be run on a Java Virtual Machine (JVM). When these Java programs run on the JVM, objects are created on the heap which is a portion of memory dedicated. The unused objects are automatically deleted by GC and frees up the memory.

Types of Garbage Collector (GC)

#	Types of GC	Description
1	Serial Garbage Collector	This is well-matched for single-threaded environments and uses the only thread for GC
2	Parallel Garbage Collector	This is the default GC and runs on multiple threads in the JVM.
3	Concurrent Mark Sweep (CMS) Garbage Collector	This uses multiple threads that scan the heap and during the scanning, it marks the instances for eviction and after scanning, it sweeps the marked instances.
4	Garbage First (G1) Garbage Collector	This is used if we have a large (more than 4GB) memory (heap space). It divides the heap into equal-sized (usually 1MB to 32MB) chunks, prioritizes them & performs the parallel GC.

The performance and working of each GC are completely different and Java allows us to choose only one GC that can be used in the JVM.

Java has recently removed the Mark & Sweep Garbage collector and started Generation Z Garbage Collector (ZGC).

Disadvantage of Mark & Sweep GC:

After multiple cycles, the reachable objects end up being separated by small unused segments of memory thus leading to fragmentation.

About Z Garbage Collector (ZGC):

The ZGC is a scalable low latency GC which performs all expensive work concurrently, without stopping the execution of application threads for more than 10ms, and hence makes it suitable for all Java applications.

This ZGC is available as an experimental feature, and is enabled with the command-line options -XX:+UnlockExperimentalVMOptions -XX:+UseZGC.

1. Setting the Heap Size:

The most important tuning option for ZGC is setting the max heap size (-Xmx). Since it is a concurrent collector a max heap size must be selected such that:

• The heap can accommodate the live-set of your Java application.
• Enough headroom in the heap is allowed to allocate services while the GC is running.

The headroom space depends on the allocation rate and the live-set size of the application, which implies the more memory you give to ZGC the better application runs. The key is to find the right balance between memory usage and how often GC needs to be run.

2. Setting Number of Concurrent GC Threads

The second tuning option is setting the number of concurrent GC threads (-XX:ConcGCThreads). ZGC has heuristics to automatically select this number which usually works well, but depending on the characteristics of the application it needs to be adjusted accordingly. This option essentially dictates the CPU-time allocation to the GC. If more time is given, GC will steal too much CPU-time and if less time is given, the application might allocate garbage faster than the GC can collect.

ZGC Supported Platforms

Platform	Supported	Since	Comment
Linux/x64	Yes	JDK 11
Linux/AArch64	Yes	JDK 13	17653 ms
macOS/x64	Yes	JDK 14
macOS/AArch64	Yes	JDK 17
Windows/x64	Yes	JDK 14	Windows/x64 Yes JDK 14 Requires Windows version 1803 (Windows 10 or Windows Server 2019) or later.
Windows/AArch64	Yes	JDK 16

By Shiva
Java Expert