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

This article shows you how to carry out JVM garbage collection, the content is concise and easy to understand, can definitely brighten your eyes, through the detailed introduction of this article, I hope you can get something.

First of all, I'd like to introduce the 80-plus-20 rule here:

Only about 20% of the variables control 80% of the situation. In other words: of all the variables, only 20% is the most important, and although the remaining 80% is in the majority, the scope of control is much lower than the "critical minority".

The life cycle of Java objects also satisfies the same law, that is, most Java objects only survive for a short period of time, while a small number of Java objects survive for a long time.

Therefore, this has created the idea of generation-by-generation recycling in JVM. To put it simply, the heap space is divided into two generations, called the new generation and the old age. The new generation is used to store newly created objects. When the object lives long enough, it is moved to the old age.

This also allows JVM to use different recycling algorithms for different generations.

For the new generation, we guess that most of the Java objects only survive for a short period of time, then we can frequently use shorter time-consuming garbage collection algorithms, so that most of the garbage can be collected in the new generation.

For the old age, we speculate that most of the garbage has been recycled in the new generation, and there is a good chance that the objects in the old era will continue to survive. When it really triggers recycling for old times, it means that the assumption is wrong, or that the heap space has been exhausted. At this point, JVM often needs to do a full heap scan, regardless of cost. (of course, modern garbage collectors are developed on the road of concurrent collection to avoid this kind of full-heap scanning. )

So, let's first take a look at how the heap is divided in JVM.

Heap partition

According to the above, JVM divides the heap into the Cenozoic era and the old era, where the Cenozoic era is divided into Eden regions and two Survivor regions of the same size.

Generally speaking, when we call the new instruction, it delimits a block of memory in the Eden area as the storage object. Since the heap space is shared by threads, it is necessary to synchronize the space directly here. Otherwise, it is possible that two objects share a section of memory.

The solution of JVM is to apply for a continuous heap space for each thread in advance, and each thread is only allowed to create objects in the heap space they have applied for. If the applied heap space is used up, then continue to apply, that is, TLAB (Thread Local Allocation Buffer, corresponding to the virtual machine parameter-XX:+UseTLAB, enabled by default).

At this point, if a thread operation involves locking, the thread needs to maintain two pointers (which may actually be more, but only two important), one pointing to the starting position of the free memory in the TLAB and one to the end of the TLAB.

The next new instruction can be implemented directly through pointer addition (bump the pointer), that is, the pointer to the free memory location is added to the requested number of bytes.

If the value of the free memory pointer after addition is still less than or equal to the pointer to the end, the allocation is successful. Otherwise, there is not enough space for TLAB to satisfy this new operation. At this point, the current thread is required to reapply for a new TLAB.

Is it possible that the application is not available? Yes, Minor GC will be triggered at this time.

Minor GC

The so-called Minor GC means: > when the space in the Eden area runs out, JVM will conduct a Minor GC to collect the new generation of garbage. Objects that survive are sent to the Survivor area.

As mentioned above, there are two Survivor zones in the Cenozoic era, which are referred to by from and to respectively. Where the Survivior area pointed to by to is empty.

When Minor GC occurs, the surviving objects in the Eden area and the Survivor area pointed to by from are copied to the Survivor area pointed to by to, and then the from and to pointers are exchanged to ensure that the Survivor area pointed to by to is still empty the next time Minor GC occurs.

JVM records how many times each object in the Survivor area has been copied back and forth. If an object is replicated 15 times (corresponding to the virtual machine parameter-XX:+MaxTenuringThreshold), the object will be promoted (promote) to the old age.

In addition, if a single Survivor zone is already occupied by 50% (corresponding to the virtual machine parameter-XX:TargetSurvivorRatio), objects with higher replication times will also be promoted to the old age.

In a word, when Minor GC occurs, we apply the tag-copy algorithm to promote the old living objects in the Survivor area to the old age, and then copy the remaining living objects and the living objects in the Eden area to another Survivor area. Ideally, almost all the objects in the Eden area are dead, so there will be very little data to copy, so this mark-copy algorithm works extremely well.

