Post: Introduce and optimize jvm gc (garbage collection)

Source: Internet
Author: User

The following is a post on http://www.javadby.com/yuyanjichu/20080322/5220.html. Because the stress tests over the past few days and the GC review, I think this article is more detailed and helpful for checking GC print. Paste it.

 

Adjusting jvm gc (garbage collection) can greatly reduce the program running interruption problems caused by GC, and thus improve the working efficiency of Java programs. However, adjusting GC is a very complex process. Because each program has different characteristics, for example, the web and GUI programs are very different (the Web can be properly paused, however, the user cannot accept the GUI pause, and the GC type is also different because the configuration on each machine is different (the number of major CPUs and the memory is different. Next, I will briefly introduce how to adjust GC.

First, let's talk about how to monitor GC. You can use the jstat tool in JDK as mentioned in my previous article, or add the following parameters to the OPT started by the Java program (note: these two parameters are only for Sun's hotspot VM ):

-XX:-printgc print messages at garbage collection. manageable.
-XX:-printgc details print more details at garbage collection. Manageable. (introduced in 1.4.0 .)
-XX:-printgctimestamps print timestamps at garbage collection. Manageable (introduced in 1.4.0 .)

After adding-XX:-printgc details to Java opt, you can see the following output:

[GC [defnew: 34538 K-> 2311 K (36352 K), 0.0232439 secs] 45898 K-> 15874 K (520320 K), 0.0233874 secs]
[Full GC [tenured: 13563 K-> 15402 K (483968 K), 0.2368177 secs] 21163 K-> 15402 K (520320 K), [perm: 28671 K-> 28635 K (28672 K)], 0.2371537 secs]

They respectively show the GC process and how much space is cleared. The first line of GC uses 'General GC '(minor collections), and the second line uses 'full GC' (major collections ). They differ greatly. We can see that the last time in the first line is 0.0233874 seconds, and the full GC time in the second line is 0.2371537 seconds. The time of the second line is nearly 10 times that of the first line, that is, the focus of our optimization, reducing the number of full GC times, thinking that full GC will suspend the program for a long time, if the number of full GC times is large. The program will often be suspended. Of course, this is just their surface phenomenon. Next I will introduce GC and full GC (to prepare for subsequent optimization ).

We know that the main difference between Java and C ++ is that Java does not need to be actively released by programmers like C ++. Instead, the GC (garbage collection) in the JVM will release the memory for us as appropriate. There are many types of GC algorithms, such as Mark-clearing collectors, compression collectors, and generational collectors. Currently, generation-based collection is commonly used (also used by Sun VM). Memory is divided into several areas, place objects of different lifecycles in different regions (new objects are first generated in the young area. After several GC operations, if they are not collected, tenured area ). During GC collection, the young area with short lifecycles is frequently collected because the object lifecycle in this area is short and GC efficiency is also high. A relatively small area (old area or tenured area) with a long collection lifecycle, and a permanent area (Perm area) with basically no collection ).
Note: The young area is divided into three areas: Eden and two consumer vor spaces. Eden is used to store new objects, while vor spaces is used to copy new objects when they are upgraded to tenured area.
The collection of the young area with short lifecycles is called GC, while the collection of the old area or tenured area with long lifecycles is called full GC, because their collection algorithms are different, the time used varies. We should minimize the number of full GC times.

Next we will introduce the types of hotspot vm gc. There are four types of GC in hotspot VM 5.0. One is serial collector by default, and the other is throughput collector, concurrent low pause collector, and incremental (sometimes called Train) Low pause collector ). Sun's official instructions are as follows:

