Comparative summary of various Java garbage collectors

[Introduction] It's 2017, but two things are still a mystery to most developers - garbage collection and the opposite sex (coders are being laughed at again). Since I don’t know much about the latter, I thought I’d try to talk about the former.

It's 2017, but two things are still a mystery to most developers - garbage collection and the opposite sex (coders are being laughed at again). Since I don't know much about the latter, I think I'll try to talk about the former. Especially with the arrival of Java 8, many major changes and improvements have taken place in this field, the most important of which is the persistent generation. (PermGen) removal and some exciting new optimizations (which will be mentioned later).

Speaking of garbage collection, many people understand its concept and use it in daily programming. Still, there's a lot we don't quite understand, and that's where the pain comes from. The biggest misconception about the JVM is that it has only one garbage collector, when in fact it has four different collectors, each with its own strengths and weaknesses. The JVM doesn't automatically choose one over the other, it's up to you and me, as different collectors can cause significant differences in throughput and application pause times.

What these four recycling algorithms have in common is that they are all generational, which means that they divide the managed heap into several areas. It assumes that there are many objects in the heap The lifecycle is very short and can be recycled quickly. There has been a lot of introduction to this topic, so here I intend to directly talk about these different algorithms, as well as their strengths and weaknesses.

1. Serial collector

The serial collector is the simplest one. You will not even consider using it because it is mainly for single-threaded environments (such as 32-bit or Windows) and a smaller heap. This collector freezes all application threads when it is working, which makes it completely impossible to be used by server-side applications.

How to use it: You can turn on the -XX:+UseSerialGC JVM parameter to use it.

2. Parallel/throughput collector

The next one is the parallel collector (Parallel collector). This is the JVM's default collector. As its name says, its biggest advantage is that it uses multiple threads to scan and compact the heap. Its disadvantage is that it will pause the application thread regardless of whether it is minor GC or full GC. The parallel collector is best suited for applications that can tolerate pauses and attempts to reduce the CPU overhead caused by the collector.

3.CMS collector

After the parallel collector is the CMS collector (concurrent-mark-sweep). This algorithm uses multiple threads (concurrent) to scan the heap and mark objects that are no longer used and can be swept (sweeped). This algorithm will enter a "stop the world" mode in two situations: when the initial marking of the root object (thread entry point in the old generation or staticvariable objects that were reached) and when the algorithm is running concurrently, the application changes the state of the heap so that it has to go back and confirm again that the objects it marked are correct.

The biggest problem with using this collector is that you will encounter promotion failure, which refers to the situation where competition conditions occur when recycling the new generation and the old generation. If the collector needs to promote young objects to the old generation, and there is no extra space in the old generation at this time, it can only perform a STW (Stop The World) full GC first - this is the correct situation. This is what CMS wants to avoid. To ensure that this doesn't happen, you either need to increase the size of the old generation (or increase the size of the entire heap), or allocate some background threads to the collector so that it can race against the speed of object allocation.

Another disadvantage of this algorithm is that compared with the parallel collector, it uses more CPU resources. It uses multiple threads to perform scanning and recycling, so that the application can continue to provide higher levels of throughput. For most long-running programs, application suspension is very detrimental to them. At this time, you can consider using the CMS recycler. However, this algorithm is not enabled by default. You have to specify XX:+UseConcMarkSweepGC to enable it. Assuming your heap is less than 4G and you want to allocate more CPU resources to avoid application suspension, then this is the collector you should choose. However, if the heap is larger than 4G, you may prefer to use the last one - the G1 collector.

4.G1 collector

The G1 (Garbage first) collector was first introduced in JDK 7update 4. Its design goal is to better support heaps larger than 4GB. The G1 collector divides the heap into regions ranging in size from 1MB to 32MB and uses multiple background threads to scan them. The G1 collector will scan areas containing the most garbage first, which is where its name comes from (Garbage first). This collector can be enabled with the -XX:UseG1GC flag.

This strategy reduces the possibility that the heap will be used up before the background thread has finished scanning the useless objects. In that case, the collector must pause the application, which will lead to STW recycling. Another benefit of G1 is that it always compacts the heap, while the CMS collector only does this during a full GC.

In the past few years, Dadu has been a controversial field. Many developers have shifted from a single machine and single JVM model to a single machine and multiple JVM microservices and componentization. Architecture. This is driven by a number of factors, including isolating application components, simplifying deployment, and avoiding the overhead of reloading application classes into memory (this has been improved in Java 8). However, the main hope of doing this is to avoid long "stop the world" pauses in large GCs (which take several seconds to complete during a large collection). Container technologies like Docker also accelerate this process, making it easy to deploy multiple applications on the same physical machine.

Java 8 and G1 Recycler

A great optimization introduced in Java 8 update 20 is the String

deduplication in the G1 Recycler (

String

deduplication). Since strings (including their internal char[]

arrays) take up most of the heap space, this new optimization is designed to enable the G1 collector to identify recurring strings in the heap and Point them to the same internal char[] array to avoid multiple copies of the same string, which would make heap usage inefficient. You can use the -XX:+UseStringDeduplication JVM parameter to try this feature. Java 8 and Persistent GenerationThe biggest change in Java 8 is the removal of the persistent generation, which was originally used to allocate space for class metadata, resident strings, and static variables. of. In the past, this required developers to specifically optimize and adjust the heap ratio for applications that would load a large number of classes. This has been true for many years and is the source of many OutOfMemory exceptions, so it's great to have the JVM take over. Even so, it does not by itself reduce the possibility of developers decoupling applications into different JVMs.

Each collector has many different switches and options for tuning, which may increase or decrease throughput, depending on the specific

behavior## of your application. #.

The above is the detailed content of Comparative summary of various Java garbage collectors. For more information, please follow other related articles on the PHP Chinese website!