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

This article will explain in detail how to analyze the garbage collection mechanism in Java performance optimization. The content of the article is of high quality, so the editor shares it for you as a reference. I hope you will have some understanding of the relevant knowledge after reading this article.

Memory space for ★ JVM

In the Java virtual machine specification, the following types of memory space are mentioned:

◇ stack memory (Stack): private per thread.

◇ heap memory (Heap): common to all threads.

◇ method area (Method Area): a bit like the "process code snippet", which stores the reflection information of each loaded class, the code of the class function, the compile-time constant, and so on.

◇ Native method Stack (Native Method Stack): it is mainly used for native code in JNI and is rarely involved. Brief introduction of ★ garbage collection mechanism

In fact, the Java virtual machine specification does not specify the details of garbage collection. How to do garbage collection depends entirely on the designers of each JVM. Therefore, the behavior of GC may vary from JVM to GC. Next, let's take the official JVM of SUN to briefly introduce the mechanism of GC.

When does ◇ carry out garbage collection?

In general, when JVM finds that heap memory is tight and insufficient, it starts garbage collection. But we have to recognize such a cruel fact: the timing of JVM GC can not be accurately predicted. Because the start-up time of GC will be affected by a variety of operating environment factors, the randomness is too great.

Although we can not accurately predict, but if you want to know the implementation of each garbage collection, it is quite convenient. The relevant information can be printed out through the command line argument "- XX:+PrintGC" of JVM.

In addition, the call to System.gc () only advises JVM to GC. As for whether JVM will actually do it, only God knows. Therefore, it is generally not recommended that you call System.gc () manually, or it is better to let JVM decide. In addition, you can disable System.gc () by using the JVM command-line argument "- XX:+DisableExplicitGC".

◇, who is in charge of garbage collection?

In general, JVM has one or more dedicated garbage collection threads that are responsible for cleaning up garbage collection memory.

How does ◇ find junk objects?

The garbage collection thread traverses object references starting with the "Root Set". The so-called "root set" is the collection of [reference variables] that can be accessed in the running thread (such as the parameters and local variables of the current function of all threads, the member variables of the current class, etc.). The garbage collection thread first finds all the objects directly referenced by the root set (call it set 1), then finds all the objects directly referenced by set 1 (call it set 2), and then finds all the objects directly referenced by set 2. This cycle goes on and on until all the objects that can be traversed have been traversed.

All objects that can be reached from the "root set" through the above traversal are called reachable objects or valid objects; otherwise, they are unreachable or invalid objects (that is, garbage).

How does ◇ clean / recycle garbage?

Through the above stage, we will find out all the garbage objects. The garbage collection thread then performs corresponding cleaning and recycling work, including remaking garbage memory into available memory, destructing memory to remove memory fragmentation, and so on. This process will involve a number of algorithms, so we won't talk in depth because of the limited space.

◇ generation

Early JVM did not use generational technology, and all objects managed by GC were stored in the same heap. The disadvantage of doing this is obvious: every time you GC, you have to traverse all the objects, which is very expensive. In fact, the life cycle of most objects is very short (short-lived objects), and only a few objects have a long life; among these short-lived objects, only a few objects occupy a large amount of memory space; a large number of other short-lived objects belong to small objects (very consistent with the 28 principle).

With this in mind, JVM has been using generational garbage collection (Generational Garbage Collection) since JDK 1.2. JVM divides GC-related memory into "Tenured" and "Nursery" and "Permanent" (corresponding to the "method area" of the JVM specification). [most] objects are in the "younger generation" when they are first created. If an object is still alive after several rounds of GC (older object), move it to the "older generation". In addition, if an object is large when it is created, it may be thrown directly to the older generation. Through this strategy, the younger generation always keeps those short-lived objects. In terms of space size, the "young generation" is relatively small, while the "old generation" is relatively large.

Because of the generational technology, the GC of JVM is divided into two types-primary collection (Major Collection) and secondary collection (Minor Collection). "primary collection" cleans up both the older generation and the younger generation, so it is very expensive and not often carried out; "secondary collection" only cleans up the younger generation, with little overhead and often.

What is the impact of ★ GC on performance?

I just introduced the general principle of GC. What is the impact of GC on performance? There are mainly the following aspects:

◇ causes the current running thread to pause

The early GC was mentally retarded. While it is working, all other threads are paused (so as not to affect garbage collection). Wait until GC finishes its work before other threads continue to run. Therefore, once the GC of the early JDK starts to work, the whole program will fall into a state of suspended animation and lose all kinds of responses.

After years of technical improvements (including the adoption of generational technology), GC has been shrewd since JDK 1.4. While it is working, it only occasionally pauses the operation of other threads (from a long period of suspended death to temporary shock).

