Java garbage collection mechanism

Problem? Java garbage collection mechanism

1. Sorting of fragments

Know that Java objects, after recycling, will form fragments, and then how is it recycled and organized?

Then the next write operation becomes more time consuming, because finding the next available free block is no longer a simple operation.

When the JVM creates a new object, it allocates memory in contiguous chunks. Therefore, if the fragment is already serious enough that no free block is sufficient to accommodate the newly created object, memory allocation will be an error.

To avoid this situation, the JVM needs to ensure that fragmentation is within the controllable range. Therefore, in the process of garbage collection, in addition to marking and deletion, there is a "memory to fragment" process, and finally the existence of the space close up, so that the speed of the search is not accelerated.

Generational assumptions

The more objects you have, the longer it takes to recycle. So can we recycle on smaller areas of memory?

2. The vast majority of memory allocations in applications fall into two main categories:
Most of the objects will soon become unavailable.
Still others, their survival time is usually not very long.

In order to solve
Final conclusion: The weak generational hypothesis (Weak generational hypothesis) is formed. Based on this assumption, the memory within the virtual machine is divided into two categories, the new generation (young Generation) and the Laosheng (old Generation). The latter is also known as the old generation (tenured Generation).

this solves the problem of garbage collection in the Cenozoic and Laosheng generation areas. with separate, cleared areas, there are a number of different recovery algorithms that have been continuously improving the performance of GC.

But this time, the new problem comes up again? Objects in different generations may have references to each other, and they are considered to be "de facto" GC root objects (GC roots) when generational collections are made. The JVM feels powerless about this moderate life-cycle object . Because it is not good to recycle garbage Ah!


Don't be afraid, the JVM has a trick, and that's the card tag . First understand the concept of the introduction

3. Eden District (Eden)

When new objects are created, they are usually assigned to the Eden area. Since there is usually more than one thread allocating a large number of objects at the same time, the Eden area is further divided into one or more thread local allocation buffers (thread local Allocation buffer, referred to as Tlab). With these buffers, the allocation of most objects in the JVM can be done in the respective tlab of each thread, thus avoiding costly synchronization overhead between threads.
Allocations cannot be completed in Tlab (usually because there is not enough space) and will be allocated to the space in the Eden area. If there is still not enough space, a new generation of garbage collection is triggered to free up space. If the Eden area does not have enough space after the garbage collection, then the object will be allocated to the Laosheng generation.

Draw a process diagram here:

When the Eden Zone is reclaimed, the garbage collector begins to traverse all the accessible objects from the root object (that is , the Reference object) and marks them as alive . Eden District when the object is checked, the object that references the Laosheng generation is marked as a " dirty " object.

When all objects are checked, all surviving objects are copied to a surviving area, so the Eden area at this time can be considered empty and assignable, a process called " tag Replication ". The surviving objects are first labeled and then copied to the Survival Zone (Survivor) .

Learn what the JVM does with garbage, and add the concept of Survival Zone (survivor) .
Next to Eden is two surviving areas, from and to, one of which is always empty (from), and think about why?

The empty active area, at the time of the next new object generation, ushered in a batch of objects (when garbage collection started). Eventually, the entire new generation of objects is tagged to the to survival area, and the surviving objects will continue to replicate back and forth between the two surviving areas until some of them are considered ripe. That is, mature enough to become an old object, these old objects will be promoted to Laosheng generation space, will not be copied to another active area (it is needed for a period of time), until it is not referenced, garbage collection mechanism is recycled.

When an object is older than a certain age threshold, it will be promoted to the old age, so what is the time limit:

The JVM dynamically adjusts the actual age threshold value , but by specifying

The -xx:+maxtenuringthreshold parameter can set an upper limit for the value.

Setting -xx:+maxtenuringthreshold to 0 immediately triggers an object promotion without copying to the survival area.

In modern JVMs, this value is set to 15 GC cycles by default. This is also the upper limit for this value in the Hotspot virtual machine.

If the surviving area is not large enough to supply, the JVM will start early. Object elevation ******

4. Laosheng generation

