Shulou(Shulou.com)06/03 Report--

This article is to share with you about the serial parallelism in java and how the CMS garbage collector is. The editor thinks it is very practical, so I share it with you to learn. I hope you can get something after reading this article.

1. Serial Collector: SerialGC

A serial collector is a collector that uses a single thread. For each collector, the serial recycler has only one worker thread. For computers with weak parallel ability, the concentration and exclusivity of serial recyclers can often make them have better performance.

The serial collector can be used in the new generation and the old age, and it can be divided into the new generation serial collector and the old serializer according to the different heap space.

1.1 New Generation Serial Collector: SerialGC

Serial recyclers have two main features:

Garbage collection using only a single thread

Exclusive garbage collection

Use the-XX:+UseSerialGC parameter to specify the use of either a new generation serial collector or an old serial collector. When the virtual machine is running in Client mode, it is the default garbage collector.

1.2 Old serial recycler: SerialOldGC

The label compression method used by the old serial collector is the same as the new generation serial collector, it is also a serial exclusive garbage collector. Because the old garbage collection usually takes longer than the new generation of garbage collection, in applications with large heap space, once the old serial collector starts, the application is likely to pause for a long time.

To turn on the old serial collector, try using the following parameters

-XX:+UseSerialGC: serial recyclers are used in the new generation and the old age

-XX:+UseParNewGc: the new generation uses the parNew recycler, while the old generation uses the serial recycler. Jdk9 and jdk10 have deleted this parameter because ParNew needs to work with CMS, and CMS has been replaced by G1, so this parameter is no longer supported.

-XX:+UseParallelGC: the new generation uses the ParallelGC recycler and the old generation uses the serial recycler.

1.3 Recycling example

Sample code:

Public class Demo02 {public static void main (String [] args) {byte [] b = null; for (int I = 0; I

< 10; i++) { b = new byte[2 * 1024 * 1024]; } }} 使用参数 -Xmx10m -Xms10m -Xmn2m -XX:SurvivorRatio=2 -XX:+PrintGCDetails -XX:+UseSerialGC 运行，gc 日志如下： //回收新生代[GC (Allocation Failure) [DefNew: 1024K->

337K (1536K), 0.0007683 secs] 1024K-> 337K (9728K), 0.0007883 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] / / Recycling the Cenozoic and the old [GC (Allocation Failure) [DefNew: 645K-> 37K (1536K), 0.0008160 secs] [Tenured: 6470K-> 2410K (819K), 0.0015724 secs] 6789K-> 2410K (9728K), [Metaspace: 2952K-> 2952K (1056768K)], 0.0024163 secs] [Times: user=0.00 sys=0.00] Real=0.00 secs] / / omit other logs.

The DefNew in the log represents the new generation, and the Tenured indicates the old age.

two。 Parallel collector

The parallel collector is an improvement on the serial collector, which uses multiple threads for garbage collection at the same time. For computers with strong parallel ability, the time required for garbage collection can be effectively reduced.

2.1Multithreaded version of SerialGC: ParNew recycler

The ParNew collector is a garbage collector that works in the new generation.

It simply makes the serial recycler multi-threaded, and its recovery strategy, algorithm and parameters are the same as the new generation serial recycler. On cpu with strong concurrency ability, its pause time is shorter than serial recycler, but in single cpu or weak concurrency system, the effect of parallel recycler is not better than serial recycler. Due to the pressure of multi-thread, its actual performance is likely to be worse than serial recycler.

The following parameters can be used to enable the ParNew collector:

-XX:+UseParNewGC: the new generation uses the ParNew recycler and the old generation uses the serial recycler. Jdk9 and jdk10 have been deleted because ParNew needs to work with CMS, and CMS has been replaced by G1, so this parameter is no longer supported.

-XX:+UseConcMarkSweepGC: the ParNew collector is used in the new generation, but it is not recommended in the old CMS.jdk9 and jdk10. It is recommended to use the default G1 garbage collector.

