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

Transferred from: http://blog.takipi.com/garbage-collectors-serial-vs-parallel-vs-cms-vs-the-g1-and-whats-new-in-java-8/?utm_ Source=blog&utm_medium=in-post&utm_content=gcmisconceptions&utm_campaign=java

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 an D Exciting 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 provides four D Ifferent 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 (generational), which means they split th E managed heap into different segments (managed by dividing the heap into several parts), using the age-old assumptions that most objects in the heap is short lived and should be recycled quickly (generally we assume that the life cycle of most objects on the heap is very short and should be recycled very quickly, so use a generational recycling algorithm). 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 of you probably won ' t being using, as it's mainly designed fo R single-threaded 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 P Urposes from being used in a server environment (not available in low latency requirements and server environments). (This garbage collection algorithm can therefore be ignored)

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 to Optimiz E for lower CPUs overhead causedby 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 The can be recycled ("sweep"). this algorithm would enter "Stop the World" (STW) mode in and cases : when initializing The initial marking of roots (objects in the old generation that is reachable from thread entry points or static variabl ES) and when the application have changed 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 was encountering promotion failures which is instances W Here's 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 would have the to does so first which would result in a full STW collection , Haven ve Ry thing this CMS collector is meant to prevent. To make sure this doesn ' t happen you would either increase the size of the old generation (or the entire heap for this matter) or allocate more background threads to the collector for him to compete with the RA Te of object allocation .

Another downside to this algorithm in comparison to the parallel collector are that it uses more CPUs in order to P Rovide the application with higher levels of continuous throughput, by using multiple threads to perform scanning and Coll Ection. 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 are not on by default. Specify XX:+USEPARNEWGC to actually enable it. If you ' re willing to allocate more CPU resources to avoid application pauses the "The collector you ' ll probably WAN  T-Use, assuming-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 supp ORT heaps larger than 4GB . The G1 collector utilizes multiple background threads to scan through the heap that it divid Es 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 are turned on using the –XX:+USEG1GC flag .

This strategy the chance of the heap being depleted before background threads has finished scanning for unused objects , in which case the collector will has to stop the application which would result in a STW collection (until the heap memory is exhausted to stop the scan from being used Start recycling, which can lead to STW consequences). The G1 also have another advantage that's that it compacts the heap on-the-go, something the CMS Collector only does during full STW collections (G1 algorithm has an advantage that it can defragment heap memory without interfering with heap memory allocations, prevent heap memory fragmentation, and CMS will defragment heap memory only at STW) .

Large Heaps has been a fairly contentious area over the past few years with many developers moving away from the Singl E JVM 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). (Large heap of memory is currently controversial, many developers are inclined to use microservices, a modular architecture-a single server running multiple JVMs, so that the application can be isolated, simplified deployment)

Even so, one of the biggest drivers to does this if it comes to the JVM stems from the desire to avoid those long "sto P The world ' pauses (which can take many seconds in a large collection) that occur with largeheaps. 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 that is traditionally allocated for class Meta-data, intern ed 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.

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

In the meanwhile, what is the things you ' re most interested in learning about regarding the differences between the Diffe Rent collectors? Hit me up in the comments section

Additional reading–

1. A really great in-depth review of the G1 Collector on InfoQ.

2. Java performance–the Definitive Guide. My favorite book on Java performance.

3. More about String deduplication on the Codecentric blog.

----------------------------------------

Self-summary :

1) Parallel ,CMS , G1 are used in the background of multi-threaded scanning garbage (Serial can be ignored);

2) Parallel disadvantage is that both the minor GC and the full GC will pause the application ( so the application does not tolerate more delay ), the advantage is low CPU consumption, is the default;

3) The advantage of the CMS is that the number of pauses (frequency) is less , the disadvantage is that it consumes more CPU, fragmentation of heap memory, the use of CMS should allocate large heap memory and many background collection threads to reduce the occurrence of STW ;

4) The advantage of G1 is to reduce the number of pauses applied (frequency), but increase the duration of the pause application , without the disadvantage of heap memory fragmentation;

5) The permanent Zone of the heap memory is removed, because the area previously caused a lot of memory overflow, removed and then the JVM itself took over, we can not specify size;

Feel or CMS more reliable. Of course, it depends on the actual operating conditions.

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