Shulou(Shulou.com)05/31 Report--

This article analyzes "how to analyze golang garbage collection". The content is detailed and easy to understand. Friends who are interested in "how to analyze golang garbage collection" can follow the editor's idea to read it slowly and deeply. I hope it will be helpful to you after reading. Let's learn more about "how to analyze golang garbage collection" with the editor.

Overview

Modern programming languages generally have garbage collection functions. This can greatly reduce the burden on programmers and reduce the problems in most scenarios. You know, the most common problems in c language are memory trampling, memory leaks, wild pointers and so on. Golang as a new language, natural garbage collection function is indispensable. The current golang garbage collection is based on the theory of tricolor tagging, and through the reasonable use of memory barrier technology, the garbage collection stw is almost eliminated (narrator: this correct understanding, it is not without stw, it is just very short).

GC & RC

First of all, there are two ways to manage a little more advanced memory. Learn about two nouns:

GC: how garbage collection manages memory RC: how reference counting manages memory

Due to the problem of the design of the c language itself, it is impossible to implement GC, so how does the c program manage memory? Reference counting is the most commonly used and more advanced form of management. How to use reference count? The common postures are as follows:

In order to protect the object from being destroyed before use, obj_ref (obj) can be safely destroyed after counting + 1, counting-1, and reducing the count to 0; {do_something;} obj_unref (obj)

The use of reference counting RC looks very simple, but it is actually very fastidious, so I won't go any further here. Here, it is also carried out by golang's garbage collection.

Golang garbage collection we often hear trichromatic labeling, tricolor refers to white, gray, black, respectively represents three states, as for the theory of tricolor labeling is not shown here, we start from a simple understanding.

The origin of garbage collection

First of all, let's think about the next question we don't need to think about: what does garbage collection do? Why does golang need garbage collection?

C programs need memory to run, stack memory is managed by compilers, and heap memory is managed by programmers. This is the source of memory problems in c programs. Programmers are people, and people can make mistakes. The quality of all kinds of programmers is also uneven, and the actual scene is also intertwined with various complex situations.

So, when we go back to the source problem, we essentially just want a memory, and we just have to manage it. When the memory is used up, the programmer had better ignore it. Programmers only work, not recycling. This will be the origin of garbage recycling.

The Origin of Escape Analysis

If we go further, the c program still needs the programmer to decide whether to allocate memory from the stack or from the heap?

So is this something programmers have to do? No, in essence, the program just needs an object, and it is a last resort to decide this matter.

Golang solves this problem, which is the corresponding "escape analysis". Escape analysis solves a problem: on the premise of ensuring the correctness of the golang program, determine the allocation location of objects in the compilation phase, on the stack? On the pile?

Garbage collection, how to achieve?

Bottom line: golang only needs to guarantee a point, recycling must be unused garbage, then there will be no functional problems, recycling is slow to a certain extent ok.

What kind of garbage is it?

How to ensure that the recycling must be garbage? First of all, look at a picture:

Let's start with the conclusion:

The yellow one on the picture is rubbish, which can be seen at a glance. No one uses it, but it's just rubbish. How to find the trash?

Now the key question is: how did you find this yellow block?

To put it another way: you find out what you are using, and the rest is rubbish that is not in use. What is in use? Starting from all the roots, it is considered to be in use as long as it is covered by a reference.

Method: scan from the root, scan all the roots, and scan each root to the end. According to the previous tricolor marks, what is scanned is black, what is being scanned is gray, and what is not scanned is white. When the root is scanned, there will be only two colors left, black and white. White is useless rubbish, this kind of cleaning up will be fine.

Ask two questions:

So what's the root? Where is the reclaimed memory?

Answer:

The stack is the root, the starting point of scanning, and some global variables are also roots, the so-called garbage is only for the memory on the heap, the memory on the stack is managed by the compiler, the memory on the heap is allocated for business, and the garbage collector collects it.

Here's another key point: how can scanning be safe?

The simplest way of thinking, I let the world stop (stw), no one move, wait for me to find out the garbage, you run your program. It's safe now.

Needless to say, that's what golang 1. 0 does. This kind of implementation is very simple and easy to understand, but it does not apply to the production environment. As soon as you stop the whole program, you have to pause the business for a few seconds, so the previous golang simply cannot be used.

So, in order to be able to produce scenarios online, not just a toy, garbage collection must not affect the running of the business code. That is, concurrency (narrator: no concurrency is fine, as long as you can think of a good way to do it: can recycle garbage without affecting the business)? Simple concurrency has issues to consider, starting with examples of insecurity (scanning and business concurrency):

Initial scene:

Business and scan concurrency:

The final result:

The white one is to be recycled, but we can see at a glance that a white one is referenced, the recycling will be wild pointer, and it will collapse when recycled.

Memory barrier

How to solve this problem? Next comes the memory barrier. The golang memory barrier also has an evolution:

Insert write barrier mixed write barrier (insert write barrier + delete write barrier)

Let's start with the nature of the barrier:

The memory barrier is just a special piece of code that generates a memory barrier during compilation, which essentially intercepts memory writes at run time, which is equivalent to a hook call.

Function of the barrier:

Through the write operation time of hook memory, to prevent some things from happening, or to do some marking work, so as to ensure the correctness of garbage collection. This is how to analyze golang garbage collection. I hope the above content can improve everyone. If you want to learn more knowledge, please pay more attention to the editor's updates. Thank you for following the website!

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.