Re-learn. Net [6]-garbage collection and resource management [1]

I have always felt that resource management in C ++ is very painful. I have to read a lot of empirical manuals to ensure good management of memory and other resources. In contrast,. Net (CLR) introduces the garbage collection mechanism (GC) to recycle managed heap resources, which undoubtedly reduces the burden on developers. However, there is no free lunch in the world. If you want to know the operation of GC clearly, you should have a good grasp of resource management (especially when it comes to unmanaged resources ), it is not easy for people like me who have no breakthrough in AI.
Well. Let's take a look at the Resource Management Mechanism of CLR. First, let's look at the CLR's memory (managed heap) allocation. The simplest statement is that the managed heap is allocated by a continuous block. Specifically, the managed heap allocates the block starting with the empty heap and points it to the beginning of the new empty heap. The method is similar to stack allocation. If the managed heap only has such a allocation process, its speed will undoubtedly be terrible. Net programmers are also so happy. Unfortunately, the memory is limited and GC must be started at the right time to recycle invalid objects (that is, no one uses them.
GC's collection of managed heap memory is a complex process. In one sentence, GC is started every time, and a part of rootless objects will be recycled. A rootless object is an object that can be used again without variables in the current execution domain. For example:
Object A = new object ();
A = NULL;
At this time, when initializing a, the new object becomes a rootless object, which is a recyclable object. Does GC know what a rootless object is? Well, in most cases, we need to trust our comrades and believe that it will not leak a rootless object or take a rootless object as a rootless object. Let's take a look at the recycling algorithm. This will be a bit complicated. In short, the GC collection algorithm is based on the assumption that the new object has a short lifetime (this assumption is very reliable. Consider the code we wrote to understand it, code on the outermost layer is always used for a long time, and the variables in a for are often discarded when they are used ). Therefore, it preferentially recycles memory occupied by new objects. More specifically, it uses a recycling algorithm called the aging algorithm. By default, all objects in the heap are divided into three age generations: 0, 1, and 2. The older the object, the more likely it will be to be used, the zero generation will be allocated. The total space of each aging object has a threshold value. CLR dynamically adjusts the Threshold Value Based on GC execution. When the space occupied by the 0th generation object exceeds the threshold, GC starts to recycle the memory. First, The 0th generation of space is reclaimed, and then the 0th generation is upgraded to the 1st generation, if the first generation is full, 1 will be recycled (otherwise it will end). So on (I also have a question: What should I do if the second generation is full, whether to expand in time or expand in the middle of the virtual memory ). Of course, this is a simple description. Many factors may be considered in the algorithm and a series of optimization measures may be taken, these details do not need to be understood by most people (I can't understand them either ). From this algorithm, we can also see that the GC mechanism is particularly suitable for the scenarios where a large number of temporary objects are created and all are destroyed. Therefore, GC has outstanding performance in Asp.net.
The above describes a macro process that considers how managed stacks are allocated and recycled as a whole. Let's further consider the allocation and recycling of a specific object. Assume that this object is named faint (^_^ ). First, the faint is allocated in the managed heap. At this time, it is a generation 0. Unfortunately, when faint has not been upgraded to the first generation, it is discarded and becomes a rootless object. At this time, the GC boss collected the memory, and faint certainly did not escape the boss's sharp eyes. The critical moment is approaching. The old Conference asked it a matter of life and death (not real-time judgment, but saved in advance using a structure). Is your Finalize method the original object. finalize () (sorry, It's so disgusting. Finalize is a method called when the object is recycled. It has a default implementation in the object class. If one of the faint's ancestors overrides the Finalize method, this method is not an existing object. finalize method). If yes, it will be killed on the spot and no longer exist. If not, the faint will still be put in the heap, it will be killed at the next GC startup (early death and late death ). The story is not well written. It should be emphasized that if a class is overloaded with the Finalize method in the inherited structure, it will not be recycled after two GC starts. Understanding this situation will often pave the way for your epiphany.
Another question is, when will CLR start GC? How can I ensure that the memory allocation status will not change during GC operation? The policy adopted by CLR is to hijack the current thread and start the garbage collection thread at the appropriate time (called the security point). At this time, all other threads are suspended and wait until the collection is completed. There is no doubt that Microsoft will continue to work hard to reduce this kind of overhead when there is a huge performance loss. At least it will not feel this kind of overhead in general use. In addition, not only does GC recycle the memory (that is, call the finalize function), but when the CLR uninstalls the appdomain or closes the CLR, the CLR also traverses the finalize function of all objects, to reclaim all memory space.
After reading this for a long time, we found that this was all done by the system. The system automatically allocates memory, automatically judges rootless objects, automatically starts GC, and automatically calls the recycle algorithm. Can we change it? Yes, of course. You can change the aging threshold (if you haven't played it, it seems OK). The most common thing is to call GC. collect () requires that GC be started to reclaim memory (sometimes two GC calls are required. collect (), think about why, the answer is above Oh ^_^), of course, many times it is not recommended to do this, because it will bring performance loss. Unless you do need to recycle large memory and perform a very time-consuming task at this time, the GC time can be well masked (consider a very modest mm, what will happen to the XX Film and Television College and XX Science and Technology School? =. = !!, Haha, a joke ).
Garbage collection is not just a simple process. There is also a lot of content such as weak type and burst garbage collection. If you are interested, you can read the description of related content in the. NET Framework programming. It may take a bit of patience, but it will definitely benefit a lot.
How can these processes be used by General developers? At least you can be comforted by knowing how your new things are sacrificed. Haha, of course there are other benefits. For example, I have clearly written code similar to faint = NULL, so that the meaning of the Code is gone. This is to help the system make it clear that my object has no root and can be recycled (you don't have to wait to jump out of the valid domain ). In addition, I won't confuse GC. Collect () to tease CLR. In addition, it may be helpful to understand the management of other unmanaged resources later.

PS: writing so much energy is exhausted, so we can only split it up and down. The recycling of unmanaged resources will be completed tomorrow...