Serial collector The Serial collector is the simplest GC implementation, mainly designed for single-threaded environments and small heaps. This GC implementation freezes all application threads whenever it's working. Hence, it's not a good idea to use it in multithreaded applications, such as server environments. To enable the Serial garbage collector, set -XX:+UseSerialGC to VM arguments

A GC can either cause a stop-the-world (STW) situation, or objects can be collected concurrently without stopping the application. The GC algorithm can be executed in a single thread or in multithread. So, Concurrent GC does not mean it executes in parallel, whereas Serial GC doesn't mean it causes more pauses due to serial execution. Concurrent and Parallel are different, where Concurrent means the GC cycle, and Parallel means the GC algorithm.

Most of the time, people are not aware that there isn't only one, but four, garbage collectors. The four garbage collectors are—Serial, Parallel, Concurrent, and Garbage First (G1). We will see them in the following section. There are some third-party garbage collectors, such as Shenandoah. JVM HotSpot's default garbage collector is Parallel up to Java 8, while from Java 9, the default collector is Garbage First Garbage Collector (G1 GC). A Parallel garbage collector isn't best most of the time; however, it depends on our application requirements. For example, the Concurrent Mark Sweep (CMS) and G1 collectors cause less frequent GC pauses. But when they do cause a pause, the pause duration will most likely be longer than a pause caused by the Parallel collector. On the other hand, the Parallel collector usually achieves higher throughput for the same heap size.