Destructor execution order?

Question

I know that Destructors in c# do not have an execution order.

The following Structure i do use in several Classes, it's to Desturct instances and the Static Information:

public class MyClass
{
    private static readonly Destructor DestructorObject = new Destructor();

    ~MyClass()
    {
        Console.WriteLine("Destructor Called");
    }

    static void Main(string[] args)
    {
        var myClass = new MyClass();
    }

    private sealed class Destructor
    {
        ~Destructor()
        {
            Console.WriteLine("Static Destructor Called");
        }
    }
}

As I mentioned above the order of Destuctors is undifined. But as im using this construct in many classes I found out, that in each class there is a non changing order, which also remains even if I'm recompiling the application and running it again.

Means that a MyClass1 could alaways run ~MyClass1 first and another class MyClass2 could alawways run ~Destructor first.

As there clearly is a "hidden" order for each class, can I trust it?

C# does not have destructors. You are describing finalizers. They slow up garbage collection and thus your application. As such, they should only ever be used in edge-case scenarios, such as to ensure unmanaged resources are freed as soon as possible and only when the deterministic `IDisposable` solution cannot be used. — David Arno, May 21 '15 at 09:01
@DavidArno Yes, [they do](https://msdn.microsoft.com/en-us/library/66x5fx1b.aspx). Of course it's just naming semantics, but still... — Yuval Itzchakov, May 21 '15 at 09:03
@YuvalItzchakov They are finalizers. It is a misnomer. Maybe design team were at the bar while they named it as destructor :p — Sriram Sakthivel, May 21 '15 at 09:04
@SriramSakthivel People avoid calling them destructors because of the way C and C++ execute destructors, but still, whatever ;) — Yuval Itzchakov, May 21 '15 at 09:07
@YuvalItzchakov You may be interested in [eric's article](http://blogs.msdn.com/b/ericlippert/archive/2010/01/21/what-s-the-difference-between-a-destructor-and-a-finalizer.aspx) — Sriram Sakthivel, May 21 '15 at 09:08

score 8 · Accepted Answer · edited Jun 20 '20 at 09:12

As there clearly is a "hidden" order for each class, can I trust it?

No, you cant. If you look at the the docs, they scream:

The finalizers of two objects are not guaranteed to run in any specific order, even if one object refers to the other. That is, if Object A has a reference to Object B and both have finalizers, Object B might have already been finalized when the finalizer of Object A starts.

Relying on an implementation detail like this as part of you normal flow of execution would be a very bad idea.

Seeing that for some reason you chose to use finalizers as a way of cleaning up static resources, you should first think if that is the right approach, taking into account everything destructors imply, and then at least implement IDisposable and give the caller a chance to dispose of resources, calling GC.SupressFinalize as well.

Using this as a common approach in your objects will also cause the objects to prolong their life, as they will be eligible for collection only once they move to the f-reachable queue, and relying on the finalizer thread to actually clean them up, which isn't guaranteed at all.

Eric Lippert has recently (18-05-2015) started a series called When everything you know is wrong talking about finalizer myths, I suggest you take a look.

Edit:

Funny, Erics second post (posted today) in the series answers this question:

Myth: Finalizers run in a predictable order

Suppose we have a tree of objects, all finalizable, and all on the finalizer queue. There is no requirement whatsoever that the tree be finalized from the root to the leaves, from the leaves to the root, or any other order.

score 2 · Answer 2 · answered May 21 '15 at 09:20

As screamed many times earlier, finalizers don't guarantee any order. You can't make any assumptions. You should assume the worst (i.e) it can be executed in any order.

As there clearly is a "hidden" order for each class, can I trust it?

Yes and no.

For normal objects order of execution of finalizers is unpredictable. So no. You can't rely anything in it.

For objects which inherits from SafeHandle, yes there is some ordering. For example: If you get two objects ready for finalization, one is derived from SafeHandle and other is not, then it is guaranteed that the finalizer of object which doesn't inherit from SafeHandle will be executed before the SafeHandle's finalizer is executed.

This ordering exist for a reason which is described in this blog post. This isn't documented but blogged by BCL team. It is unlikely to be changed in future. But...

To prove it, the following program will always finalize Destructor class first then MyClass. Because you know MyClass inherits from SafeHandle.

public class MyClass : SafeHandle
{
    private static readonly Destructor DestructorObject = new Destructor();

    ~MyClass()
    {
        Console.WriteLine("Destructor Called");
    }

    protected override bool ReleaseHandle()
    {
        return true;
    }

    public override bool IsInvalid
    {
        get { return false; }
    }

    static void Main(string[] args)
    {
        var myClass = new MyClass(IntPtr.Zero, true);
    }

    private sealed class Destructor
    {
        ~Destructor()
        {
            Console.WriteLine("Static Destructor Called");
        }
    }

    public MyClass(IntPtr invalidHandleValue, bool ownsHandle)
        : base(invalidHandleValue, ownsHandle)
    {
    }
}

Ah well thanks, this provides well usable additional information +1 — LuckyLikey, May 21 '15 at 09:29

score 1 · Answer 3 · answered May 21 '15 at 08:56

1

I'd suggest reading Eric Lippert's latest blog post, but as the order is not defined, you cannot rely on the order remaining the same in a future version.

answered May 21 '15 at 08:56

Rowland Shaw

37,700
14
97
166

Destructor execution order?

3 Answers3

Linked