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 GC
|Serial Garbage Collector
|This is well-matched for single-threaded environments and uses the only thread for GC
|Parallel Garbage Collector
|This is the default GC and runs on multiple threads in the JVM.
|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.
|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).
After multiple cycles, the reachable objects end up being separated by small unused segments of memory thus leading to fragmentation.
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.
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 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.
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.
|Windows/x64 Yes JDK 14 Requires Windows version 1803 (Windows 10 or Windows Server 2019) or later.