Programming .NET Components, 2nd Edition

Deterministic Finalization

.NET tries to simplify the management of object lifecycles by relieving you of the need to explicitly de-allocate the memory occupied by their objects. However, simplifying the object lifecycle comes with potential penalties in terms of system scalability and throughput. If the object holds onto expensive resources such as files or database connections, those resources are released only when Finalize() (or the C# destructor) is called. This is done at an undetermined point in the future, usually when certain memory-exhaustion thresholds are met. In theory, releasing the expensive resources the object holds may never happen, thus severely hampering system scalability and throughput.

There are a few solutions to the problems arising from nondeterministic finalization. These solutions are called deterministic finalization, because they take place at a known, determined point in time. In all deterministic finalization techniques, the object has to be explicitly told by the client when it’s no longer required. This section describes and contrasts these techniques.

The Open/Close Pattern

In order for deterministic finalization to work, you must first implement methods on your object that allow the client to explicitly order cleanup of expensive resources the object holds. Use this pattern when the resources the object holds onto can be reallocated. If this is the case, the object should expose methods such as Open() and Close().

An object encapsulating a file is ...