introduce
The Throughput collector in the JVM is a garbage collector that focuses on throughput. This collector is the only one that implements the UseAdaptiveSizePolicy policy, which allows users to achieve the configured goal by specifying the maximum pause time and the percentage of garbage collection time in the total time, and then adaptively adjust the parameters of the JVM.
Throughtput collector
First, a picture of a classic garbage collector: I believe many people have seen this picture, showing the combination of various garbage collectors. The Thoughtput collectors we usually refer to are the collectors framed by the red lines in the figure. The following will introduce some of the characteristics and functions of these collectors.
ParallelScavenge Collector
The ParallelScavenge collector collects the new generation and uses Scavenge GC (another name for Copying GC). The collector is parallel, and multiple threads can execute the copying phase at the same time, which can improve the efficiency of minor gc as much as possible in the multi-processor scenario. The purpose of the ParallelScavenge collector is to achieve a controllable throughput, throughput = time to run user code / (time to run user code + time for garbage collection), the virtual machine runs for a total of 100 minutes, of which the garbage collector runs 1 minutes, then the throughput is 99%.
There is an interesting history about the ParallelScavenge collector. The developers of HotSpot VM develop in a generational framework when developing garbage collectors, and hope that third-party developers will also develop custom collectors in this framework, which can work well with other collectors. Use together. Later, a developer did not want to use this framework, so he implemented a parallel GC without a framework by himself, and the performance of this parallel GC was quite good, so this parallel GC was put into the HotSpot VM, which is The ParallelScavenge collector we saw. That's why this collector doesn't work with a CMS, because they're not in a framework at all.
When using the ParallelScavenge collector, you need to pay attention to the following two configuration parameters:
1. MaxGCPauseMills, this parameter controls the longest GC pause time allowed. The allowed value of the parameter is a number of milliseconds greater than 0. After setting this parameter, the VM will control the pause time by controlling the size of the new generation. Don't think that the smaller the parameter is, the better. The smaller the parameter is, the smaller the space of the new generation will be, which will lead to an increase in the number of garbage collections performed by the new generation. For example, it used to execute minor gc once every 10 seconds, with a pause of 100 milliseconds each time. Now the allowable pause time is reduced to 80 milliseconds, which may cause minor gc to be executed every 5 seconds, and the pause time is reduced, but Throughput has also dropped.
2. GCTimeRatio, the ratio of garbage collection time to total time. The value of this parameter should be an integer greater than 0 and less than 100. If this parameter is set to 19, the maximum allowed GC time is 5% of the total time (ie 1 /(1 + 19)), the default value is 99, which is the maximum allowed 1% (ie 1 /(1+99 )) garbage collection time.
By adjusting these two parameters, the throughput and pause time can be controlled. The user does not need to care about how much to set for the new generation and how much to set for the old generation. Just set these two values and leave the rest to the virtual machine. It will help you adjust the corresponding size. The new generation can be implemented in this way, so is there a similar way to implement the old generation? The answer is yes, it is Parralled Old in the picture.
Parralled Old collector
The Parralled Old collector is an older version of ParallelScavenge. The algorithm used is Mark-Compact. The Parralled Old collector only appeared after JDK1.6. Before that, if the new generation chooses to use ParallelScavenge, the old generation can only choose to use Serial Old, that is to say, only single-threaded collection can be used. In order to make up for this deficiency, so The Parallel Old collector was developed. With the Parallel Old collector, the Thoughtput collector really shows its power. In the case of throughput and CPU sensitivity, the combination of Parallel Scavenge+Parallel Old can be considered.
The schematic diagram of the operation of the Parallel Old collector is as follows:
Serial Old collector
The Serial Old collector is a traditional single-threaded garbage collector that uses the Mark-Sweep-Compact algorithm. This collector is mainly used in Client mode. The collector has two purposes: one is to work with the ParallelScavenge collector before JDK1.5; the second is to be used as a backup plan for the CMS collector, and the Serial Old collector is used when the CMS fails in concurrent mode. A complete STW garbage collection.
The schematic diagram of the operation of the Serial Old collector is as follows:
Collector configuration
Under JDK1.8, there are two configurations for using the Throughput collector:
1. -XX:+UseParallelGC or -XX:+UseParallelOldGC, the collectors used in either of these two configurations are ParallelScavenge+Parralled Old. This is different from most of the introductions on the Internet. Most of the introductions on the Internet say that ParallelScavenge+Serial Old is used in the UseParallelGC configuration. It has been unified under JDK1.8, and Serial Old is no longer the default choice.
2. If you want to use Serial Old as the old-age garbage collector, you can configure it like this: -XX:+UseParallelGC -XX:-UseParallelOldGC.
GC log description
The log under the -XX:+UseParallelGC or -XX:+UseParallelOldGC parameter:
- 2018-04-29T14:55:42.360-0800: [Full GC (System.gc()) [PSYoungGen: 1421K->0K(76288K)] [ParOldGen: 8K->1257K(175104K)] 1429K->1257K(251392K), [Metaspace: 3205K->3205K(1056768K)], 0.0054702 secs] [Times: user=0.02 sys=0.01, real=0.00 secs]
The log under the -XX:+UseParallelGC -XX:-UseParallelOldGC parameter:
- 2018-04-29T15:05:43.409-0800: [Full GC (System.gc()) [PSYoungGen: 1449K->0K(76288K)] [PSOldGen: 8K->1265K(175104K)] 1457K->1265K(251392K), [Metaspace: 3206K->3206K(1056768K)], 0.0034926 secs] [Times: user=0.00 sys=0.00, real=0.01 secs]
I used System.gc() to trigger GC under the two configurations respectively. By comparison, it can be found that only the collection in the old generation is different. The first one uses ParOldGen, which corresponds to the Parralled Old collector; The second one uses PSOldGen, which corresponds to the Serial Old collector. The new generation collection log PSYoungGen corresponds to the Parallel Scavenge collector.
Collector Tuning
It is strongly not recommended to manually specify the size of the young generation and the old generation when using the Thoughtput collector, because this will discard the adaptive adjustment strategy of the virtual machine. This means that the MaxGCPauseMills and GCTimeRatio parameters you configure are difficult to really work. Users only need to specify the maximum and minimum heap memory, as well as the parameters of MaxGCPauseMills and GCTimeRatio, and leave the rest to the VM to handle, it will help you adjust to the best state, which is also very user-friendly. The specific adjustment of the VM includes adjusting the size of the new generation and the old generation, and adjusting the age at which the new generation is promoted to the old generation.
For the parameters set above, MaxGCPauseMills has the highest priority. If this value is set, the new generation and old generation will be adjusted accordingly until the corresponding pause time target is met. Once this goal is achieved, the total capacity of the heap starts to grow until the runtime reaches the ratio GCTimeRatio set. After these two goals are achieved, the JVM attempts to reduce the heap size and meet these two goals with the smallest possible heap.
some other things
ParNew vs Parallel Scavenge
ParNew is also a new generation of parallel GC. The existence of ParNew is mainly for use with CMS. Without ParNew, CMS can only be used with single-threaded garbage collection. The differences between ParNew and Parallel Scavenge are as follows:
1. ParNew uses breadth-first to traverse the object graph, while Parallel Scavenge uses depth-first to traverse the object graph
2. ParNew does not implement the UseAdaptiveSizePolicy strategy, while Parallel Scavenge implements this strategy
3. ParNew can be used with CMS, while Parallel Scavenge cannot be used with CMS
Number of parallel GC threads
Set the number of parallel GC threads by -XX:ParallelGCThreads=X, which is the same as the number of processors by default.
Summarize
1. The Thoughtput collector has two parameters, Minor GC and Full GC
. 2. The dynamic adjustment strategy of the Thoughtput collector is a good entry point for garbage collection tuning, which can effectively reduce JVM memory usage
. 3. When throughput needs to be pursued Thoughtput is always a good choice when