My favorites | Sign in
Project Home Downloads Wiki Issues Source
A brief explanation of the problems with singletons.
Updated Feb 4, 2010 by

Why Singletons Are Controversial

The use of singletons is actually a fairly controversial subject in the Java community; what was once an often-used design pattern is now being looked at as a less than desirable coding practice. The problem with singletons is that they introduce global state into a program, allowing anyone to access them at anytime (ignoring scope). Even worse, singletons are one of the most overused design patterns today, meaning that many people introduce this possibly detrimental global state in instances where it isn't even necessary. What's wrong with singletons' use of global state?

First, programs using global state are very difficult to test. One of the hallmarks of testability is a loose coupling of classes, allowing you to isolate a single class and test it completely. When one class uses a singleton (and I'm talking about a classic singleton, one that enforces it own singularity thorough a static getInstance() method), the singleton user and the singleton become inextricably coupled together. It is no longer possible to test the user without also testing the singleton. In many cases, this is a deal breaker that can prevent a developer from testing a class at all, especially if the singleton represents a resource that should not be updated by tests (i.e. an important database). The ideal solution here is to pass in the singleton as a parameter in the user's constructor, allowing a tester to easily mock out the singleton for tests. The singleton then doesn't have to enforce its own singularity; this can be handled by the client or a factory class, which could produce the real version or a test version, eliminating the global state altogether. In fact, it should be considered a violation of the Single Responsibility Principle of OO design to have an object responsible for its own singularity as well as its normal tasks.

Second, programs that rely on global state hide their dependencies. One of the unique abilities of a singleton is that it can be accessed anywhere though its globally available static method (i.e. getInstance()), allowing programmers to use it inside of a method without having to pass it in expressly through parameters. While this may seem easier to the programmer, relying on this static instance means that the signatures of methods no longer show their dependencies, because the method could pull a singleton “out of thin air.” This means that users need knowledge of the inner workings of code to properly use it, making it more difficult to use and test.

Tying these two problems together shows another issue with singletons. In todays world of test-driven and agile development, it is more important than ever to have small tests covering most of your code. One of the important things about these tests is that they must be able to be run in any order (not dependent on each other), which can become a problem with singleton usage. Because the dependencies of some given methods aren't clear when they rely on singletons (getting them from static getters), a tester may unknowing write two tests that actually depend on each other by modifying a shared resource (the singleton). This can produce flaky tests, ones that pass when run in one order but fail when run in another, which aren't very useful.

Still not convinced? Well, this certainly wasn't originally my idea, and it's not even that new. If you're looking for some more compelling arguments, check out some of these sources:

All pages with Singleton in their title at the Portland Pattern Repository Wiki

Use Your Singletons Wisely (IBM developerWorks)

Comment by, Nov 3, 2007

In most cases a singleton is equivalent to a class consisting only of static attributes and methods. Why is this a bad smell to most developers, whereas the singleton isn't? Maybe because the latter is a well known pattern?

Comment by, Feb 13, 2008

No, with the latter you can take advantage of inheritance.

Comment by, May 25, 2008

Another problem with a static class implementation is that you may later find the need to change from having a single global instance to multiple context-based instances. With a static class, you will wind up having to rewrite a lot of static references in your code.

Comment by, Apr 23, 2009

singletons are definitely not a global var, singleton should be thread-safe, multi-thread-safe and synchronized, you may dream to accomplish this Job with global vars, especially if you have singletons in a shared Object(s)/Librarie(s).

this is by the way the definition of singleton design pattern, in Java and Objective-C it's really easy to accomplish and there is a big use of this pattern especially in Desktop Application. I n C++ it can be painful except with Boost :), there are several folks who wrote interesting stuff about singletons in C++, one of essential aspect of singleton pattern is the multi-thread support with a mutex/lock mechanism, the next version of STL/C++ should include this natively in the same way than Objective-C/ Class Struct where every Object has a mutex property.

And finally, to answer to the author, there is no controversial/trivial point, as Developer you are supposed to know what you are doing and understand basic OO design pattern if you do not, chose another Job! Code is really not for you.


Comment by, Apr 23, 2009

you may use OCaml and stop doing Java, it could help :), there are several developers who are using Singletons in a proper way, detect them if you want this is for me what you wrote, is useless, try to replace a brain by a poor parsing tool, LOL, it's like machine learning, it's totally void, we should spend this energy in other fields, like change the way we are building machine, change our electronic view, you will never accomplish such things on our actual tech, yes sure it's working a bit but comparison of the billions of $ put in this field...

Comment by, Sep 28, 2009

When one class references another class, it is coupled to that class, period. It does not matter if either class is a singleton. Coupling is unavoidable in software. You can not reduce it by avoiding the singleton pattern.

Further, the 'getInstance()' method of a singleton gives you a reference to an object. At that point, you don't care if the object is singleton or not, so long as it exposes it instance methods instead of statics.

There is a time and a place for singleton. The real problems with singletons are the problems with all statics - holding memory, synchronizing initialization and access, etc.

Comment by, Nov 19, 2009

Of course when one class references another, there's coupling. I think the issue with singletons is that their use can hide the particulars of those dependencies in multiple places within source code, making changes and testing much more difficult to deal with. That's what led to the rise of dependency injection's popularity in the Java world. Those dependencies are explicitly stated in the class definition, avoiding the use of any singletons behind the scenes. That means, for example, that it's easy to test a class that's dependent on a db and mail connection because you can set the connection references directly in a test class using either a test db or mail account, or a mocked connection. If you're using a singleton in your implementation without that kind of explicit dependency declaration, you don't know how or where the connection is coming from and it's difficult to swap out for testing purposes, let alone when implementation details change.