Another benefit of Minor GC is that there is no need to garbage collect the entire heap. However, it has a problem, that is, objects in the old era may refer to objects of the new generation. In other words, when marking living objects, we need to scan objects from the old days. If the object has a reference to a new generation of objects, then the reference will also be used as a GC Roots. As a result, didn't you do another full-pile scan?

To avoid scanning the whole heap, JVM introduces a technology called card tables, which roughly marks areas of memory that may be referenced from the old to the new generation. Interested friends can learn about it in detail, but there is no specific introduction because of the limited space here.

Full GC

So when will Full GC happen? The trigger conditions for Full GC may not be the same for different garbage collectors. According to the implementation of HotSpot VM's serial GC, the trigger condition is:

> when preparing to trigger a Minor GC, if it is found that the average promotion size of the previous Minor GC is larger than the remaining space in the old years, the Minor GC will not be triggered but will instead trigger the Full GC. > > because in the GC of HotSpot VM, except for the garbage collector CMS, all other GC collects the entire heap at the same time, so there is no need to prepare a separate Minor GC in advance.

Garbage collection

There are three basic ways to recycle: clear, compress, and copy. Let's take a look at them one by one.

Clear

The so-called purge is to mark the memory occupied by the dead object as free memory and record it in a free list. When a new object is needed, the memory management module looks for free memory from the free list and allocates it to the new object.

The principle is very simple, but it has two disadvantages:

Can cause memory fragmentation. Because the objects in the JVM heap must be continuously distributed, there may be extreme cases where there is enough total free memory but cannot be allocated.

The efficiency of distribution is low. If it is a continuous piece of memory space, then we can use pointer addition (pointer bumping) to do the allocation. For the free list, JVM needs to access the items in the free list one by one to find the free memory that can be put into the new object.

Compress

The so-called compression is to gather the surviving objects at the beginning of the memory area, leaving a continuous memory space.

This approach can solve the problem of memory fragmentation, but at the cost of the performance cost of the compression algorithm, so the problem of allocation efficiency is still unsolved.

Copy

The so-called replication is to divide the memory area equally into two blocks, which are maintained by two pointers from and to, and only allocate memory by using the memory area pointed to by the from pointer. When garbage collection occurs, the surviving objects are copied to the memory area pointed to by the to pointer, and the contents of the from pointer and the to pointer are exchanged.

This recycling method can also solve the problem of memory fragmentation, but its disadvantage is also extremely obvious, that is, the use of heap space is extremely inefficient.

Specific garbage collector

There are three garbage collectors for the new generation: Serial, Parallel Scavenge and Parallel New. All three use the tag-copy algorithm.

Among them, Serial is a single-threaded, Parallel New can be seen as a multithreaded version of Serial, Parallel Scavenge is similar to Parallel New, but more focused on throughput. In addition, Parallel Scavenge cannot be used with CMS.

There are also three garbage collectors for the old days: Serial Old, Parallel Old and CMS.

Both Serial Old and Parallel Old are tag-compression algorithms. Similarly, the former is single-threaded, while the latter can be seen as a multithreaded version of the former.

CMS uses a mark-and-clear algorithm and is concurrent. Except for a few operations that require STW (Stop the world), it can be garbage collected while the application is running. In the event of a concurrent collection failure, JVM uses the other two compressed garbage collectors for a garbage collection. Due to the emergence of G1, CMS has been abandoned in Java 9.

G1 (Garbage First) is a garbage collector that spans the new generation and the old era. In fact, it has disrupted the previously mentioned heap structure and directly divided the heap into extremely many areas. Each area can act as an Eden zone, a Survivor zone, or one of the old days. It uses a tag-compression algorithm and, like CMS, can collect garbage concurrently while the application is running.

G1 can be garbage collected for each subdivided area. When selecting areas for garbage collection, it gives priority to areas with more dead objects. This is also the origin of the name G1.

It is mainly about the specific garbage collection method in JVM, which leads to the recovery method from the survival law of the object, combined with the characteristics of multi-thread, and gradually optimizes, resulting in all kinds of garbage collectors that we can know now.

The above content is how to carry out JVM garbage collection. Have you learned any knowledge or skills? If you want to learn more skills or enrich your knowledge reserve, you are welcome to 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.