1. the throughput COLLECTOR: This collector uses a parallel version of the young generation collector. it is used if the-XX: + useparallelgc option is passed on the command line. the tenured generation collector is the same as the serial collector.
2. the concurrent low pause COLLECTOR: This collector is used if the-xincgc or-XX: + useconcmarksweepgc is passed on the command line. the concurrent collector is used to collect the tenured generation and does most of the collection concurrently with the execution of the application. the application is paused for short periods during the collection. A parallel version of the young generation copying collector is used with the concurrent collector. the concurrent low pause collector is used if the option-XX: + useconcmarksweepgc is passed on the command line.
3. the incremental (sometimes called Train) Low pause COLLECTOR: This collector is used only if-XX: + usetraingc is passed on the command line. this collector has not changed since the j2se platform version 1.4.2 and is currently not under active development. it will not be supported in future releases. please see the 1.4.2 GC tuning document for information on this collector.

In short, throughput collector and concurrent low pause COLLECTOR: use multi-threaded methods and use multiple CPUs to improve GC efficiency, throughput collector and concurrent low pause collector use multithreading only in the young area, while concurrent low pause collector uses multithreading in tenured generation.

According to the official documentation, the two of them need to play a role in the case of multiple CPUs. In the case of a CPU, It is inferior to the default serial collector because thread management consumes CPU resources. However, in the case of two CPUs, it is not very high. It can be improved only when more CPUs are available. Of course, concurrent low pause collector has a mode that provides as few pause modes as possible on machines with fewer CPUs. See the following figure.

To use throughput collector, add-XX: + useparallelgc to Java opt to start throughput collector collection. You can also add-XX: parallelgcthreads = <desired number> to change the number of threads. Two other parameters-XX: maxgcpausemillis = <NNN> and-XX: gctimeratio = <NNN>, maxgcpausemillis = <NNN> are used to control the maximum pause time, while-XX: gctimeratio can increase the CPU proportion of GC, and minimize heap.

When you want to use concurrent low pause collector, add-XX: + useconcmarksweepgc to the Java OPT. Concurrent low pause collector also has a mode for preparing machines with fewer CPUs, called incremental mode. In this mode, a CPU is used to perform GC during the program running, and the program is paused with only a small amount of time to check whether the object is alive.

In incremental mode, each collection process is paused twice, and the second time is slightly longer. Used for the first time to simply query the surviving objects from the root. The second time is used to check the surviving objects in detail. The process is as follows:

* Stop all application threads; do the initial mark; resume all application threads (first pause, initial call Mark)
* Do the concurrent mark (uses one procesor for the concurrent Work) (running is a flag)
* Do the concurrent pre-clean (uses one processor for the concurrent Work) (ready for cleanup)
* Stop all application threads; do the remark; resume all application threads (second pause, Mark, check)
* Do the concurrent sweep (uses one processor for the concurrent Work) (cleanup during running)
* Do the concurrent reset (uses one processor for the concurrent Work) (recovery)

To use incremental mode, you need to use the following variables:
-XX: + cmsincrementalmode default: Disabled start I-CMS mode (must-

XX: + useconcmarksweepgc)
-XX: + cmsincrementalpacing default: Disabled provides the automatic correction function.
-XX: cmsincrementaldutycycle = <n> default: 50 launch CMS
-XX: cmsincrementaldutycyclemin = <n> default: 10 start CMS deprecation
-XX: cmsincrementalsafetyfactor = <n> default: 10 is used to calculate the number of cycles.
-XX: cmsincrementaloffset = <n> default: 0 minimum number of cycles (this is the percentage (0-

(100) by which the incremental mode duty cycle is shifted to the right within the period

Between minor collections .)
-XX: cmsexpavgfactor = <n> default: 25 provides a number of guidance collections.

Sun recommends the following parameters:

-XX: + useconcmarksweepgc/
-XX: + cmsincrementalmode/
-XX: + cmsincrementalpacing/
-XX: cmsincrementaldutycyclemin = 0/
-XX: cmsincrementaldutycycle = 10/
-XX: + printgc details/
-XX: + printgctimestamps/
-XX:-traceclassunloading

NOTE: If throughput collector and concurrent low pause collector are used, these two garbage collectors must have a high memory size to prepare for multithreading.

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.