Singletons in C#, Static Constructor vs Static Initialization

A Technical Blog article. View original blog here.[^]

Not a long time ago, I posted an article about how to implement a static constructor. As an example, I used a singleton to show how the static constructor works and how it is implemented. The result was a discussion about singletons, what they are good for and how it can be implemented in C#. There is the standard way (how it is normally done) and also a lot easier way for C# with a static constructor or a static initialization.

The Classic Singleton

public sealed class Singleton
{
   private static volatile Singleton instance;
   private static object syncRoot = new Object();

   private Singleton() {}

   public static Singleton Instance
   {
      get 
      {
         if (instance == null) 
         {
            lock (syncRoot) 
            {
               if (instance == null) 
                  instance = new Singleton();
            }
         }

         return instance;
      }
   }
}

In every object oriented language (or those I know), a Singleton looks nearly (more or less) like the code above. The Singleton restricts the instantiation of a class to one object. This is provided by a static field which holds the instance. If the instance which is stored in the static field is still null, a new object will be created and assigned to the static variable. The code which does the instantiation is locked so it also works in a multi threaded environment (double check locking). Too much code for you?

Singleton with Static Initialization

public sealed class Singleton
{
   private static readonly Singleton instance = new Singleton();
   
   private Singleton(){}

   public static Singleton Instance
   {
      get 
      {
         return instance; 
      }
   }
}

C# allows you to initialize the static field directly (and it also works properly)! The instantiation does occur when instance property is called the first time, so it is some sort of lazy instantiation. .NET takes control that it also works in multi threaded environments, so you have nothing to do with it. But you will still have a problem with that solution if you want to execute custom code before instantiation! With a static constructor, you can solve this problem!

Singleton with Static Constructor

public sealed class Singleton
{
   private static readonly Singleton instance;
   
   private Singleton() { }

   static Singleton()
   {
      instance = new Singleton()
   }

   public static Singleton Instance
   {
      get 
      {
         return instance; 
      }
   }
}

It allows you to execute custom code before the singleton is instantiated. But the complexity is still handled by the .NET Framework, so you don't have to implement a double check locking also when you work in multi threaded environments. The static constructor is only executed when the instance property is called the first time. So both variations allow you to implement a thread safe singleton where the complexity is hidden in the .NET Framework. You do not even need an if statement!