. NET memory management, GC mechanism, memory release process

Introduction
As one. NET programmer, we know that the memory management of managed code is automatic. NET can ensure that our managed program at the end of all release, which for our programmers save a lot of trouble, we can not even think how to manage memory, anyway. NET itself will guarantee everything. Well, it makes sense, there's some truth to it. The problem is when we use unmanaged resources. NET will not be automatically managed. This is because unmanaged code is not controlled by the CLR (Common Language Runtime) beyond the scope of the CLR's administration. So how do you deal with these unmanaged resources,. How does net manage and release managed resources?

Automatic memory management and GC
The memory allocation for the heap in the original program is this: find the first memory address that has enough space (not occupied), and then allocate the memory. The programmer will need to manually release this memory when the program no longer requires this in-memory information. The memory of the heap is common, which means that all processes may overwrite the memory content of another process, which is why many poorly designed programs even let the operating system down. The programs we sometimes run into are inexplicably dead (random) and are also caused by improper memory management (possibly due to memory problems with their own programs or external programs). Another common example is the trainer of games that are often seen, and they are "invincible" by directly modifying the memory of the game. With that in mind, we can imagine how dangerous it would be if the memory address was messed up, and we could imagine why C + + programmers (some) had a headache when they mentioned the pointer. Also, if the memory in the program is not manually released by the programmer, then the memory will not be reassigned until the computer is reset, which is what we call a memory leak. In the case of unmanaged code, the CLR avoids these memory management problems by AppDomain the isolation of the code, meaning that a AppDomain cannot normally read/write another AppDomain memory. Managed memory deallocation is the responsibility of the GC (garbage Collector). We're going to go further with this GC, but before we do that we'll talk about the allocation of memory in managed code, the allocation of memory in the managed heap is sequential, that is, an assignment next to one. This allows the memory allocation to be higher than the original program, but the higher speed will be found by GC. Why? Once you've seen how the GC works, you'll know the answer.
How GC Works
First we need to know when objects in managed code are recycled we can't control it (unless we use gc.collect to force GC to recycle, which is not recommended, and that explains why). The GC performs a recycle when it is "happy" (for many reasons, such as when there is not enough memory.) This is done to improve memory allocation, recovery efficiency. So what if we use destructor? No, not at all, because. NET the concept of destructor is no longer there, it becomes finalizer, which will be mentioned later. At this time, remember that an object can be recycled only if there is no reference to it. To illustrate this point, see the following section of code:
[C #]
Object Obja = new Object ();
Object OBJB = Obja;
Obja = null;
Forced recycling.
Gc. Collect ();
Objb.tostring ();

[Visual Basic]
Dim Obja as New Object ()
Dim objb as Object = Obja
Obja = Nothing
' Forced recycling.
Gc. Collect ()
Objb.tostring ()
Here Obja the referenced object is not reclaimed because there is another reference to this object, OBJB.
The object is eligible to be reclaimed after no reference has been made to it. When GC is recycled, it does the following steps:
Determines that the object does not have any references.