I think that singletons in and of themselves aren't bad, though. It's just that using them behind the scenes makes testing and debugging more difficult than it could be otherwise.

Comment by, Mar 18, 2010

IMHO singletons are not worth a discussion. Originally introduced as the small "1" annotation in UML diagrams and the like (where you need it) they were always present and known as "global variables". Since that was not possible anymore with Java, some strange implementation efforts have been started to compensate for that deficit - and they're still spreading to other languages. To me it seems like a competition of who's creating the most complex implementation available - unfortunately I did that myself 5-10 years ago. And excuses like "thread safety" - come on... do you really want a single synchronization point across all your threads?

Comment by, Jul 16, 2010

When I hear someone say Singletons are they way to go , they drop down a few points in my book.

The main problem is that they are EXTREMELY easy to misuse. The purpose of a Singleton is for a SINGLE point of class instantiation , but that begs the question , "how often do you 'accidently' create another instance of a class".

I was on one project where they were used for everything. Remote services , controlling views , controlling mediators , controlling mediator-view communication and more. Debugging and testing became impossible because the singletons where referenced amongst so many classes. Because of this , a test result using the singleton could not be taken seriously because during runtime , you could never be sure of the singleton's state and who/what was changing it.

TL;DR Singleton/Global variables are bad , it becomes hard to figure out their state during global execution.

Comment by, Sep 8, 2010

@drewmca "Of course when one class references another, there's coupling" which is why you shouldn't dependt on concrete implementations but interfaces/pure abstracts. The you can say well I could pass a singlton for a parameter then. Yes you could but then you have no need for the static getinstance method. You simply allocate the resposibility of creating the object to a specific entity. Adherring to SRP as a free gift

Comment by, Sep 8, 2010

@0xcafefeed: "singleton should be thread-safe, multi-thread-safe and synchronized" so because they are all that they can't also be global -ly available var -iable state? Those are not mutually exclusive concepts. The singleton pattern is a simpler way of slowing down the system by use of one sync point implementing syncronization for a collection of global var's

Comment by, Oct 16, 2010

If people really need global variables then create something to read/write a stream for them!

Seriously - need to store the "health" of a player?... ... writer it to disk using a "non-global" writing object and read it later on.

If you have lots of global variables as such and considering writing them , re-factor.

Comment by, Jul 8, 2011

I've seen couple of times singletons (as in usage, someSystem::getInstance()->method()) that later would need to become proper objects, such as:

Screen -> Split Screen (modern games) One Input Device -> Multiple Input devices (modern consoles) Camera -> Split Windows (an editor for example)
Some systems deal with this by allowing context or state switch (or preserving such), but these are adhoc, and not first class citizens (e.g. you communicate to them in a special way). OpenGL is example for that dealing with matrices, different contexts, etc. Or drive letters in Windows. It's a bit of a singleton, isn't it :) Actually multitons - a bunch of unneeded, and artificially limited resources (the number of letters in the alphabet), instead of properly named resource (URI, or Unix names) It seems to me, that acknowledging at the beginning that most of the things would not stay ONE, or accessed as ONE is better idea overall. As there is not one God :)

Comment by, Aug 16, 2011

The proper use of singletons and the most common design pattern is for managing the state and attributes of a scarce or limited resource that does not support concurrency. A Singleton is the only design pattern that can be used for such a requirement. As such, it is expected that the developer manage concurrency via thread safe management and control of the resource.

Comment by, Sep 12, 2011

It's a sad state of affairs, when so many software "engineers" actively advocate widespread use of global variables and even call it a "design pattern".

Comment by, Oct 26, 2011

First, there is no "global" method of singletons in Java, it is on a classloader basis. Second, thread-safe singletons can be created without synchronization. There are several ways of doing this. Third, most use cases for singletons can probably be implemented by passing instances created by a factory

Comment by, Oct 28, 2011

its depends on the demand of your design. Somtime you may need to use Singleton accross different process. For details refere to

Comment by, Jan 29, 2014
Comment by, Aug 31 (45 hours ago)

I never believed in love spells or magic until I met this spell caster once when i went to see my friend in Indian this year on a business summit. I meant a man who's name is Dr IKhine he is really powerful and could help cast spells to bring back one's gone, lost, misbehaving lover and magic money spell or spell for a good job or luck spell .I'm now happy & a living testimony cos the man i had wanted to marry left me 5 weeks before our wedding and my life was upside down cos our relationship has been on for 3years. I really loved him, but his mother was against us and he had no good paying job. So when i met this spell caster, i told him what happened and explained the situation of things to him. At first i was undecided,skeptical and doubtful, but i just gave it a try. And in 7 days when i returned to Canada, my boyfriend (now husband) called me by himself and came to me apologizing that everything had been settled with his mom and family and he got a new job interview so we should get married. I didn't believe it cos the spell caster only asked for my name and my boyfriends name and all i wanted him to do. Well we are happily married now and we are expecting our little kid, and my husband also got the new job and our lives became much better. His email is or call +237060552255

Sign in to add a comment
Powered by Google Project Hosting