21
votes

I have an object cache which implements the Singleton design pattern. My approach to singleton was always to lazy load the static instance when the property is first accessed.

public static Widget
{
    get
    {
        if(instance==null) instance = new Widget();
        return instance;
    }
}

However, I know that this approach isn't thread safe and the check for instance being null introduces a small inefficiency. Would it be wise to implement a static constructor on the class which instantiates the static instance?

As I understand it, the static constructor would be called whenever the first static property access occurs. Is this valid, and will it provide any benefits over the current lazy load approach or would it be better to explore a proxy implementation, or use a lock to force it to be thread safe?

public static Widget
    {
        get
        {
            if(instance==null)
            {
                lock(padlock)
                {
                    if(instance==null) instance = new Widget();
                }
            }
            return instance;
        }
    }

I don't have a whole lot of experience with static constructors, so don't want to leap in with this idea if it is an equal or worse implementation of the lazy load property.

Cheers, Gary

2
I believe this Q&A thread will give you what you want: stackoverflow.com/questions/246710/… - Fredrik Mörk

2 Answers

16
votes

Jon Skeet has a nice article on singletons discussing this issue.

2
votes

Rather than rolling your own threadsafe lazy initializer and possibly getting it wrong, I recommend reading the msdn on Lazy<T>.

https://docs.microsoft.com/en-us/dotnet/framework/performance/lazy-initialization#thread-safe-initialization