.NET, Design

Different ways to implement Singleton in .NET (and make people hate you along the way)


Code that accompanies this article can be downloaded here.


The Singleton Pattern is probably the most well-known design patterns that came out of Gang of Four’s book Design Patterns: Elements of Reusable Object-Oriented Software. This pattern is one of the creational patterns, and basically, it ensures that only one object of a particular class is created and shared among other members of the system. Singleton class should enable easy access to its only instance to the other classes.

But this design pattern carries a lot of controversies too. Some consider it an antipattern and cause of code smell. Among many complaints, people often argue that it violate Single Responsibility Principle, due to the fact that it handles its own creation, that it couples code and that it is hard to test. And even thought some of these issues were addressed by Uncle Bob himself, there are a lot of good points that Singleton class shouldn’t be used. Heck, there is a good chance that people will hate you just by writing one. But…

Singleton patterns still solve one problem that you may encounter – Resource Contention. This is a situation where you need one instance of the object and you need to manage that instance. There are not many cases of this situation and one example of this is a single log file. There are suggestions that you can solve this problem with Dependancy Injection which you should also consider. But, in case you need Singleton let’s take a look at some good and bad ways to implement Singleton class.

Standard implementation

Singleton pattern is also one of the most commonly asked interview questions. Usually, candidates are asked to write one version of singleton implementation. If you google this you’ll probably find few hits that will suggest an implementation that looks like this:

Now this will probably pass as a fine answer on an interview, but this code definitely has a lot of problems, apart from not being very impressive one. The biggest problem is that this code isn’t thread-safe, and that is why you shouldn’t use this code. Yes, now you are using threads and Singleton and everyone will avoid you in the office. Nevertheless, let’s go trough this thought exercise. We don’t want to end up in the situation where two threads evaluate if (_instance == null) as true and each creates an instance of the class.

Thread-safe implementation

So, let’s do something like this:

There it is, we used locks to make our singleton class thread-safe. But, locks are not very good synchronization mechanisms in this case. Because the lock is required everytime Instance is asked for, the performance of this code will be degraded. This problem can be avoided if we ask if the instance is null before locking and then asking is instance null once again after acquiring the lock. Now, that would look ugly. Also, we already have one if-null combo, and we can agree that controlling flow with if-null combos is not such a good idea and that it indicated that we have problems in our design.
Can we try to use the static constructor?

Implementation with static constructor

Static constructors will assure that it has been run only once per application domain, meaning that our Singleton class can look like this:

The first thread that wants to get property Instance will trigger static constructor, also known as type initializer. Other threads that try to read the Instance property will be locked until static constructor has finished. Only once it completes its task, other threads will be allowed to get Instance value. So, locking on every time someone tries to get an instance is avoided.

But…people will have a lot of comments on that static constructor of yours. Usually something along the line that they could cause deadlocks if you perform blocking operations, eg. asynchronous callbacks.

Can we avoid this? If we are working in C# 4 or above, we can. And we can achieve this by using – Lazy.

Lazy implementation

Lazy initialization of an object means that object creation is deferred until it is first used. This way of object construction is used primarily for optimization purposes. In .NET 4 and above, we can use the Lazy class, which encapsulates this kind of behavior. It is also thread-safe, so we don’t have to worry about multiple threads creating duplicate objects.

So, Singleton implementation using Lazy would look like this:

Conclusion

Singleton is for sure one pattern with many flaws. The problem is also that this pattern is often used in places not quite suited for it, thus coupling code, and adding performance issues. However, it has its purpose and its (rare) use.
And althought that there are multiple variations of Singleton implementation, I personally, prefer the last version of implementation. It is simplest, thread-safe solution with lazy initialization, that everyone can understand. Also, I need to add once again that first implementation shouldn’t be used ever.


Read more posts from the author at Rubik’s Code.

Creative Commons License


21 thoughts on “Different ways to implement Singleton in .NET (and make people hate you along the way)”

  1. Excellent article. I’ve seen some bad implementations of singleton in my time. An applicant I was interviewing argued that ‘public static Singleton Instance => new Singleton();’ is an acceptable implementation of the Singleton pattern 😦

    Like

  2. Excellent article. I’ve seen some bad implementations of singleton in my time. An applicant I was interviewing argued that ‘public static Singleton Instance => new Singleton();’ is an acceptable implementation of the Singleton pattern 😦

    Like

  3. In libraries, singleton implementations are sometimes necessary but in applications, using the lifetime options of an IOC container makes far more sense to me.

    Like

  4. I thought Lazy initialization was thread-safe but not the object in itself after the initialization. So, shouldn’t you find a way to lock the object in this case too?

    Like

    1. We are locking creation of the object, that is our critical section, not the object itself. What we are trying to avoid is creation of two instances of singleton, and that is what Lazy is providing us with.
      Hope this helps.

      Thanks for reading!

      Like

  5. You left out the biggest advantage of singletons over static classes: interface implementation. Though, I do agree that many times DI is a better solution, sometimes Singleton is the best option check out my post (also on WP) about WPF converters. In short, the framework requires a specific interface to be implemented, and there’s no support for construction via DI. Singletons are perfect here.

    Liked by 1 person

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s