Serial GC
Garbage collection improves memory efficiency in Java by removing unreferenced objects from the heap and making room for newly created objects.
The Java virtual machine has eight types of garbage collectors. Let's consider each of them in detail.
Serial GC is the simplest GC implementation. It is intended for small applications running in single-threaded environments. All garbage collection events are executed sequentially on the same thread. Compaction is performed after each garbage collection.
Running the collector results in a "world stop" event, where the entire application is suspended. Since the entire application is frozen during garbage collection, you should not resort to this in real life if you want to keep delays as low as possible.
The JVM argument to use the serial garbage collector is -XX:+UseSerialGC .
Parallel GC
The parallel garbage collector is designed for applications with medium to large data sets that run on multithreaded or multiprocessor hardware. This is the default GC implementation and is also known as the throughput collector.
Several threads are destined for small garbage collection in the young generation. The only thread is busy with the main garbage collection in the older generation.
Running a parallel GC also causes the world to “stop” and the application hangs. This behavior is more appropriate for a multi-threaded environment where many tasks need to be completed and long pauses are acceptable, such as when running a batch job.
The JVM argument to use the parallel garbage collector is -XX:+UseParallelGC .
CMS GC
Also known to us as the low rest parallel picker .
Here, for a small garbage collection, several threads are involved, this happens through the same algorithm as in the parallel collector. The main garbage collection is multi-threaded, just like the old parallel GC, but the CMS runs concurrently with application processes to minimize "world stop" events.
Because of this, the CMS collector consumes more CPU than other collectors. If you have the ability to allocate more CPU to improve performance, then a CMS is preferable to a simple parallel collector. The CMS GC does not compact.
The JVM argument to use the parallel mark-sweep garbage collector is -XX:+UseConcMarkSweepGC .
G1 (Garbage first) GC
G1GC was conceived as a replacement for CMS and was developed for multi-threaded applications that are characterized by large heap sizes (greater than 4 GB). It's parallel and competitive like a CMS, but under the hood it works very differently than the old garbage collectors.
Although G1 also operates on a generational basis, it does not have separate spaces for younger and older generations. Instead, each generation is a set of regions, allowing flexibility in changing the size of the younger generation.
G1 splits the heap into a set of equally sized regions (depending on the size of the heap) and scans them into multiple threads. The area during the execution of the program can repeatedly become both old and young.
After the markup phase is complete, G1 knows which areas contain the most junk. If the user is interested in minimizing pauses, G1 can only select a few areas. If the pause time is not important to the user, or if the pause time limit is set to high, G1 will go over more areas.
Since the G1 GC identifies the regions with the most garbage and performs garbage collection on those regions first, it is called "Garbage First".
In addition to the areas of Eden, Survivors and Old Memory, there are two other types in G1GC.
- Humongous (Huge) - for objects of large size (more than 50% of the heap size).
- Available - Unused or unallocated space.
The JVM argument to use the G1 garbage collector is -XX:+UseG1GC .
Shenandoah (Shandara)
Shenandoah is a new GC released as part of JDK 12. The key advantage of Shenandoah over G1 is that most of the garbage collection cycle is done concurrently with application threads. G1 can only evacuate heap areas when the application is suspended, while Shenandoah moves objects at the same time as the application.
Shenandoah can compact live objects, clean up garbage, and free up RAM almost as soon as free memory is found. Since all this happens at the same time, without suspending the application, Shenandoah is more CPU intensive.
ZGC
ZGC is another GC released as part of JDK 11 and improved in JDK 12.
It is intended for applications that require speed and low latency (pauses of less than 10 ms) and/or use a very large heap (several terabytes).
The main goals of ZGC are low latency, scalability, and ease of use. To do this, it allows the Java application to continue running despite the fact that garbage collection operations are in progress. By default, ZGC releases unused memory and returns it to the operating system.
Thus, the ZGC brings a significant improvement over other traditional GCs by providing extremely low dead times (typically within 2ms).
The JVM argument to use the ZGC garbage collector is -XX:+UnlockExperimentalVMOptions -XX:+UseZGC .
GO TO FULL VERSION