What is the .NET object life cycle?

Question

What is the object life cycle for an object in .NET?

From what I understand it is:

1. Object created - constructor called (if one exists)
2. Methods/Properties/Fields used
3. Object destroyed - Dispose called (if one exists)
4. Destructor called by GC at some point

Solution 1

Dispose doesn't get called automatically; you need to call it, or use a using block, eg.

using(Stream s = File.OpenRead(@"c:\temp\somefile.txt"))
    // Do something with s

The finalizer only gets called by the GC if it exists. Having a finalizer causes your class to be collected in 2 steps; first the object is put in the finalizer queue, then the finalizer is called and the object is collected. Objects without finalizers are directly collected.

The guideline is that Dispose gets rid of managed and unmanaged resources, and the finalizer only cleans up unmanaged resources. When the Dispose method has freed the unmanaged resources it can call GC.SuppressFinalize to avoid the object from living long to be put on the finalizer queue. See MSDN for a correct sample of the dispose pattern.

Solution 2

Just as an edge case... you can create objects without using the ctor at all:

class Foo {  
    public Foo() {
        message += "; ctor";
    }
    string message = "init";
    public string Message { get { return message; } }
}
static class Program {
    static void Main() {
        Foo foo = new Foo();
        Console.WriteLine(foo.Message); // "init; ctor"
        Foo bar = (Foo)System.Runtime.Serialization.FormatterServices
            .GetSafeUninitializedObject(typeof(Foo));
        Console.WriteLine(bar.Message); // null
    }
}

Solution 3

Here are the steps I know of:

1. load the assembly
2. execute static initialisers
3. "new" call:
   1. allocate memory
   2. execute non-static initialisers
   3. execute constructor
4. the instance is now ready to be used
5. after the last reference to the object has vanished: if the object has no finalizer, it is now ready for collection; if the object has a finalizer, it is put on the finalizer queue.
6. (optional) the objects from the finalizer queue have their finalizer called in a special thread; if there is still no reference from the application to the object, it too becomes now eligible for garbage collection
7. the garbage collector deallocates memory

As others already have pointed out, Dispose() must be called by the user since the runtime won't act on it.

Solution 4

Here is a detailed descriptin of the question. First, Dispose is not called by runtime, you have to call it yourself. There are also no destructors, but finalizers: if an object overrides a Finalized method, it is called when the object is no longer accessible for the application. It may happen that during finalization the object becomes accessible again (for example, stores a reference to itself in a global object), so it returns to step 2 of your model. There are also methods in GC object that let the user control object finalization.

Solution 5

The Object Life Cycle

Creating an object: You use the new keyword to instantiate the new object.

1. A block of memory is allocated. This block of memory is big enough to hold the object. (CLR handles the allocation of memory for managed objects)
2. The block of memory is converted to an object. The object is initialized. (You can control this step by implementing a constructor)

Destroying an Object: You use destruction to reclaim any resources used by that object.

1. The object is cleaned up; for example, by releasing any unmanaged resources used by the application, such as file handles and database connections. (You can control this step by implementing a destructor.)
2. The memory used by the object is reclaimed.

The CLR handles the release of memory used by managed objects; however, if you use unmanaged objects, you may need to manually release the memory used by these items.

View more solutions

Comments

[David Schmitt]

I thought that finalizers are not allowed to touch managed space anymore. At least that was my reading of the official IDispose pattern, which specifically separates between managed and unmanaged resources for the finalizer.

[rein]

Not that I can see when you would or should use this but +1 for teaching me something cool.

[Marc Gravell]

This is mainly used by BinaryFormatter during deserialization

[Sander Rijken]

They can, but just don't do that. See blogs.msdn.com/clyon/archive/2006/04/25/583698.aspx

[Raquel]

If you want one class to explain the entire life cycle you should add a static field and static constructor as well.

[Raquel]

Should point out that if the finalizer takes too long to run the thread will be aborted without any notification or thrown exceptions

[Bert Huijben]

static constructors are not necessary initialized in this order. I think the only guarantee is that they are called before accessing static variables in that class.. But that can be after the constructor.

[David Schmitt]

msdn.microsoft.com/en-us/library/k9x6w0hc.aspx states explicitly: "called automatically before the first instance is created or any static members are referenced"