The number of threads when the ParNew recycler is working can be specified using the-XX:ParallelGCThreads parameter. In general, it is best to be equal to the number of CPU to avoid too many threads affecting garbage collection performance. By default, when the number of CPU is less than 8, the value of ParallelGCThreads is equal to the number of CPU, and when the number of CPU is greater than 8, the value of ParallelGCThreads is equal to 3 + ((5xCPU_Count) / 8) (the number of CPU is 16:00, the value of ParallelGCThreads is 13)

Sample code:

Public class Demo02 {public static void main (String [] args) {byte [] b = null; for (int I = 0; I

< 10; i++) { b = new byte[2 * 1024 * 1024]; } }} 使用参数 -Xmx10m -Xms10m -Xmn2m -XX:SurvivorRatio=2 -XX:+PrintGCDetails -XX:+UseParNewGC 运行，gc 日志如下： [GC (Allocation Failure) [ParNew: 1024K->

384K (1536K), 0.0004642 secs] 1024K-> 384K (9728K), 0.0004796 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] [GC (Allocation Failure) [ParNew: 691K-> 265K (1536K), 0.0009477 secs] [Tenured: 6509K-> 2407K (819K), 0.0012491 secs] 6835K-> 2407K (9728K), [Metaspace: 2933K-> 2933K (1056768K)], 0.0022175 secs] [Times: user=0.00 sys=0.00] Real=0.00 secs] [GC (Allocation Failure) [ParNew: 41K-> 45K (1536K), 0.0006914 secs] [Tenured: 6503K-> 2407K (819K), 0.0012305 secs] 6544K-> 2407K (9728K), [Metaspace: 2936K-> 2936K (1056768K)], 0.0019425 secs] [Times: user=0.01 sys=0.00, real=0.01 secs] / / omit other logs.

As you can see, this output is almost the same as that of the new generation serial collector, except for the collector identifier.

2.2 A recycler focused on throughput: ParallelGC

ParallelGC is a garbage collector that can work in both the new generation and the old era. When working in the new generation, it was called ParallelGC, and when working in the old age, it was called ParallelOldGC.

2.2.1 New generation ParallelGC recycler

The new generation of ParallelGC collectors are also collectors that use replication algorithms. On the face of it, it is a multithreaded, exclusive collector like the ParaNew collector, but the Parallel recycler has an important feature: it is very concerned about the throughput of the system.

The new generation of Parallel collectors can be enabled with the following parameters:

-XX:+UseParallelGC: the new generation uses the ParallelGC recycler and the old generation uses the serial recycler.

-XX:+UseParallelOldGC: the new generation uses the ParallelGC recycler and the old generation uses the ParallelOldGC recycler.

The ParallelGC recycler provides two important parameters to control the throughput of the system:

-XX:MaxGCPauseMillis: sets the maximum garbage collection pause time. Its value is an integer greater than 0. While ParallelGC is working, it adjusts the java heap size or other parameters to guide the pause time to be controlled within MaxGCPauseMillis as much as possible.

-XX:GCTimeRatio: sets the throughput size. Its value is an integer between 0 and 100. assuming that the value of GCTimeRation is n, the system will spend no more than 1 / (1 percent n) on garbage collection. By default, its value is 99, that is, no more than 1 / (1 percent 99) = 1% of the time for garbage collection.

In addition, the ParallelGC collector supports an adaptive GC tuning strategy, which can be turned on with-XX:+UseAdaptiveSizePolicy. In this model, parameters such as the size of the new generation, the ratio of eden to survivor, and the age of the object in the old age will be automatically adjusted to achieve the balance between heap size, throughput and pause time.

2.2.2 Old ParallelOldGC recycler

The old ParallelOldGC recycler is also a multithreaded concurrent recycler. Like the new generation of ParallelGC collectors, it is also a throughput-focused collector.

Old ParallelOldGC can be enabled with the following parameters:

-XX:+UseParallelOldGC: the new generation uses the ParallelGC recycler and the old generation uses the ParallelOldGC recycler.

The parameter-XX:ParallelGCThreads can also be used to set the number of threads for garbage collection.

2.2.3 Recycling example

Sample code:

