Do not use the incorrect Singleton Mode

The SingleTon mode may be the most widely used mode, but recently several SingleTon models have to make me feel cold.
Let's take a look at the standard counterexample:
C # Public static SomeObject GetInstance ()
{
If (_ instance = null)
{
Lock (_ syncRoot)
{
_ Instance = new SomeObject ();
}
}
Return _ instance;
}

VB. Net Public Shared Function GetInstance () As SomeObject
If _ instance Is Nothing Then
SyncLock syncRoot
_ Instance = New SomeObject ()
End SyncLock
End If
Return _ instance
End Function

Seeing this code, I believe everyone knows the failure of SingleTon. It is simply a SingleTon without thread security, and the lock is still used in the wrong place... Assuming that SomeObject creation takes a long time (for example, database access) and 10 threads come in, it is also very likely to create 10 instances. It can be said that it is the most failed SingleTon.
Another common error is the double check lock. This error is usually caused by JIT Compiler Optimization. Let's take a look at the counterexample: Public class BadSingleTon
{
Private static readonly object _ syncRoot = new object ();
Private static BadSingleTon _ instance;

Private BadSingleTon ()
{
// Label 5
}

Public static BadSingleTon Instance
{
Get
{
// Label 1
If (_ instance = null)
{
// Label 2
Lock (_ syncRoot)
{
// Label 3
If (_ instance = null)
{
// Label 4
_ Instance = new BadSingleTon ();
}
}
}
Return _ instance;
}
}
}

At first glance, it seems perfect. When an instance exists, it is directly returned to the instance. If the instance does not exist, it is locked and then determined whether the instance exists (why? Without this judgment, multiple instances will be created in the same way as in the preceding example.) If there are still no instances, create them.
However, due to the optimization of the compiler, the actual effect is A little different. Suppose there are two threads, namely thread A and thread B. Thread A first enters the Instance attribute, and the Instance is empty, thread A enters Label 1, 2, 3, and 4 in sequence, and then creates an object, that is, Label 5. If the object has not been created yet, but due to the optimization of the compiler, _ The instance is no longer empty. At this time, thread A is popped up and thread B enters. Thread B finds that the instance is not empty and returns the instance directly, but thread B does not know, the instance has not been created yet. Then thread B uses the instance that has not been created to perform various operations. The danger is self-evident.
Many people like to use latency to create SingleTon. However, I personally think this SingleTon requires a certain understanding of the thread. net program, this latency does not seem very important, so I prefer the simplest way to directly create objects on static fields, in this way, you can easily avoid locks and create multiple instances, which is guaranteed by the CLR level (if the CLR is executed multiple times, the only explanation is, in this case, it is executed in multiple AppDomains ).
Of course, the disadvantage of doing so is that it is not enough delay, but in many cases, this method has been enough delay.
When will the. net run type construction? Yes. When this type is used for the first time. If the only static member that is publicly available in this Singleton type is the GetInstance method or Instance attribute, in addition to this method or attribute, what else can cause this type of structure to be created?
Therefore, you don't need to worry too much about delayed creation. Don't forget that the more code you write, the more bugs you may encounter. Since there is no big problem in directly creating fields, why not?
Of course, SingleTon mentioned here is at the AppDomain level. If you want to share an instance among multiple AppDomains, you cannot do this simply.