Our website uses cookies to enhance your browsing experience.
Your message has been sent. We will email you at
If you do not see the email in your inbox, please check if it is filtered to one of the following folders:
Webinar: Evaluation - 05.12
Not so long ago we worked on a diagnostic rule related to the finalizer check. This provoked an argument on the details of the garbage collector work and the finalization of objects. Although we have been programming in C# for more than 5 years, we haven't achieved any consensus as regards this question, so I decided to study it more thoroughly.
Usually .NET developers encounter a finalizer when they need to free an unmanaged resource. That's when a programmer has to think about a specific question: should we implement in our class IDisposable, or add a finalizer? Then he goes to Stack Overflow, for example, and reads answers to questions like the Finalize/Dispose pattern in C#, where he sees a classic pattern of IDisposable implementation, and the definition of the finalizer. The same pattern can be found in the MSDN description of the IDisposable interface. Some consider it quite complicated to understand, and offer other options like implementing the clearing of managed and unmanaged resources in separate methods, or creating a wrapper class especially for freeing unmanaged resource. You can find them on the same page on Stack Overflow.
Most of these methods suggest implementing a finalizer. Let's see what the benefits are, and what potential problems it can bring.
Pros.
Well, that's it. That is the only plus, and it is quite controversial; we'll speak about the details later.
Cons.
class Root
{
public volatile static Root StaticRoot = null;
public Nested Nested = null;
~Root()
{
Console.WriteLine("Finalization of Root");
StaticRoot = this;
}
}
class Nested
{
public void DoSomeWork()
{
Console.WriteLine(String.Format(
"Thread {0} enters DoSomeWork",
Thread.CurrentThread.ManagedThreadId));
Thread.Sleep(2000);
Console.WriteLine(String.Format(
"Thread {0} leaves DoSomeWork",
Thread.CurrentThread.ManagedThreadId));
}
~Nested()
{
Console.WriteLine("Finalization of Nested");
DoSomeWork();
}
}
class Program
{
static void CreateObjects()
{
Nested nested = new Nested();
Root root = new Root();
root.Nested = nested;
}
static void Main(string[] args)
{
CreateObjects();
GC.Collect();
while (Root.StaticRoot == null) { }
Root.StaticRoot.Nested.DoSomeWork();
Console.ReadLine();
}
}This is what will be be displayed on my machine:
Finalization of Root
Finalization of Nested
Thread 10 enters DoSomeWork
Thread 2 enters DoSomeWork
Thread 10 leaves DoSomeWork
Thread 2 leaves DoSomeWorkIf your finalizers called in a different order, try to change the places of the creation of nested and root.
Finalizers in .NET are the easiest way to shoot yourself in the foot. Before you rush into adding finalizers for all the classes that are implementing IDisposable, think first; do you really need them that much? It should be noted that the CLR developers warn against their use on the page the Dispose Pattern: "Avoid making types finalizable. Carefully consider any case in which you think a finalizer is needed. There is a real cost associated with instances with finalizers, from both a performance and code complexity standpoint."
But if you decide to use finalizers anyway, PVS-Studio will help you find potential bugs. We have the V3100 diagnostic, which can indicate all spots in the finalizer where there is a possibility of NullReferenceException.
0
0
0
0