Essentially, a singleton is a class which only allows a single instance of itself to be created and usually gives simple access to that instance. Most commonly, singletons don’t allow any parameters to be specified when creating the instance, for that This article deals only with the situation where no parameters are required.
There are various different ways of implementing the singleton pattern in C# and I will describe main four ways to implement Singleton Pattern.
First Version: Not Thread Save
public seald class singletomInstance {
private singletomInstance (){ }
private static singletomInstance _singleInstance =null ;
Public staitc singletomInstance Instance {
get{
if(_singleInstance ==null) { _singleInstance = new singletomInstance() ; }
return _singleInstance ;
}
}
}
Second Version: simple thread Save :
This implementation is thread-safe. The thread takes out a lock on a shared object and then checks whether or not the instance has been created before creating the instance.
public sealed class singletomInstance
{
private static singletomInstance _singleInstance =null ;
private static readonly object padlock = new object();singletomInstance () { }
public static singletomInstance Instance
{
get
{
lock (padlock)
{
if (_singleInstance == null)
{
_singleInstance = new Singleton();
}
return _singleInstance ;
}
}
}
}
Third Version: Thread Save by double checking :
This implementation attempts to be thread-safe without the necessity of taking out a lock every time. Unfortunately, there are four downsides to the pattern:
- It doesn’t work in Java. This may seem an odd thing to comment on, but it’s worth knowing if you ever need the singleton pattern in Java
- Without any memory barriers, it’s broken in the ECMA CLI specification too. It’s possible that under the .NET 2.0 memory model (which is stronger than the ECMA spec) it’s safe, but I’d rather not rely on that stronger semantics, especially if there’s any doubt as to the safety. Making the variable Instance volatile can make it work, as would explicit memory barrier calls, although in the latter case even experts can’t agree exactly which barriers are required. I tend to try to avoid situations where experts don’t agree what’s right and what’s wrong!
- It’s easy to get wrong. The pattern needs to be pretty much exactly as Below- any significant changes are likely to impact either performance or correctness.
- It still doesn’t perform as well as we need
public sealed class singletomInstance
{
private static singletomInstance _singleInstance = null;
private static readonly object padlock = new object();Singleton(){ }
public static singletomInstance Instance
{
get
{
if (_singleInstance == null)
{
lock (padlock)
{
if (_singleInstance == null)
{
_singleInstance = new Singleton();
}
}
}
return_singleInstance ;
}
}
}
fourth Version: thread save without lock
public sealed class singletomInstance
{
private static readonly singletomInstance _singleInstance = new singletomInstance ();// Explicit static constructor to tell C# compiler
// not to mark type as beforefieldinit
static singletomInstance ()
{
}private singletomInstance ()
{
}public static singletomInstance Instance
{
get
{
return _singleInstance ;
}
}
}
As you can see, this is really is extremely simple – but why is it thread-safe and how lazy is it? Well, static constructors in C# are specified to execute only when an instance of the class is created or a static member is referenced, and to execute only once per AppDomain. Given that this check for the type being newly constructed needs to be executed whatever else happens, it will be faster than adding extra checking as in the previous examples