The cost of ◇ traversing object references

Imagine that if there are a lot of objects in JVM, it must be a lot of work to traverse all the reachable objects, which is a lot of overhead.

The cost of cleaning and recycling garbage by ◇

After traversing object references, there is also a lot of overhead for garbage cleaning and collection. This overhead may include copying memory blocks, updating object references, and so on.

Two performance Indexes of ★ Collector ◇

Because we are talking about performance today, we are bound to mention two important metrics that measure GC performance: throughput (Throughput) and pause time (Pause Time). The term throughput is not very intuitive, explain it: it is the ratio of JVM [not used] GC time to total time. "Throughput" is the larger the better, and the "pause time" is the smaller the better.

Different applications pay different attention to these two indicators (as we will say later), that is, the so-called "difficult to tune". In order to cater to the audience, many JVM manufacturers have to provide a variety of garbage collectors for users to choose from. Different collectors adopt different collection strategies, which are described in detail below.

◇ serial collector (Serial Collector)

Specify using the command line option "- XX:+UseSerialGC".

This kind of collector is the most traditional collector. It uses a single thread for garbage collection, which is suitable for "single CPU machines". In addition, serial collectors can be used for small applications or if there are no special requirements for the above two indicators.

◇ parallel Collector (Parallel Throughput Collector)

As the name implies, this collector uses multiple threads for garbage collection to achieve high throughput. The number of garbage collection threads is specified by the command line option "- XX:ParallelGCThreads=n". You can set this value to take full advantage of Multi-CPU or Multi-Core.

When using the command line option "- XX:+UseParallelGC": it uses multiple garbage collection threads for the younger generation and a single thread serial mode for the older generation. This option was first introduced in JDK 1.5.

When using the command line option "- XX:+UseParallelOldGC": it is targeted at the way that both the younger and the older generations use multiple garbage collection threads. However, this option has only been introduced since JDK 1.6.

◇ concurrent collector (Concurrent Low Pause Collector)

Specify using the command line option "- XX:+UseConcMarkSweepGC".

This collector gives priority to ensuring the response of the program. It tries to keep the garbage collection thread and the application's own thread running at the same time, thus reducing the pause time. This option is supported since JDK 1.4.1.

◇ incremental Collector (Incremental Collector)

Since JDK 1.4.2, SUN officials have stopped maintaining the collector. So I saved some saliva and said no more.

How does ★ reduce the impact of GC? ◇ minimizes the use of heap memory

Because GC is for objects stored in heap memory. If we reduce the allocation of reference objects in the program (that is, reduce the heap memory allocation accordingly), it will be very helpful to improve the performance of GC. The last "string filtering practice" post gave an example of how to improve performance by reducing the number of heap memory allocations.

◇ sets the appropriate heap memory size

JVM's heap memory is fastidious, neither too big nor too small. If the heap memory is too small, JVM always feels that there is not enough memory, which may lead to frequent garbage collection and affect performance; if the heap memory is so large that most of the physical memory of the operating system is occupied by JVM itself, it may affect the performance of other applications and even the operating system itself.

In addition, the size of the young generation (or the ratio of the "young generation" to the "old generation") also has a significant impact on the performance of the GC. If the younger generation is too small, it may lead to frequent secondary collection; if the younger generation is too large, the pause in secondary collection is obvious.

JVM provides several command line options related to heap memory size, as follows:

--

-Xms sets the initial heap memory

-Xmx sets the maximum heap memory

-Xmn sets the size of the younger generation

-XX:NewRatio=n sets the ratio of younger generation to older generation to "n"

-XX:NewSize=n sets the size of the younger generation to "n"

--

In general, the default parameter values for JVM are sufficient. So don't use the above options easily. If you have to adjust, be sure to do an in-depth performance comparison test to ensure that the adjusted performance is indeed better than the default parameter value.

Trade-off between ◇ throughput and pause

As mentioned earlier, it is difficult to adjust the mouths of different applications. There are two common flavors: (1) focus on throughput rather than pause time, and (2) focus on pause time.

For some simple computing-intensive applications in the background, it belongs to the first kind. For example, the application of some scientific computing. Parallel collectors are recommended at this time.

For those involving user UI interaction, the real-time requirements are relatively high, and the program needs to respond quickly, it belongs to the second kind. For example, some desktop games, some telecommunications switching systems. It is recommended to use a concurrent collector at this time.

On how to analyze the garbage collection mechanism in Java performance optimization is shared here, I hope the above content can be of some help to you, can learn more knowledge. If you think the article is good, you can share it for more people to see.

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.