In software engineering, the singleton pattern is a design pattern that restricts the instantiation of a class to one object. This is useful when exactly one object is needed to coordinate actions across the system. The concept is sometimes generalized to systems that operate more efficiently when only one object exists, or that restrict the instantiation to a certain number of objects.

Implementation of a singleton pattern must satisfy the single instance and global access principles. It requires a mechanism to access the singleton class member without creating a class object and a mechanism to persist the value of class members among class objects. The singleton pattern is implemented by creating a class with a method that creates a new instance of the class if one does not exist. If an instance already exists, it simply returns a reference to that object. To make sure that the object cannot be instantiated any other way, the constructor is made private.

Note the distinction between a simple static instance of a class, and a singleton: although a singleton can be implemented as a static instance, it can also be lazily constructed, requiring no memory or resources until needed. Another notable difference is that static member classes cannot implement an interface, unless that interface is simply a marker. So if the class has to realize a contract expressed by an interface, it really has to be a singleton.
The singleton pattern must be carefully constructed in multi-threaded applications. If two threads are to execute the creation method at the same time when a singleton does not yet exist, they both must check for an instance of the singleton and then only one should create the new one. If the programming language has concurrent processing capabilities the method should be constructed to execute as a mutually exclusive operation. 

The following is an example implementation with the following benefits:
a) Because the instance is created inside the Instance property method, the class can exercise additional functionality (for example, instantiating a subclass), even though it may introduce unwelcome dependencies.
b) The instantiation is not performed until an object asks for an instance; this approach is referred to as lazy instantiation. Lazy instantiation avoids instantiating unnecessary singletons when the application starts.
The disadvantage of the following implementation is that it is NOT thread safe for multithreading environments.  If separate threads of execution enter the Instance property method at the same time, more than one instance of the Singleton object may be created. Each thread could execute the following statement and decide that a new instance has to be created:

using System;  
public class Singleton  
{  
   private static Singleton instance;
  
   private Singleton() {}
  
   public static Singleton Instance  
   {  
      get   
      {  
         if (instance == null)  
         {  
            instance = new Singleton();  
         }  
         return instance;  
      }  
   }  
} 

There is one approach name ‘double-check locking’ to help resolve the above thread-safe issue however the .NET Framework resolve this via the static initialization implementation.
< br>In this strategy, the instance is created the first time any member of the class is referenced. The common language runtime takes care of the variable initialization.

The class is marked sealed to prevent derivation, which could add instances. In addition, the variable is marked readonly, which means that it can be assigned only during static initialization (which is shown here) or in a class constructor.

This implementation is similar to the preceding example, except that it relies on the common language runtime to initialize the variable. It still addresses the two basic problems that the Singleton pattern is trying to solve: global access and instantiation control. The public static property provides a global access point to the instance. Also, because the constructor is private, the Singleton class cannot be instantiated outside of the class itself; therefore, the variable refers to the only instance that can exist in the system.

Because the Singleton instance is referenced by a private static member variable, the instantiation does not occur until the class is first referenced by a call to the Instance property. This solution therefore implements a form of the lazy instantiation property, as in the Design Patterns form of Singleton.

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

 
The only potential downside of this approach is that you have less control over the mechanics of the instantiation. In the Design Patterns form, you were able to use a nondefault constructor or perform other tasks before the instantiation.  Because the .NET Framework performs the initialization in this solution, you do not have these options. In most cases, static initialization is the preferred approach for implementing a Singleton in .NET.

Finally Multithreaded Singleton Static initialization is suitable for most situations. When your application must delay the instantiation, use a non-default constructor or perform other tasks before the instantiation, and work in a multithreaded environment, you need a different solution.  

The following implementation allows only a single thread to enter the critical area, which the lock block identifies, when no instance of Singleton has yet been created:

using System;  
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;  
      }  
   }  
}  

This approach ensures that only one instance is created and only when the instance is needed. Also, the variable is declared to be volatile to ensure that assignment to the instance variable completes before the instance variable can be accessed. Lastly, this approach uses a syncRoot instance to lock on, rather than locking on the type itself, to avoid deadlocks.

This double-check locking approach solves the thread concurrency problems while avoiding an exclusive lock in every call to the Instance property method. It also allows you to delay instantiation until the object is first accessed. In practice, an application rarely requires this type of implementation. In most cases, the static initialization approach is sufficient. 
Finally, there is a much cleaner approach than above if using .NET 4 or greater.

public sealed class Singleton  
{  
    private static readonly Lazy lazy =  
        new Lazy(() => new Singleton());  
      
    public static Singleton Instance { get { return lazy.Value; } }  
  
    private Singleton()  
    {  
    }  
}

It's simple and performs well. It also allows you to check whether or not the instance has been created yet with the IsValueCreated property, if you need that.

Reference: http://csharpindepth.com/Articles/General/Singleton.aspx