Garbage collectors-serial vs. Parallel vs. CMS vs. G1 (and what's new in Java 8)--Go

The 4 Java garbage collectors-how the wrong Choice dramatically impacts performance

The year is, and there is, things that still remain a mystery to most developers-garbage collection and Understa Nding the opposite sex. Since I don ' t know much about the latter, I thought I ' d take a whack at the former, especially as a Seen some major changes and improvements with Java 8, especially with the removal of the PermGen and some new and excitin G Optimizations (more on this towards the end).

When we speak about garbage collection, the vast majority of us know the concept and employ it in our everyday programming . Even so, there's much about it we don ' t understand, and that's when things get painful. One of the biggest misconceptions about the JVM was that it had one garbage collector, where in fact it providesFour different ones, each with its own unique advantages and disadvantages. The choice of which one to use isn ' t automatic and lies on your shoulders and the differences in throughput and Applicatio N pauses can be dramatic.

What's common about these four garbage collection algorithms was that they was generational, which means they split the man Aged heap into different segments, using the age-old assumptions a most objects in the heap is short lived and should Be recycled quickly. As this too are a well-covered area, I ' m going to jump directly into the different algorithms, along with their pros and th Eir cons.

1. The Serial Collector

The serial collector is the simplest one, and the one probably won ' t being using, as it's mainly designed for Single-thre aded environments (e.g. + bit or Windows) and for small heaps. This collector freezes all application threads whenever it's working, which disqualifies it for all intents and purposes F Rom being used in a server environment. How to use it:you can with it by turning on the -xx:+useserialgc JVM argument,

2. The Parallel/throughput collector

Next off is the Parallel collector. This is the JVM ' s default collector. Much like its name, it biggest advantage is, it's uses multiple threads to scan through and compact the heap. The downside to the parallel collector was that it would stop application threads when performing either a minor or full GC Collection. The parallel collector is best suited for apps-can tolerate application pauses and is trying-optimize for lower C PU overhead caused by the collector.

3. The CMS Collector

Following up to the parallel collector is the CMS collector ("Concurrent-mark-sweep”). This algorithm uses multiple threads ("concurrent") to scan through the heap ("Mark") for unused objects so can be RECYC LED ("Sweep"). This algorithm would enter "Stop the World" (STW) mode in the Cases:when initializing the initial marking of roots (object s in the old generation that is reachable from thread entry points or static variables) and when the application have Chan Ged the state of the heap while the algorithm is running concurrently, forcing it to go back and does some final touches to Make sure it have the right objects marked.

The biggest concern when using this collector is encounteringPromotion FailuresWhich is instances where a race condition occurs between collecting the young and old generations.  If The collector needs to promote young objects to the old generation, but hasn ' t had enough time to make space clear it, It'll has to does so first which would result in a full STW collection-the very thing this CMS collector is meant to P Revent. To make sure this doesn ' t happen you would either increase the size of the old generation (or the entire heap for that mat ter) or allocate more background threads to the collector for him to compete with the rate of object allocation.

Another downside to this algorithm in comparison to the parallel collector are that it uses more CPUs in order to provide th e application with higher levels of continuous throughput, by using multiple threads to perform scanning and collection. For most long-running server applications which is adverse to application freezes, which ' s usually a good trade off to mak E. Even so, this algorithm isNot on by default. You have to specifyXX:+USEPARNEWGCTo actually enable it. If you ' re willing to allocate more CPU resources to avoid application pauses this is the collector you'll probably want to  Use, assuming this your heap is less than 4Gb in size. However, if it ' s greater than 4GB, you'll probably want to use the last algorithm-the G1 Collector.

4. The G1 Collector

The garbage First collector (G1) introduced in JDK 7 update 4 is designed to better support heaps larger than 4GB. The G1 collector utilizes multiple background threads to scan through the heap that it divides into regions, spanning from 1MB to 32MB (depending on the size of your heap). G1 Collector is geared towards scanning those regions this contain the most garbage objects first, giving it it name (Gar Bage first). This collector was turned on using the–XX:+USEG1GCFlag.

This strategy the chance of the heap being depleted before background threads has finished scanning for unused objects, I n which case the collector would has to stop the application which would result in a STW collection. The G1 also have another advantage that's it compacts the heap on-the-go, something the CMS collector only does Durin G Full STW collections.
Large Heaps has been a fairly contentious area over the past few years with many developers moving away from the single J VM per machine model to more micro-service, componentized architectures with multiple JVMs per machine. This have been driven by many factors including the desire to isolate different application parts, simplifying deployment a nd avoiding the cost which would usually come with reloading application classes into memory (something which have actually been improved in Java 8).

Even so, one of the biggest drivers to does this if it comes to the JVM stems from the desire to avoid those long "stop th E World "pauses (which can take many seconds in a large collection) that occur with large heaps. This have also been accelerated by container technologies like Docker-enable you-deploy multiple apps on the same p Hysical machine with relative ease.

Java 8 and the G1 Collector

Another beautiful optimization which was just out with Java 8 update all for the G1 Collector String deduplication . Since strings (and their internal char[] arrays) takes much of our heap, a new optimization have been made that enables the G1 collector to identify strings which is duplicated more than once across your heap and correct them Same internal char[] array, to avoid multiple copies of the same string from residing inefficiently within the heap. You can use the -xx:+usestringdeduplicationJVM argument-to-try this out.

Java 8 and PermGen

One of the biggest changes made in Java 8 was removing the PermGen part of the heap it was traditionally al Located for class Meta-data, interned strings and static variables. This would traditionally require developers with applications that would load significant amount of classes (something COM Mon with apps using enterprise containers) to optimize and tune for this portion of the heap specifically. This have over the years become the source of many OutOfMemory exceptions and so have the JVM (mostly) take care if it's a Very nice addition. Even so, this in itself would probably not reduce the tide of developers decoupling their apps into multiple jvms. &nb Sp

Each of these collectors are configured and tuned differently with a slew of toggles and switches, each with the PO Tential to increase or decrease throughput, all based on the specific behavior app. We ' ll delve into the key strategies of configuring each of these in our next posts. 

Reference from:

Http://java.dzone.com/articles/garbage-collectors-serial-vs-0?mz=110215-high-perf

Garbage collectors-serial vs. Parallel vs. CMS vs. G1 (and what's new in Java 8)--Go