Java GC-Garbage collection mechanism

1. Introduction

For Java developer, understanding how the JVM GC Works can help us develop better applications while being more free when dealing with JVM bottlenecks. The benefits of this knowledge have been realized in the last year of application development and have allowed our applications to work well in larger concurrency.

This part of the knowledge and image comes from the book Java performance-Charlie Hunt & Binu John, which comprehensively explains the performance analysis of Java applications, the optimization of points and the principles of the JVM, and this article (and some later articles) contains only GC Co Llector part of the knowledge, but also only for the common hotspot JVM, of course, a lot of knowledge is interlinked.

2. JVM Overview

As a skeleton of the JVM, it is mainly divided into VM Runtime, GC collector and JIT Compiler, where we can configure the intervention only by GC and JIT (through-server and-client choose different JIT Compiler, where-ser Ver has better performance after start-up, but it takes a little longer to start-though we don't feel it clearly.

is the memory partitioning model in the JVM, which is divided into the Heap area, the method area, the VM stack, the native method stack, and the PC register.

This article focuses only on the heap area and Method area covered by GC collector, as well as other information available.

3, Garbage collections

In GC, the most "fascinating" is "Stop-the-world", which will appear in the currently implemented GC algorithm, which appears when the JVM hosts the application will stop executing, which means that all threads in our app will stop responding until "Stop-the-world "Finish the work.

The HotSpot VM divides the Heap area into two physical areas of young generation and old generation, which we often translate into: younger generations and older generations. They have the following characteristics:

1. Young generation: Most of the objects are allocated here, usually for smaller but more frequent recoveries, which take less time.

2. older generation: The memory is relatively large, the object will be relatively reserved for a long time, large objects are also generally allocated here, the Occupy space rises slowly and the recovery frequency is low, "Stop-the-world" will take place when it recycles, take a longer time.

For example, objects are allocated in younger generations and may be moved to older generations after some time. The permanent generation is a persistent zone, which mainly stores metadata such as class data structures, interned strings and other information. The GC focuses on the recovery of Young Gen and Old Gen.

3.1 Young generation

Young generation is subdivided into Eden and 2 survivor spaces (i.e., surviving areas) such as:

1. The Eden: Most of the new objects are allocated here, and some large objects are allocated directly in the old quarter, which in many cases becomes empty after the area is reclaimed.

2. The two survivor spaces: When the Eden zone is full, the surviving objects will be copied to one of the survivor areas, and when the area is full, it will be copied to another survivor area, such as:

3.2 Garbage Collectors

HotSpot currently has three types of available recyclers: Serial GC, Parallel GC , and Concurrent Mark-sweep (CMS GC), and the recycling type is divided into C8>mirror GC and Major GC (also called full GC), Mirror GC for young Generation,major GC for old generation.

Note: The garbage collection and memory allocations used by the query app use: jmap-heap [PID], where the PID is the process ID, and a later article may have an example.

3.2.1 Serial GC

This collector is used when the Java application is started (if it is not specified to determine whether to use-server or-client according to the official judging method (such as CPU cores, memory size, etc.), and if the -client parameter is added, please check the official information for details. In the current hardware configuration, specifying-server is required for most scenarios.

The collector is characterized by single-threaded recovery (which is rarely selected in this multicore ERA), and Mirro GC and major GC are required to pause the application (i.e. Stop-the-world)

Such as:

3.2.2 Parallel GC

In the Parallel GC, both the minor and full GC are parallel and can be used for multi-core parallel recycling, specifying how many threads to use, improving application throughput, and in general machine configurations, if the GC collector used is not specified, the default is Parallel GC, which conforms to most scenarios . Such as:

3.2.3 CMS GC

The appearance of the collector is primarily to address low-response latency scenarios where, once stop-the-world occurs, the application will stop responding until it is done, which is especially critical in many web, telecom, or banking applications. Although major GC rarely occurs, it can take a long time to occur, especially when the heap is large (that is , why we cannot allocate the heap for a large reason, as appropriate, to effectively disperse GC pauses so that it does not lag significantly ).

The CMS GC is designed to reduce the response time of the application (but at the expense of some throughput), and because of the extended GC work cycle, there is a larger heap requirement (which is still allowed to allocate memory during the marking pause phase), which has a more complex algorithm, and the CMS GC manages young The generation aspect is the same as the Serial/parallel GC (specified by the parameters, in a later article will be explained in detail), in the management of the old generation with 2 cycles to recover to reduce the application pause time, such as:

The approximate action description is divided into:

1. Initial mark, mark all objects that are directly reachable outside old generation (such as static objects, line stacks, and so on).

2. Concurrent marking phase, which marks all reachable (direct or indirect) surviving objects at this stage, the application does not need to stop at this stage, the tagging thread and the application thread work simultaneously.

3. Concurrent pre-cleaning to alleviate the work of the remark pause step, such as accessing references that were changed during the making phase phase, although remark pause would still do the work, However, it can significantly reduce the duration of remark pause.

4. Remark Pause, since the application will constantly update the reference, it is still necessary to pause the application to completely mark it, this step recheck the previous step (Concurrent marking phase) to the time period to suspend the update of the reference.

5. Concurrent Sweeping phase, this step already knows all the objects that survived in old generation, will rearrange the memory and release the unreachable objects (as shown in B), and after releasing the free space is identified, but they are discontinuous ( Serial and parallel GC use a compression method), so will cause the allocation of memory in the old generation expensive. The marking pause phase guarantees that the tag will survive at this stage, but there is no guarantee that all unreachable objects can be cleaned up, and the next full GC is recycled if the collection cannot be cleaned up.

Finally, the memory fragmentation problem: Due to the lack of memory compression will make memory fragmentation, CMS provides compression cycle, this cycle is also the Stop the world, and serial, parallel GC similar. Using the-xx:cmsfullgcsbeforecompaction parameter to specify how many times the full GC is compressed, the default is 0, which can typically be set to 1, and later in the article there will be a detailed description of the relevant GC parameters.

3.2.4 the Garbage-first GC

G1 GC Future will be an alternative to the CMS GC (in Java 6 Update, or later and Java 7), it can specify the GC caused by the application stop time, there are different memory distribution, improve the application real-time, but the GC has not been validated by a large number of production environments, currently only Used as an experimental feature.

4. Summary

JVM tuning is mainly at 3 points:

1. Select the appropriate GC collector.

2. Specify the appropriate heap area size.

3. Specify the ratio (or size) of young generation, which affects how often the full GC occurs and when the app is paused.

Java GC-Garbage collection mechanism