Is the singleton pattern prone to thread safety problems? If so, what are the best methods to work around them?

  • 1
    Well be very dependent on language. – Martin York Sep 14 '12 at 23:51

It is heavily depend on the programming language specification & how thread safety is you implemented.

For example: code provided below uses double-checked locking, which should not be used prior to J2SE 5.0, as it is vulnerable to subtle bugs.

public class Singleton {
        private static volatile Singleton instance = null;

        private Singleton() {   }

        public static Singleton getInstance() {
                if (instance == null) {
                        synchronized (Singleton.class){
                                if (instance == null) {
                                        instance = new Singleton();
                return instance;

Here is a referencing article on how to correctly implement thread safe Singleton Pattern in C#.

|improve this answer|||||
  • 4
    A correct implementation in Java is actually completely trivial: private static Singleton instance = new Singleton(); public static Singleton getInstance() { return this.instance; } - that's it. The double-checked locking crap is a red herring that keeps getting re-aired by people who love splitting hairs. – Michael Borgwardt Sep 14 '12 at 20:48
  • 1
    I have to agree with Michael. Everyone's complaint about singleton's and thread safety makes the assumption that this single instance is being created and deleted throughout the lifetime of the program. If that is the case then they have a point. However, in EVERY system I have ever seen, singletons are created at startup time and exist throughout the life of the program. In this case, all that locking stuff and thread safety issues are meaningless. Now complaining about singleton's because of global data and hard to test reasons are absolutely valid complaints. – Dunk Sep 14 '12 at 21:03
  • 1
    Maybe the 'double-checked locking crap' gets brought up because someone, somewhere at some time actually had this problem. – James Sep 15 '12 at 11:02
  • Here is a reference that discusses the double-checked locking pattern WRT singleton in C++. aristeia.com/Papers/… The authors are Scott Meyers and Andrei Alexandrescu who I think generally do a pretty good job explaining C++ issues. – DeveloperDon Sep 15 '12 at 11:21
  • I am pointing to condition "when used prior to J2SE 5.0" - at that time it is helpful to consider "double-checked locking pattern" – Yusubov Sep 15 '12 at 11:48

If well implemented, with threading in mind, a singleton will be thread safe.

There are many implementations in many languages that are not thread safe - see this article by Jon Skeet regarding Singleton in C#. Most of the implementations suffer.

The best ways to "work around them" is to know your language, how it works with threads and ensure the code is thread safe.

Just to note - even if singletons were somehow thread safe by nature, you should not use them for this reason. They tend to be overused and make for un-testable code as a source of global state.

|improve this answer|||||
  • +1 for mentioning global state, global state is prone to thread safety problems, in any form, singleton or otherwise. – Jimmy Hoffa Sep 14 '12 at 20:10
  • Singleton classes needn't hold state. Unless they're designed to. Global state has its place. – MebAlone Sep 14 '12 at 23:00
  • @MebAlone a singleton refers to a single global instance, that is the definition of global state. Yes it has it's place, but you can't write a singleton pattern that doesn't share state unless it's a singleton instance of null. – Jimmy Hoffa Sep 15 '12 at 2:49
  • Not all classes have class variables. Classes that don't have class variables don't hold state. But the class may be a singleton whose instance is shared by all clients. Granted it's a non-issue because if the class weren't a singleton, calls to new wouldn't allocate any memory, just pointers to the same methods. – MebAlone Sep 15 '12 at 4:47

Yes, as other answers have noted, it can be implemented in a thread safe manner. That said, it tends to be prone to issues since it already requires careful implementation to avoid subtle issues due to initialization order. The possibility of multiple thread access exacerbates these concerns.

And it's still global state. Even if the singleton itself is threadsafe, the reliance on global state tends to add errors to the actual multithreaded code.

|improve this answer|||||

Best way to avoid thread safety issues with a singleton is not use them. :-D That said, if you're going to use them, whether or not they're thread safe in a naive form is highly dependent on the language. If there's a safety issue, it lies with the lazy initialization nature of singletons which could end up being executed in parallel.

With that aside, let's say you're working in a language where it's not thread-safe. Such was my case in the 90s with a C codebase that was migrated to C++ where the developers started getting all happy with design patterns, including singletons. The one thing I'd request you don't do here to achieve thread safety is start trying to do fancy things like double-checked locking. Instead of doing backflips and juggling chainsaws, there's a very simple solution to the problem if you insist on using singletons:

Just make sure the singleton is initialized in the main thread prior to it being accessed in others.

That's it. It's such a simple solution, and it's no big deal to apply. You don't have to come up with some headache-inducing way to access the singleton without incurring the locking overhead in the common case. Just make sure it's initialized in the main thread before other threads get access to it. Done. Now you can make the access function lock-free and move on with your life.

|improve this answer|||||

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.