ECMA-334 C# Language Specification

10.9: Automatic memory management

C# employs automatic memory management, which frees developers from manually allocating and freeing the memory occupied by objects. Automatic memory management policies are implemented by a garbage collector. The memory management life cycle of an object is as follows:

1 When the object is created, memory is allocated for it, the constructor is run, and the object is considered live.

2 If the object, or any part of it, cannot be accessed by any possible continuation of execution, other than the running of destructors, the object is considered no longer in use, and it becomes eligible for destruction. [Note: Implementations may choose to analyze code to determine which references to an object may be used in the future. For instance, if a local variable that is in scope is the only existing reference to an object, but that local variable is never referred to in any possible continuation of execution from the current execution point in the procedure, an implementation may (but is not required to) treat the object as no longer in use. end note]

3 Once the object is eligible for destruction, at some unspecified later time the destructor (17.12) (if any) for the object is run. Unless overridden by explicit calls, the destructor for the object is run once only.

4 Once the destructor for an object is run, if that object, or any part of it, cannot be accessed by any possible continuation of execution, including the running of destructors, the object is considered inaccessible and the object becomes eligible for collection.

5 Finally, at some time after the object becomes eligible for collection, the garbage collector frees the memory associated with that object.

The garbage collector maintains information about object usage, and uses this information to make memory management decisions, such as where in memory to locate a newly created object, when to relocate an object, and when an object is no longer in use or inaccessible.

Like other languages that assume the existence of a garbage collector, C# is designed so that the garbage collector may implement a wide range of memory management policies. For instance, C# does not require that destructors be run or that objects be collected as soon as they are eligible, or that destructors be run in any particular order, or on any particular thread.

The behavior of the garbage collector can be controlled, to some degree, via static methods on the class System.GC. This class can be used to request a collection to occur, destructors to be run (or not run), and so forth.

[Example: Since the garbage collector is allowed wide latitude in deciding when to collect objects and run destructors, a conforming implementation may produce output that differs from that shown by the following code. The program 
using System;  
class A  
{  
   ~A() {  
      Console.WriteLine("Destruct instance of A");  
   }  
}  
class B  
{  
   object Ref;  
   public B(object o) {  
      Ref = o;  
   }  
   ~B() {  
      Console.WriteLine("Destruct instance of B");  
   }  
}  
class Test  
{  
   static void Main() {  
      B b = new B(new A());  
      b = null;  
      GC.Collect();  
      GC.WaitForPendingFinalizers();  
   }  
}
creates an instance of class A and an instance of class B. These objects become eligible for garbage collection when the variable b is assigned the value null, since after this time it is impossible for any user-written code to access them. The output could be either 
Destruct instance of A  
Destruct instance of B
or 
Destruct instance of B  
Destruct instance of A
because the language imposes no constraints on the order in which objects are garbage collected.

In subtle cases, the distinction between "eligible for destruction" and "eligible for collection" can be important. For example, 
using System;  
class A  
{  
   ~A() {  
      Console.WriteLine("Destruct instance of A");  
   }  
   public void F() {  
      Console.WriteLine("A.F");  
      Test.RefA = this;  
   }  
}  
class B  
{  
   public A Ref;  
   ~B() {  
      Console.WriteLine("Destruct instance of B");  
      Ref.F();  
   }  
}  
class Test  
{  
   public static A RefA;  
   public static B RefB;  
   static void Main() {  
      RefB = new B();  
      RefA = new A();  
      RefB.Ref = RefA;  
      RefB = null;  
      RefA = null;  
      // A and B now eligible for destruction  
      GC.Collect();  
      GC.WaitForPendingFinalizers();  
      // B now eligible for collection, but A is not  
      if (RefA != null)  
      Console.WriteLine("RefA is not null");  
   }  
}

In the above program, if the garbage collector chooses to run the destructor of A before the destructor of B, then the output of this program might be: 
Destruct instance of A  
Destruct instance of B  
A.F  
RefA is not null

Note that although the instance of A was not in use and A's destructor was run, it is still possible for methods of A (in this case, F) to be called from another destructor. Also, note that running of a destructor may cause an object to become usable from the mainline program again. In this case, the running of B's destructor caused an instance of A that was previously not in use to become accessible from the live reference RefA. After the call to WaitForPendingFinalizers, the instance of B is eligible for collection, but the instance of A is not, because of the reference RefA.

To avoid confusion and unexpected behavior, it is generally a good idea for destructors to only perform cleanup on data stored in their object's own fields, and not to perform any actions on referenced objects or static fields. end example]