Public class Demo02 {public static void main (String [] args) {byte [] b = null; for (int I = 0; I

< 10; i++) { b = new byte[2 * 1024 * 1024]; } }} 使用参数 -Xmx10m -Xms10m -Xmn2m -XX:SurvivorRatio=2 -XX:+PrintGCDetails -XX:+UseParallelOldGC 运行，gc 日志如下： //回收年轻代[GC (Allocation Failure) [PSYoungGen: 464K->

432K (1536K)] 6616K-> 6584K (9728K), 0.0013387 secs] [Times: user=0.01 sys=0.00, real=0.00 secs] / / Recycling Old Age [Full GC (Allocation Failure) [PSYoungGen: 432K-> 0K (1536K)] [ParOldGen: 6152K-> 2407K (819K)] 6584K-> 2407K (9728K), [Metaspace: 2928K-> 2928K (1056768K)], 0.0032880 secs] [Times: user=0.01 sys=0.00, real=0.01 secs] 2.3 CMS Collector (jdk8 and previous versions)

Unlike ParallelGC and ParallelOldGC, the CMS (Concurrent Mark Sweep, meaning concurrent mark cleanup) collector focuses on system pause time. It's an old garbage collector.

The main steps of CMS are as follows:

Initial tag (CMS-initial-mark): tag root object (STW)

Concurrent tagging (CMS-concurrent-mark): marking all objects

Pre-cleaning (MS-concurrent-preclean): prepare and control pause time before cleaning

Relabeling (CMS-remark): correcting concurrent tag data (STW)

Concurrent cleanup (CMS-concurrent-sweep): cleaning up garbage

Concurrent reset (CMS-concurrent-reset): after garbage collection is complete, reinitialize the CMS data to prepare for the next garbage collection.

In the above process, concurrent marking, concurrent cleanup, and concurrent reset can all be performed with the application thread.

The main parameters of the CMS recycler are as follows:

Start the CMS garbage collector:-XX:+UseConcMarkSweepGC

Turn off pre-cleanup:-XX:-CMSPrecleaningEnabled. During the entire CMS recycling process, by default, there is a pre-cleaning operation after the concurrent tag, which is concurrent, and attempts to control a pause time in addition to a preparation check for formal cleanup.

Set the number of concurrent threads of CMS: the default number of recycling threads started by CMS is (ParallelGCThreads + 3) / 4). If you need to set it explicitly, you can set it through-XX:ParallelCMSThreads=20, where ParallelGCThreads is the number of parallel collection threads of the younger generation.

Specify the threshold for memory reclamation: because CMS is not exclusive, the application is still working non-stop during the recycling process. In the course of the application's work, rubbish is constantly generated, which cannot be removed in the current recycling process. At the same time, because the application is not interrupted, you should also ensure that the application has enough memory available during CMS recycling. Therefore, the CMS collector does not wait until the heap memory is saturated before garbage collection, but begins to collect when the heap memory usage reaches a certain threshold. This recycling threshold can be specified by parameter-XX:CMSInitiatingOccupancyFraction. The default is 68, that is, a CMS recycling will be performed when the old space utilization reaches 68%.

Enable defragmentation: CMS will not defragment the heap, so in order to prevent full gc caused by heap fragmentation, merge defragmentation option:-XX:+UseCMSCompactAtFullCollection is enabled in the CMS phase. Memory defragmentation is not concurrent, so performance will be consumed.

Specify how many times the CMS is recycled, and then perform a memory compression:-XX:CMSFullGCBeforeCompaction

Reclaim Perm area: CMS does not recycle Perm area by default. If the Perm area is full, a FullGC will be triggered. If you want to use CMS to recycle the Perm zone, you can use the parameter-XX:+CMSClassUnloadingEnabled.

Sample code:

