Firing destructor in non-static class that contains static field?

Question

I wanted to test when a destructor is called in a class,When it is a simple class every thing goes as expected - when we leave instance's scope destructor is called.

But when we add a static field it does not happen. Can anyone explain the concept behind this condition?

public class Test
{
    ~Test(){}
    private static string StaticField="";
    private float NonStaticField;    
}

And what would happen for other fields that are non-static and have values? Do they never get cleaned?

I tested calling destructor through Controller as you see below

public class HomeController : Controller
{
    // GET: Home
    public ActionResult Index()
    {
        var ts = new Test();
        return View();
    }
}

When I remove static field after leaving Index destructor is called.

Edit:calling destructor is a bit weird because it behaves different in static and non-static methods,if i create the instance inside an static method and leave the scope, destructor is called .

Answer 1

There is no predictable point when the destructor is called. The memory is managed by the garbage collector:

Garbage collection occurs when one of the following conditions is true:

• The system has low physical memory. This is detected by either the low memory notification from the OS or low memory indicated by the host.

• The memory that is used by allocated objects on the managed heap surpasses an acceptable threshold. This threshold is continuously adjusted as the process runs.

• The GC.Collect method is called. In almost all cases, you do not have to call this method, because the garbage collector runs continuously. This method is primarily used for unique situations and testing.

So usually you are not interested when this happens, just that it happens. To see for myself I tried to repeat your experiment with a simple test program. The test function, that created the test class without a static field, was called multiple times. All created instances were only finalised and freed when the program finished.

If it is important and you want to control the moment when the instance is finalised, you should implement the IDisposable interface and use a using statement.

Answer 2

I think finally found out what is happening behind the scene,based on microsoft article, Garbage collector think of the objects as one of the three Generations, Generation 0,Generation 1,Generation 2 . and it says implicitly that

The heap is organized into generations so it can handle long-lived and short-lived objects. Garbage collection primarily occurs with the reclamation of short-lived objects that typically occupy only a small part of the heap

Generation 2. This generation contains long-lived objects. An example of a long-lived object is an object in a server application that contains static data that is live for the duration of the process.

and objects that fall into generation 2 category are not disposed immediately, of course garbage collector behavior in web applications is different from windows applications. to determine when garbage collector is performing it's job we should know about latency

Latency refers to the time that the garbage collector intrudes in your application

and default latency mode for web applications is Interactive:

Enables garbage collection concurrency and reclaims objects while the application is running. This is the default mode for garbage collection on a workstation and is less intrusive than Batch. It balances responsiveness with throughput. This mode is equivalent to garbage collection on a workstation that is concurrent.

i am pretty sure that it's a vast topic that needs to be considered precisely, you can use links below to read more about garbage collecting

Fundamentals of garbage collection

Garbage Collection

Latency Mode