GC algorithms/collectors define how GC is expected to behave at run time. There are various Collectors that you can use depending on your need. Note that the collectors vary greatly by the implementation of the JVM. This document addresses Oracle Hotspot JVM.
Note: Unless you explicitly specify a GC collector in the JVM command line, JVM selects the best collector to use based on various factors such as the hardware, platform etc
1. Serial Collector
Simplest. It uses just one thread to perform the GC operation. So, it is suited for single processor machines (are there any still left ?).
2. Parallel Collector (a.k.a Throughput Collector)
Uses multiple threads to perform minor GC, so it is generally faster than Serial Collector. It is intended to be used in multi processor machines to run multiple threads in parallel. With the option ‘-XX:+UseParallelOldGC’, major collections can also be performed in parallel (otherwise major collections are performed using a single thread). For most of the enterprise class applications, JVM will choose this collector as the default collector
3. Concurrent Mark and Sweep (CMS) Collector
Strives to avoid ‘Stop the world’ JVM pausing while performing GC by executing simultaneously along with the Application (Both Serial and Parallel collectors mentioned above will pause the JVM while collecting which can result in poor perceived performance. ). It is designed for Applications that cannot tolerate long GC pauses (Video games, for example)
4. G1 Collector (Garbage first collector)
Newest addition to the collectors, it runs multiple GC threads in the background to locate the heap region that has the most garbage. Since it is still fairly new collector, perform lots of load tests before going with G1 collector.
Here is a table that summarizes the various collectors:
| Collector | Function | Recommended for | How to enable |
| Serial Collector | Uses single thread for both minor and major collections. Simplest. | Single processor machines | -XX:+UseSerialGC |
| Parallel Collector (Throughput Collector) | Uses multiple threads for minor collection. | Multi processor machines, enterprise class applications | -XX:+UseParallelGC To enable Major parallel collection, add -XX:+UseParallelOldGC |
| CMS Collector (Concurrent Mark and Sweep Collector) | Mostly performs GC simultaneously along with Application | Applications that cannot tolerate longer GC pause times | -XX:+UseConcMarkSweepGC |
| G1 Collector | Strives to collect from Heap regions that have the most garbage | Most enterprise class applications. Through testing required before implementing. | –XX:+UseG1GC |
An excellent tool to gauge the performance of various collector is verbose garbage collection log (more on that shortly).
For most applications, in my experience the CMS collector does work pretty well.
Note: IBM JDK uses different set of GC algorithms. Here is a quick review:
-Xgcpolicy:optthruput – Optimized for throughput
-Xgcpolicy:optavgpause – Optimized for GC Pause time
-Xgcpolicy:gencon – Generational heap
-Xgcpolicy:subpool – Suitable for Systems with 16+ processors.
Next, I will explain the most popular issues due to memory related problems.
Coming up: Troubleshooting GC: Heap Exhaustion
Previous: Troubleshooting GC: What is GC and how it works – Part 2