The implementation of the memory space of the Laosheng generation is more complex. The space in the Laosheng generation is usually very large, and the objects stored in it are unlikely to be recycled. The GC of the Laosheng generation is much less frequent than that of the new generation GC. Since most of the objects in the Laosheng generation are considered to be alive, there is no tag-copy operation. In the GC, these objects are moved together to reduce fragmentation. The recovery algorithm of Laosheng generation is usually constructed according to different theories, which is different from the new generation of recovery algorithm.

However, you will experience the following steps:

(1) Mark the object, set the GC root object can reach all objects after the mark bit
(2) Delete unreachable objects
(3) the object of Laosheng generation space is organized, and the surviving object is copied into the continuous space starting from the Laosheng generation.

5. Persistent generation

The persistent generation is the space before the JVM8, mainly for the string, metadata such as the place where the class-related data is stored. In addition, a string like a resident (internalized string) is stored in a persistent generation, but is cumbersome for developers because it is not possible to predict how much space it needs to control. So there is no lasting space for the JVM8 generation.

An exception to the Java.lang.OutOfMemoryError:Permgen space will be thrown when the evaluation is not in place. As long as the outofmemoryerror exception is not really due to a memory leak, you can solve this problem by increasing the size of the persistent generation space, for example, in the following example, the maximum space for the persistent generation is set to 256MB:

java-xx:maxpermsize=256m com.mycompany.MyApplication

6. Meta-space:

Because the long-term space for the programmer is Jinan control and prediction, so after the JVM8, the permanent generation removed, thereby introducing the meta-space, from now on what assorted things are put into the heap to use.

7. The size of the meta-space is limited only by the size of the available local memory of the Java process, and they are no longer raised by adding a class more
Java.lang.OutOfMemoryError:Permgen space is out of the ordinary. Although there seems to be no limit to the size of the meta-space, these are not
There is no price that you may face is frequent memory swapping (swapping) or local memory allocation failure.
To avoid such cases, you can set the size of the meta-space:

java-xx:maxmetaspacesize=256m com.mycompany.MyApplication




The New Generation GC (Minor GC) vs Laosheng GC (Major GC) vs full GC, but they are not very different, but to understand



1. The recovery of new generation garbage is called minor GC, there are some places to be aware of when using the next generation garbage collection, as long as the JVM is unable to allocate space for newly created objects, it will certainly trigger the Cenozoic GC, for example, the Eden area is full. As a result, the more frequently objects are created, the new generation of GC is certainly more frequent. As long as the JVM cannot allocate space for newly created objects, it will certainly trigger a new generation of GC, for example, the Eden area is full. As a result, the more frequently objects are created, the new generation of GC is certainly more frequent.

Once the memory pool is full, all of its contents are copied away, and the pointer is re-zeroed. So unlike the classic mark (Mark), Clear (Sweep), finishing (Compact) process, the cleanup of the Eden and survivor areas only involves tagging and copying. There is no fragmentation in them. The write pointer is always at the top of the current usage area.
In a new generation of GC events, older generations are usually not involved. The reference to the old generation to the young generation is considered to be the root object of the GC. In the tagging phase, references from younger generations to older generations are ignored.
Unlike what is generally understood, all new generation GC triggers a "Stop-the-world" pause, which interrupts the application's thread. For most applications, the time to pause is negligible. This is reasonable if most of the objects in the Eden area are garbage objects and will never be copied to the Survivor/Old generation. If the opposite is true, then the vast majority of new objects should not be recycled, and the time of generation of GC pauses will be relatively long.
Now the new generation of GC is still clear-every new generation GC will be garbage removal for younger generations.


Old age GC and full GC
You will find that there is no clear definition of these two types of GC. Not mentioned in the JVM specification or garbage collection related papers. But intuitively, according to the New generation GC (Minor GC) cleanup is the new generation of space, it is not difficult to draw the following inference (here should be understood from the English, Minor, Major and full GC, translated by the name has been clearly interpreted):


The Major GC cleans up the space of the old age.
Full GC cleans up the entire heap--including the new generation and the old age space
Unfortunately, this understanding is a bit complicated and confusing. First-many of the older GCs are actually triggered by the new generation of GC, so in many cases they cannot be seen in isolation. On the other hand-many modern garbage collector will partially clean up the old age, so using the term "clean up" seems a bit farfetched.


So the question is, let's not dwell on whether a GC is an old GC or full GC, and you should be concerned if the GC interrupts the application thread or executes concurrently with the application thread.

Java garbage collection mechanism