Public class Demo02 {public static void main (String [] args) {byte [] b = null; for (int I = 0; I

< 10; i++) { b = new byte[2 * 1024 * 1024]; } }} 使用参数 -Xmx10m -Xms10m -Xmn2m -XX:SurvivorRatio=2 -XX:+PrintGCDetails -XX:+UseConcMarkSweepGC 运行，gc 日志如下： [GC (Allocation Failure) [ParNew: 1024K->

362K (1536K), 0.0013608 secs] 1024K-> 362K (9728K), 0.0014303 secs] [Times: user=0.01 sys=0.00, real=0.00 secs] [GC (Allocation Failure) [ParNew: 730K-> 264K (1536K), 0.0028882 secs] [CMS: 6490K-> 2418K (819K), 0.0025366 secs] 6874K-> 2418K (9728K), [Metaspace: 3008K-> 3008K (1056768K)], 0.0054949 secs] [Times: user=0.01 sys=0.00 Real=0.01 secs] [GC (CMS Initial Mark) [1 CMS-initial-mark: 4466K (819K)] 4466K (9728K), 0.0004792 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] [CMS-concurrent-mark-start] [GC (Allocation Failure) [ParNew: 41K-> 55K (1536K), 0.0008476 secs] [CMS [CMS-concurrent-mark: 0.002mp 0.003 secs] [Times: user=0.01 sys=0.00 Real=0.00 secs] (concurrent mode failure): 6514K-> 2418K (819K), 0.0035573 secs] 6555K-> 2418K (9728K), [Metaspace: 3016K-> 3016K (1056768K)], 0.0044327 secs] [Times: user=0.01 sys=0.00, real=0.01 secs] [GC (Allocation Failure) [ParNew: 41K-> 11K (1536K), 0.0008080 secs] [CMS: 6514K-> 2419K (819K), 0.0013165 secs] 6555K-> 2419K (9728K), [Metaspace: 3026K-> 3026K (1056768K)] 0.0021484 secs] [Times: user=0.01 sys=0.00, real=0.00 secs] [GC (CMS Initial Mark) [1 CMS-initial-mark: 4467K (8192 K)] 4467K (9728K), 0.0002437 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] [CMS-concurrent-mark-start] [GC (Allocation Failure) [ParNew: 20K-> 4K (1536K), 0.0006944 secs] [Times [CMS-concurrent-mark: 0.001 secs] [Times: user=0.00 sys=0.00 Real=0.00 secs] (concurrent mode failure): 6515K-> 2419K (819K), 0.0023357 secs] 6536K-> 2419K (9728K), [Metaspace: 3037K-> 3037K (1056768K)], 0.0030568 secs] [Times: user=0.01 sys=0.00, real=0.00 secs]

The relevant information is described as follows:

CMS Initial Mark: initial markup

CMS-concurrent-mark: concurrent markup

CMS-concurrent-preclean-start: pre-cleaning

CMS-concurrent-abortable-preclean: abortable pre-cleaning, waiting for a new generation of GC for follow-up operations. The pre-cleaning is followed by the relabeling stage, because the relabeling is exclusive of CPU, if a relabel is triggered immediately after the occurrence of the new generation GC, then the pause may take a long time. In order to avoid this situation, the preprocessing will deliberately wait for the occurrence of a new generation GC, and then predict the possible occurrence time of the next new generation GC based on the historical performance data. Re-mark the time between the current time and the predicted time, so as to avoid the coincidence of the new generation GC and the re-marking as much as possible, and reduce the pause time as much as possible.

CMS-remark: relabeling

CMS-concurrent-sweep: concurrent cleanup

CMS-concurrent-reset: concurrent reset

The concurrent collection of the concurrent mode failure:CMS collector fails, which is probably due to the fact that the garbage has not been collected and the new garbage is generated while the application is running, resulting in insufficient space in the old age. You can consider increasing the old space or setting a smaller-XX:CMSInitiatingOccupancyFraction parameter. Note: if insufficient memory has occurred during the execution of CMS, CMS collection will fail, and the virtual machine will launch the old serial collector for garbage collection, and the application will be completely interrupted until garbage collection is complete, so try to avoid this situation.

These are the serial parallel and CMS garbage collectors in java. The editor believes that there are some knowledge points that we may see or use in our daily work. I hope you can learn more from this article. For more details, please follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.