. NET garbage collection and Memory leakage

> Preface I believe you have heard of it and have even encountered memory leaks. On the. NET platform, you must also know that there is a garbage collector, which allows developers not to worry about memory release issues because it will customize memory management. But will there be no memory leakage if I program on the. NET platform? The answer is no. Even if the Garbage Collector with automatic memory management is available, memory leakage may occur. This article will discuss how the. NET platform garbage collector works, and avoid Memory leakage when writing. NET programs.> The basic concept of Garbage Collection refers to the memory allocated in advance but not used later. A basic concept behind garbage collection is "unlimited memory access", but there is never an infinite memory. When the machine needs to allocate memory but it is not enough, you need to recycle the memory that is no longer in use-"garbage .. The. NET Framework Garbage Collector manages the memory allocation and release of applications. Whenever you create a new object, the common language runtime allocates memory for the object from the managed heap. As long as the address space in the managed heap is available, the runtime will continue to allocate space for the new object. However, the memory is not infinitely large. Eventually, the garbage collector must recycle to release some memory. (Reference to MSDN garbage collection)> when we create an object, the system allocates a block of memory for the new object. If there is enough available memory, it will be allocated directly; however, when the memory is insufficient, the garbage collector recycles the unused objects and converts them to available memory for use by new objects. The process seems simple, but how does the Garbage Collector know the objects that are no longer used?> The garbage collection algorithm performs a garbage collection operation in three steps: 1. assume that all objects are junk. 2. mark the object in use. The tag is based on:. the object referenced by the variable is still in the scope. For example, if a method in a class is half executed, and garbage collection occurs at this time, all the variables in the method block are in the scope, and they are marked as being used. B. The object referenced by another object is still in use. 3. Compression: Release unmarked objects in step 2 (no longer used, I .e. "junk") and transfer the objects in use to contiguous memory blocks. As long as the Garbage Collector releases objects that can be released, it compresses the remaining objects and moves them back to the end of the heap to form a continuous block. Note: to improve performance, the garbage collector uses the generation mechanism. The newly created object is a new generation. The objects created earlier are the old generation, and the objects recently created are The 0th generation. To describe the basic principles of the garbage collector, this article does not discuss the generation mechanism in depth. In short, with the garbage collector, we do not have to implement code to manage the lifetime of the objects used by the application. Since the Garbage Collector with the automatic memory management function is available, why is memory leakage still occurring?> Hosted and unmanaged code executed by the public Language Runtime Library environment (rather than directly by the operating system) is called managed code and runs in. under the. NET Framework. applications or components managed by the. NET Framework are called managed resources .. More than 80% of NET resources are hosted resources, such as int, string, float, and DateTime. The unmanaged resource is. in addition to the. NET Framework, the most common type of unmanaged resources is the objects that encapsulate operating system resources, such as file, window, or network connections, although the garbage collector can track the lifetime of objects that encapsulate unmanaged resources, it does not know how to clear these resources. Therefore, for unmanaged resources, they must be displayed after they are used in the application. Therefore, most memory leaks are non-hosted resource memory leaks: they are not displayed to be released.> Memory leakage of unmanaged resources: public class Foo {Timer _ timer; public Foo () {_ timer = new Timer (1000); _ timer. elapsed + = _ timer_Elapsed; _ timer. start ();} void _ timer_Elapsed (object sender, ElapsedEventArgs e) {Console. writeLine ("Tick") ;}} calls the Foo class: static void Main (string [] args) {Foo foo = new Foo (); foo = null; Thread. sleep (int. maxValue);} Although foo is set to null, the field _ timer in foo is still alive, and the Elapsed Event continues to be executed: in this class, The _ timer object is an unmanaged object. Because of the _ timer Elapsed event,. NET Framework will keep _ timer permanently, And the _ timer object will keep the Foo instance permanently until the program is closed. To solve this problem, the release _ timer object: Foo class inherits the IDisposable interface, and the modified class: public class Foo: IDisposable {Timer _ timer; public Foo () {_ timer = new Timer (1000); _ timer. elapsed + = _ timer_Elapsed; _ timer. start ();} public void Dispose () {Console. writeLine ("Dispose"); _ timer. dispose ();} void _ timer_Elapsed (object sender, ElapsedEventArgs e) {Console. writeLine ("Tick") ;}} calls the Foo class again and displays the call to the Dispose method: static void Main (string [] args) {Foo foo = new Foo (); foo. dispose (); foo = null; Thread. sleep (int. maxValue);} foo is set to null, The _ timer object is also recycled, and The Elapsed event is stopped: