Garbage collector is a process run by JVM to recycle unused memory footprints of the applications. Say, you create an object. If you post the usage of the object, it still stays in the memory, unless you remove it from the memory. To alleviate the pains of memory management, JVM automated this process by introducing garbage collectors.
Live objects are tracked continuously and the rest of them are considered to be eligible for the next cycle of GC. Say, you have 10 objects created in an application flow. If five objects are still referenced in the application flow, they are considered to be live objects and the rest will be marked as eligible for next GC.
To determine which objects are no longer used, JVM runs the mark-and-sweep algorithm (https://en.wikipedia.org/wiki/Tracing_garbage_collection) in a periodic fashion. Reviewing the basics of GC (https://www.oracle.com/webfolder/technetwork/tutorials/obe/java/gc01/index.html) is important for understanding how a garbage collector is chosen.
There are multiple factors to be considered, based on the type of environment, before choosing the appropriate garbage collector. But the most important factor stays the same: how to reduce the stop the world pauses.
In order to get an idea on garbage collectors, lets have a look at the various options.
One of the earliest, single-threaded mode garbage collector. This is still a good-to-use collector when you have a single core VM.
With the advent of multi-core processors, a multi-threaded garbage collector was released. This is good if you are running a batch processing application, like processing a large file by splitting it into smaller chunks where lengthy GC pauses are not a real cause of concern. Since multiple threads are chosen to perform GC here, the optimal choice of number of threads is important to achieve the best throughput out of this GC.
CMS runs concurrently with the application threads. Although it has lesser throughput than Parallel GC, it has low latency pause times. In a nutshell, the applications may have more stop the world events with lesser GC pause times. As it runs parallel with application threads, the memory footprint of CMS is expected to be more. It's a preferred garbage collector for most of the general purpose applications.
Based on the principle of dividing the heap into regions, this leads the G1 Collector to lesser fragmentation of memory as it clean up at each region. Since region-based information is maintained internally, the memory footprint is expected to be more than CMS, but GC pauses are expected to be predictable. A user can configure the max pause time and control that aspect as well, but the user also has to keep an eye on the efficiency of the clean up in such circumstances.
Apart from these garbage collectors, there is one in experimental mode called the Z garbage collector. It's expected to address the concerns of low latency requirements and expected to perform better than G1 GC. Moving to a new garbage collector should not be a decision made quickly, but should result from a measured evaluation, and determined on an incremental basis.
The following are choices of garbage collectors:
|Serial GC||Very low memory footprint||Single threaded applications|
|Parallel GC||High Throughput||Batch processing|
|CMS||Low GC pauses||General applications|
|G1 GC||Predictable / controlled GC pauses||Applications working with larger heaps and uncontrolled GC delays|
The three most important factors to be considered before the choice of the garbage collector are: