Using Garbage Collection and Resource Management in .NET framework

Painting PDF 417 in .NET framework Using Garbage Collection and Resource Management

14

counts the number of existing instances by incrementing a static variable in the constructor and decrementing the same static variable in the destructor:

class Tally { public Tally() { this.instanceCount++; } ~Tally() { this.instanceCount--; } public static int InstanceCount() { return this.instanceCount; } ... private static int instanceCount = 0; }

There are some very important restrictions that apply to destructors: Destructors apply only to reference types. You cannot declare a destructor in a value type, such as a struct.

struct Tally { ~Tally() { ... } // compile-time error }

You cannot specify an access modi er (such as public) for a destructor. You never call the destructor in your own code part of the the runtime called the garbage collector does this for you.

You never declare a destructor with parameters, and the destructor cannot take any parameters. Again, this is because you never call the destructor yourself.

The compiler automatically translates a destructor into an override of the Object.Finalize method. The compiler translates the following destructor:

class Tally { ~Tally() { ... } }

into this:

class Tally { protected override void Finalize() { try { ... } finally { base.Finalize(); } } }

The compiler-generated Finalize method contains the destructor body inside a try block, followed by a nally block that calls the Finalize method in the base class. (The try and nally keywords are described in 6, Managing Errors and Exceptions. ) This ensures that a destructor always calls its base class destructor. It s important to realize that only the compiler can make this translation. You can t override Finalize yourself, and you can t call Finalize yourself.

You should now understand that you can never destroy an object yourself by using C# code. There just isn t any syntax to do it, and there are good reasons why the designers of C# decided to forbid you from doing it. If it were your responsibility to destroy objects, sooner or later one of the following situations would arise: You d forget to destroy the object. This would mean that the object s destructor (if it had one) would not be run, tidying up would not occur, and memory would not be deallocated back to the heap. You could quite easily run out of memory. You d try to destroy an active object. Remember, objects are accessed by reference. If a class held a reference to a destroyed object, it would be a dangling reference. The dangling reference would end up referring either to unused memory or possibly to a completely different object in the same piece of memory. Either way, the outcome of using a dangling reference would be unde ned at best or a security risk at worst. All bets would be off. You d try and destroy the same object more than once. This might or might not be disastrous, depending on the code in the destructor. These problems are unacceptable in a language like C#, which places robustness and security high on its list of design goals. Instead, the garbage collector is responsible for destroying objects for you. The garbage collector makes the following guarantees: Every object will be destroyed and its destructors run. When a program ends, all outstanding objects will be destroyed. Every object will be destroyed exactly once.

14

Every object will be destroyed only when it becomes unreachable that is, when no references refer to the object. These guarantees are tremendously useful and free you, the programmer, from tedious housekeeping chores that are easy to get wrong. They allow you to concentrate on the logic of the program itself and be more productive. When does garbage collection occur This might seem like a strange question. After all, surely garbage collection occurs when an object is no longer needed. Well, it does, but not necessarily immediately. Garbage collection can be an expensive process, so the runtime collects garbage only when it needs to (when it thinks available memory is starting to run low), and then it collects as much as it can. Performing a few large sweeps of memory is more ef cient than performing lots of little dustings! Note You can invoke the garbage collector in a program by calling the static method System. GC.Collect. However, except in a few cases, this is not recommended. The System.GC.Collect method starts the garbage collector, but the process runs asynchronously, and when the method call is complete, you still don t know whether your objects have been destroyed. Let the runtime decide when it is best to collect garbage! One feature of the garbage collector is that you don t know, and should not rely upon, the order in which objects will be destroyed. The nal point to understand is arguably the most important: destructors do not run until objects are garbage collected. If you write a destructor, you know it will be executed, but you just don t know when.