JVM memory management------Exquisite explanation of GC algorithm (five minutes to completely understand the mark/clear algorithm)

What I am about to share with you below is the most basic algorithm in the GC algorithm------mark/clear algorithm. If you figure out this algorithm, the next two will be a piece of cake.
First of all, let’s recall the root search algorithm mentioned in the previous chapter. It can solve the problem of which objects we should recycle, but it obviously cannot bear the heavy responsibility of garbage collection, because we are in the program (the program refers to us If you want to perform garbage collection during the operation of a JAVA program running on the JVM, you must have the GC thread cooperate with the threads in the program so that the garbage can be successfully collected without affecting the running of the program.
In order to achieve this goal, the mark/clear algorithm came into being. What it does is that when the available memory space (available memory) in the heap is exhausted, it will stop the entire program (also called stop the world), and then perform two tasks, the first is marking, and the second The item is cleared.
Below, LZ will explain in detail what marking and clearing will do.
Marking: The process of marking is actually to traverse all GC Roots, and then mark all objects reachable by GC Roots as alive objects.
Clear: The cleaning process will traverse all objects in the heap and clear all unmarked objects.
In fact, these two steps are not particularly complicated and easy to understand. LZ explains the mark/clear algorithm in layman's terms. When the program is running, if the usable memory is exhausted, the GC thread will be triggered and the program will be suspended. Then the surviving objects will be marked again, and finally Clear all unmarked objects in the heap, and then let the program resume running.
Below, LZ has created a set of pictures for you to describe the above process. Combined with the pictures, let’s take a look at this process intuitively. The first picture is the first picture.

This picture represents the status of all objects during the running of the program. Their flag bits are all 0 (that is, unmarked. The default below is 0 which means unmarked and 1 (marked), assuming that the effective memory space is exhausted at this time, the JVM will stop the application and start the GC thread, and then start the marking work. According to the root search algorithm, after marking, the status of the object is as follows.

It can be seen that according to the root search algorithm, all objects reachable from the root object are marked as surviving objects. At this time, the first stage of marking has been completed. Next, the second stage of cleanup is performed. After the cleanup is completed, the remaining objects and their status are as shown in the figure below.

As you can see, unmarked objects will be recycled and cleared, while marked objects will remain and the mark bit will be reset to 0. Needless to say, just wake up the stopped program thread and let the program continue running.

In fact, this process is not complicated, it can even be said to be very simple. Are you right? However, there is one point worth mentioning, that is, why do we have to stop the running of the program?
This is actually not difficult to understand. LZ will give the simplest example. Assume that our program and the GC thread run together. Just imagine such a scenario.
Suppose we have just marked the rightmost object in the picture, let's call it A for the time being. As a result, a new object B is created in the program at this time, and the A object can reach the B object. However, since the A object has been marked at this time, the mark bit of the B object is still 0 because it missed the marking stage. Therefore, when it is the next turn to clear the phase, the new object B will be cleared hard. As a result, it is not difficult to imagine the result. The GC thread will cause the program to not work properly.
The above result is of course unacceptable. We just created a new object, and after a GC, it suddenly became null. How can we do this?

So far, the mark/clear algorithm LZ has been introduced. Let’s take a look at its shortcomings. In fact, after understanding its algorithm principle, its shortcomings are easy to understand.
1. First of all, its disadvantage is that its efficiency is relatively low (recursion and full heap object traversal), and when performing GC, the application needs to be stopped, which will lead to a very poor user experience, especially for interactive applications. It's simply unacceptable. Just imagine, if you are playing on a website and the site is down for five minutes an hour, would you still play?
2. The second main disadvantage is that the free memory cleared in this way is discontinuous. This is not difficult to understand. Our dead objects appear randomly in every corner of the memory. Now After clearing them, the memory layout will naturally be messy. In order to cope with this, the JVM has to maintain a free list of memory, which is another overhead. Moreover, when allocating array objects, it will be difficult to find continuous memory space.
After reading its shortcomings, some ape friends may not be able to help but vomit, "So this algorithm is basically useless, then why does LZ introduce such a thing?"
Ape friends, don't do it. Worry, if an algorithm has shortcomings, experts will naturally try their best to improve it. The two algorithms we are going to introduce next are both optimized based on the mark/clear algorithm. LZ will share the specific content with you next time.
This sharing ends here. I hope you can gain something from reading it, 0.0.

The above is the content of JVM memory management------GC algorithm refinement (five minutes for you to fully understand the mark/clear algorithm). For more related content, please pay attention to the PHP Chinese website (www.php. cn)!