Which garbage collector to use in java

Attention reader! Get hold of all the important Java Foundation and Collections concepts with the Fundamentals of Java and Java Collections Course at a student-friendly price and become industry ready.

Each garbage collector will vary in Application throughput and Application pause. Application throughput denotes the speed at which a Java application runs and Application pause means the time taken by the garbage collector to clean the unused memory spaces.

Skip to content. Change Language. Related Articles. Table of Contents. You can also read G1 Collector tuning for G1 performance improvement recommendations. ZGC is a low-latency garbage collector that works well with very large multi-terabyte heaps.

Like G1, ZGC works concurrently with the application. It does not stop the execution of application threads for more than 10ms. This collector is suitable for applications with very large amounts of memory that require very short pause times. Setting a maximum heap size is very important when using ZGC, because the collector's behavior depends on allocation rate variance and how much of the data set is live. ZGC works better with a larger heap, but wasting unnecessary memory is also inefficient, so you need to tune your balance between memory usage and the resources available for garbage collection.

The number of concurrent garbage collection threads is also an important value to tune with ZGC. This parameter determines how much CPU time is given to the garbage collector.

By default, ZGC automatically selects how many threads to run, which works for some applications but needs to be tuned for others. Specifying too many threads ends up using a lot of CPU, whereas specifying too few threads causes garbage to be created faster than it can be collected.

Shenandoah is another garbage collector with very short pause times. It reduces pause times by performing more garbage collection work concurrently with the application, including concurrent compaction.

Shenandoah's pause time is independent of the heap size. Garbage collecting a 2GB heap or a GB heap should have a similar short pause behavior. Shenandoah is best suited to an application that needs responsiveness and short pause times, irrespective of heap size requirements. The CMS collector has been preferred in applications that require short garbage collection pause times and that can share the processor resources with the garbage collector while the application is running.

This collector offers more benefit when long-lived tenured generation is high and the application is running on a machine with two or more available processors. CMS is a generational garbage collector, collecting the tenured generations.

By performing garbage collection—notably, mark-and-sweep operations—concurrently with the application thread, it ensures short pause times in the application. However, if the CMS collector is unable to clear the unreferenced objects before the old generation fills up, or if object allocation cannot be satisfied with available space in the old generation, CMS stops all the application threads to perform the garbage collection.

The state in which the CMS garbage collector could not complete garbage collection concurrently is known as concurrent mode failure and indicates the importance of tuning the parameters for the CMS collector.

This feature is designed to prevent applications from running for an extended period of time while making little or no progress because the heap is too small. CMS was deprecated to accelerate the development of other garbage collectors in HotSpot. Eliminating CMS will reduce the maintenance burden of the GC code base and accelerate new development.

The G1 garbage collector is intended, in the long term, to replace most uses of the Concurrent Mark Sweep collector. If none of these collectors works for your application requirements, you can still use Concurrent Mark Sweep as long as it remains supported in earlier releases.

This article has contrasted six Java garbage collectors based on throughput, latency, and footprint. You can use this information to choose the garbage collector best suited for your applications. Despite the extra work required, some programmers argue in favor of manual memory management over garbage collection, primarily for reasons of control and performance. While the debate over memory management approaches continues to rage on, garbage collection is now a standard component of many popular programming languages.

For scenarios in which the garbage collector is negatively impacting performance, Java offers many options for tuning the garbage collector to improve its efficiency. For many simple applications, Java garbage collection is not something that a programmer needs to consciously consider.

However, for programmers who want to advance their Java skills, it is important to understand how Java garbage collection works and the ways in which it can be tuned. Besides the basic mechanisms of garbage collection, one of the most important points to understand about garbage collection in Java is that it is non-deterministic, and there is no way to predict when garbage collection will occur at run time.

It is possible to include a hint in the code to run the garbage collector with the System. The best approach to tuning Java garbage collection is setting flags on the JVM. Flags can adjust the garbage collector to be used e. Serial, G1, etc. Young Generation, Old Generation , and more. The nature of the application being tuned is a good initial guide to settings.

On the other hand, the CMS garbage collector is designed to minimize pauses, making it ideal for GUI applications where responsiveness is important. Additional fine-tuning can be accomplished by changing the size of the heap or its sections and measuring garbage collection efficiency using a tool like jstat.

Prefix works with. Click here to read more about the acquisition. Try Our Free Code Profiler.