Garbage Collectors Available in Java

Posted By : Amit Kumar | 30-Sep-2019



The Serial Garbage Collector


The simplest of the garbage collectors is the serial garbage collector. This is the default collector if the application is running on a client-class machine (32-bit JVMs on Windows or on single-processor machines).


The serial collector uses a single thread and will stop all application threads as the heap is processed. The serial collector is enabled by using the -XX:+UseSerialGC flag (though usually, it is the default in those cases where it might be used). Note that unlike most JVM flags, the serial collector is not disabled changing the plus sign to a minus sign (i.e., by specifying -XX:-UseSerialGC). On systems where the serial collector is the default, it is disabled by specifying a different GC algorithm.


The Throughput Collector


The throughput collector (Parallel Collector) uses multiple threads, which makes minor GCs much faster than when the serial collector is used. That is the default behavior in JDK 7u4 and later releases, and that behavior can be enabled in earlier JDK 7 JVMs by specifying the -XX:+UseParallelOldGC flag.


The throughput collector stops all application threads during both minor and full GCs, and it fully compacts the old generation during a full GC. Since it is the default in most situations where it would be used, it needn’t be explicitly enabled. To use this use the following flags -XX:+UseParallelGC -XX:+UseParallelOldGC.


The CMS Collector


The CMS collector is designed to eliminate the long pauses associated with the full GC cycles of the throughput and serial collectors. CMS stops all application threads during a minor GC, which it also performs with multiple threads. Notably, though, CMS uses a different algorithm to collect the young generation (-XX:+UseParNewGC) than the throughput collector uses (-XX:+UseParallelGC).


Instead of stopping the application threads during a full GC, CMS uses one or more background threads to periodically scan through the old generation and discard unused objects. This makes CMS a low-pause collector: application threads are only paused during minor collections, and for some very short periods of time at certain points as the background threads scan the old generation. The overall amount of time that application threads are stopped is much less than with the throughput collector.


The trade-off here comes with increased CPU usage: there must be adequate CPU available for the background GC thread(s) to scan the heap at the same time the application threads are running. In addition, the background threads do not perform any compaction, which means that the heap can become fragmented. If the CMS background threads don’t get enough CPU to complete their tasks, or if the heap becomes too fragmented to allocate an object, CMS reverts to the behavior of the serial collector: it stops all application threads in order to clean and compact the old generation using a single thread. Then it begins it's concurrent, background processing again (until, possibly, the next time the heap becomes too fragmented).

CMS is enabled by specifying the flags -XX:+UseConcMarkSweepGC -XX:+UseParNewGC (both of which are false by default).


The G1 Collector


The G1 (or Garbage First) collector is designed to process large heaps (greater than about 4 GB) with minimal pauses. It divides the heap into a number of regions, but it is still a generational collector. Some number of those regions comprise the young generation, and the young generation is still collected by stopping all application threads and moving all objects that are alive into the old generation or the survivor spaces. As in the other algorithms, this occurs using multiple threads.


G1 is a concurrent collector: the old generation is processed by background threads that don’t need to stop the application threads to perform most of their work. Because the old generation is divided into regions, G1 can clean up objects from the old generation by copying from one region into another, which means that it (at least partially) compacts the heap during normal processing. Hence, a G1 heap is much less likely to be subject to fragmentation—though that is still possible.




About Author

Author Image
Amit Kumar

Amit is an seasoned Backend Developer with expertise in Java, particularly the Spring framework as well as Javascript and related frameworks such as Node.js and Express. He possesses a solid understanding of blockchain fundamentals and has hands-on experience integrating major blockchains like Ethereum and Bitcoin into both centralized and decentralized applications. He is proficient in working with relational and non-relational databases, enabling him to handle various data storage requirements effectively. He has successfully contributed to a range of projects, including Belfrics, a cryptocurrency exchange platform, Daxxcoin, an Ethereum Proof-Of-Work fork, and Wethio blockchain, an Ethereum-based Proof-Of-Stake fork. His strong technical skills and practical experience make him a valuable asset, particularly in the blockchain domain. Amit's ability to integrate blockchain technologies into applications showcases his versatility and innovation.

Request for Proposal

Name is required

Comment is required

Sending message..