Lets get the definition right. There is Singleton the design pattern (Notice the capital “S” as in name of something) and there is a singleton as in one of something (notice the lower case “s”). There is nothing wrong with having a single instance of a class, lots of reasons why you may want to do that. However, when I complain about the Singletons, I complain about the design pattern. Specifically: (1) private constructor and (2) global instance variable which refers to the singleton. So from now on when I say Singleton, I mean the design (anti)pattern.

I would say that at this point most developers recognize that global state is harmful to your application design. Singletons have global instance variable which points to the singleton. The instance is global. The trouble with global variables is that they are transitive. It is not just the global variable marked with static which is global but any other variable/object which is reachable by traversing the object graph. All of it is global! Singletons, usually are complex objects which contain a lot of state. As a result all of the state of Singleton is global as well. I like to say that “Singletons are global state in sheep’s clothing.” Most developers agree that global state is bad, but they love their Singletons.

The moment you traverse a global variable your API lies about its true dependencies (see: Singletons are Pathological Liars) The root problem is not the Singleton design pattern, the root problem here is the global reference to singleton. But the moment you get rid of the global variable you get rid of the Singleton design pattern. So from my point of view blaming Singletons or blaming global state is one and the same. You can’t have a Singleton design pattern and at the same time not have the global state.

Someone pointed out that any design pattern can be abused. I agree, but with Singleton design pattern, I don’t know how I can possibly use it in a good way. The global reference and hence the global state is ever so present. Now, in my line of work I don’t see too much global state in classical sense of the word, but I see a lot of global state masquerading as Singletons. Hence, I complain about Singletons. If I would complain about global state no one would care, as that is old news.

Now, there is one kind of Singleton which is OK. That is a singleton where all of the reachable objects are immutable. If all objects are immutable than Singleton has no global state, as everything is constant. But it is so easy to turn this kind of singleton into mutable one, it is very slippery slope. Therefore, I am against these Singletons too, not because they are bad, but because it is very easy for them to go bad. (As a side note Java enumeration are just these kind of singletons. As long as you don’t put state into your enumeration you are OK, so please don’t.)

The other kind of Singletons, which are semi-acceptable are those which don’t effect the execution of your code. Logging is perfect example. It is loaded with Singletons and global state. It is acceptable (as in it will not hurt you) because your application does not behave any different whether or not a given logger is enabled. The information here flows one way: From your application into the logger. Even thought loggers are global state since no information flows from loggers into your application, loggers are acceptable. You should still inject your logger if you want your test to assert that something is getting logged, but in general Loggers are not harmful despite being full of state.

So the root cause is “GLOBAL STATE!” Keep in mind that global state is transitive, so any object which is reachable from a global variable is global as well. It is not possible to have a Singleton and not have a global state. Therefore, Singleton design patter can not be used in “the right way.” Now you could have a immutable singleton, but outside of limited use as enumerations, they have little value. Most applications are full of Singletons which have lots of global state, and where the information flows both directions.

38 responses so far ↓

I must say I really like your posts on Singletons. I have come to detest the pattern as it makes it impossible to test code with. My answer for why people are using it, is because they are lazy. It is so much easier adding logic/data to a Singleton than making it separate and changing a lot of classes to get the data to the requesting class.

I can see how “Global State” impacts your desires for testability. However, appropriate use of “Global” or semi-Global states can greatly simplify the design of applications as well as improve reliability in performance.

In web applications, for instance, there is a natural “Global” state associated with a web request. In PHP that’s quite literally a global state, and in ASP.NET. For most web apps, you want “global” access to the ip address of the requestor and to the database connection that you’re using. People who are afraid of globals invariabily end up:

(i) creating ‘local’ database connections that are wasteful (I clocked one app that went down this road and ended up creating 300 connections to the same database to serve a request!) and make it difficult or impossible to use transactions in a correct manner
(ii) using the “sawzall antipattern” where they need to modify the signature of 15 methods so they can pass an object (like a database connection or the ip address of the requestor) from the place where it’s available to where it’s available. A one-line code change that one programmer could do in twenty minutes becomes a matter of 30 lines of code that cross several boundaries thus requiring three or four meetings to make the change.

It’s not always lazy to use global states: often it’s DRY and often it results in radically simpler code that lets you focus on the difficult parts of your work.

In my mind, the “root cause” of Singletons is the weakness of inheritance and polymorphism in mainstream languages where statics are concerned. That is, people often use Singletons where they really want to use a static class.

The Multiton pattern gives many of the benefits of Singletons while still having the ability to partition the application (for testability and other purposes.) See

I would like to politely disagree with you. Your counterexamples only stand to demonstrate that you have not yet understood what I am trying to get to.

1) Creating a new connection per request is dumb. I agree. You need to have a single object responsible for caching it. But that object should not be Singleton (global state) but a singleton (one instance).

2) I never heard of “sawzall” but I think I have seen it many times before, so I think I know what you are talking about, and yes it is an anti-pattern. See Breaking the law of Demeter When this happens you are doing dependency injection the wrong way.

3) A http request is not global, at best it is thread local. (otherwise you could not have multi-threaded request to your web server) However, using global state is wrong here as well. You can design a nice clean application without resorting to any of these.

Global state impacts: testability, understandability, maintainability, and scalability, and probably few other -abilities.

You can build apps global state free, and once you see those apps, the first thing you notice is just how clean the code is and you instantly fall in love with them.

You’ve done a lousy job explaining the difference between Singleton and singleton. Where does a singleton come from? How do you enforce the fact that there should be only one? IOW, how exactly does a Singleton differ from a singleton?

In any case, your original post was still HUGELY in error. If all of your Singleton examples actually were Singletons, none of the issues you pointed out would have occurred. The Singleton pattern IS a factory, and ensures none of the things you complain about can occur. The init() calls in your examples mean that you did NOT follow the pattern, and THAT is your problem.

I’m not arguing that the Singleton pattern doesn’t have issues, and isn’t over used by developers. But we can’t have that discussion until you’ve proven you understand the subject we’re talking about.

Yes, a singleton can be abused. Get over it, so can if statements. A few things often left out of the debate:

Singletons solves an important discovery and hence usability problem. If you, the designer of an application, decides there should only ever be one, but it can change, then you should be entitled to. Thank goodness a Swing app can only have one have one L&F at a time due to UIManager.getLookAndFeel.

Contrary to common belief, singletons are easily mockable by simply using a SPI approach (program to an interface). Let the classpatch do the depdendency injection rather than you having to add arbitrary layers of indirection in annotations or XML.

PS: For a post that goes to great length trying defining concept vs. pattern, I wonder why you would toss around the world “enumeration” so freely. An SE1.4 or ME developer will be thinking of java.util.Enumeration but I guess you really mean the SE5 enum construct.

A singleton is more of a service access point than it has anything to do with making sure there’s only one of something. So when you test simply set the instance you want the singleton to return so all test code works like normal. Only the test setup is different. Simple.

In this view a singleton is global for perfectly good reasons, it is supposed to be how independent modules access a shared service. The program startup environment can act as a factory setting the correct instance for the environment.

@Casper
Singletons and unnecessary global state are abused much more often than ‘if’ statements. I’d be interested in hearing how you use the classpath to mock and and to ensure cleanup of singletons in a testing context. Are you confusing “dependency injection” with some kind of “classpath constructor polymorphism”?

“Singletons and unnecessary global state are abused much more often than ‘if’ statements.”

Umm not so sure about that. I see an awful lot of ‘if’ being used in quadrupoled nested scopes, to handle null or because the developer have yet to see the OO polymorphism light. I’m surprised my RSS feed haven’t yet delivered an ‘if is evil’ heading although I expect when the singleton has been ponded enough that will come.

“Are you confusing ‘dependency injection’ with some kind of ‘classpath constructor polymorphism’?”

No I don’t believe I am, you just appear to acknowledge only to the Hollywood version (don’t call me, we’ll call you). With an SPI approach, dependency resolution is controlled by my Ant script (thus a test implementation of SomeService can differ from the real impl of it).

How would you implement the Swing L&F mechanism without global state? You agree that components would need somewhere to register themselves such as to receive notifications when a new L&F is set etc?

[...] test-doubles. (I know we can fight static with static, but we already said that global state is bad here, here and here). The reason we can’t test this is that the moment you execute the main method [...]

Singleton’s have concerned me for a while, but I think there is a way to fix the pattern. The original idea behind the pattern was that you would have a means of controlling the number of objects of a class that could be instantiated. For instance, if you have an object that gets exclusive access to some hardware device that can’t be shared within the process, you don’t want someone accidentally instantiating two instances.

However, if you ever call getInstance() more than once in your program, you end up just using singleton’s like global variables… and if you can remember to *not* call getInstance() more than once, than you really got no benefit over just calling a constructor only once. So proper use of the pattern with dependency injection negates the benefits of the pattern.

Maybe a pattern that would actually achieve the goal that singleton fails to achieve would be a one shot static factory. The first time you call CreateInstance() it succeeds, and on subsequent attempts it returns null.

The pros of this approach as I see it would be that you can easily control the number of objects, and increase the number of objects that can be created in the future for instance, if you decide to allow one object for each calling thread, or if you figure out a way to allow many objects to concurrently access a resource. Allow more objects just means relaxing the “call once” interface in a backwards compatible way.

The con is that one shot static factories themselves are inherrently stateful. However, if the created objects cannot safely coexist with other objects of the same class, than that statefulness already exists, but the one shot makes it exlicit and localizes the statefullness to the static factory method. In cases where you are only creating one instance for efficiency (i.e. a database connection) then I’m not sure if there is a strong case above simply remembering to only call the constructor once.

[...] the scope of this article, such as manage object lifetimes, enforce singletons (in a good way, see: Root Cause of Singletons and Singletons are Pathological Liars) and manage different configurations of your application [...]

[...] code execution remains the same. Enable it, same same. Misko puts it in the following way in Root Cause of Singletons, “The information here flows one way: From your application into the logger. Even though loggers [...]

[...] reading the article on Singletons (the design anti-pattern) and how they are really global variables and dependency injection suggestion to simply pass in the reference to the singleton in a [...]

having singletons in the global code is essential for the design of greater singleton truth. singletons are not all a controlled mechenism ,althought thought can be that if you use them well then good is explained, but if you do not like singletons then what [ no code ] that is not essential to what and how it is being used…

There is nothing in the description of the Singleton pattern which says you should have a “global instance variable” (your words) pointing to it. If you have implemented them this way then that’s your lookout, but what you are criticising is your implementation, not the pattern.

[...] NSNotificationCenter is basically a global context which is used by many classes. As Miško Hevery points out, global state makes testing hard. So if I decided to be pedantic about avoiding global state and [...]

Misko-Thanks for all of these posts and your Google Clean Code talks. I watched those first, and while I was convinced of the need to do as you explained, I didn’t see HOW. This series of blog posts with concrete examples has definitely helped me see ways to refactor away from Singletons. Thanks,Alan

Thank you Misko for great blog. I have never heard anyone explaining the difficult things you say like this. I just read it and it hits me like a thunder: “damn, he has got the point just-like-that while I couldn’t find it for long time” Keep dooing your great job, do not worry because all those guys who does not get the idea.

Whatever is absolutely correct. You have a problem with a particular Singleton implementation, not the Singleton design pattern. I’m going to assume that you don’t know the difference rather than that you are deliberately setting up a straw man.So, basically your Singleton implementation can be used as follows:singleton.init();singleton.do_something();That is you have a Singleton instance singleton that must have init() called before it can be used. This seems to be due to your desire for constructors to not actually construct objects. If you want to lazily construct your object, as long as you aren’t directly exposing your internals, there is no need for for users to explicitly do the initialization. In fact, such a requirement smells bad, you should make it difficult for users to misuse your code. Almost all implementations I’ve seen require you to call a method to get a reference to the singleton instance. In this method, init() is called if needed. With this pattern, the singleton instance can even expose its internals without worry of them not being initialized. That is, the above code would change tosingleton::instance().do_something();If you don’t want the instance() method, then as long as initialization is checked and done in each of the singleton’s methods and it doesn’t expose its internals you can have the interface that you wanted. That is, you could do:singleton.do_something();Either of these solutions completely solve your original complaint about the Singleton design pattern. Again, it seems your problem is with a particular implementation that with the pattern itself.

no, the issue I have with singletons is that they represent global state. You can call them whatever you want but the moment you access any abject through a global variable you will have an issue with testability and maintainability of the code. Moreover the globality is transitive, so once you get a hold of a global variable anything you can get a hold of from there is global as well. A single global variable can expose a large mutable state to an application which is global.

The rails is loaded with global state. Which is one reason why rails could not be multithreaded. It also makes it hard to know how to assert and reset state in rails, but luckily they have done most of the hard work in the test suites, so rails is testable despite their reliance on the global state.

yes, it is not valid. since it is accessing more then it “friends” the proper way would be to get postFactory injected into the constructor of the controller and then call postFactory.create(). But since Rails does not have a DI framework, it would be hard to do that in the current state of rails.

I agree that mutable global state is bad mainly for two reasons. 1) Since state can be changed, it creates a very vulnerable dependency among objects. 2) Testing becomes that much harder as you need to setup global state and isolation of global state is hard.

However, IMO Global state that is either immutable or provides just a common set of behavior is not an anti-pattern. Reason no. 1 becomes irrelevant since there is no state changing happening and hence vulnerability disappears. Global State still needs to be setup before every unit test. However isolation is not required.

In the case of Post.create, I guess its ok since it is just providing a behavior of inserting a record.
However, areas within rails where one can change the global configurations on the fly are ugly. These are classic mutable Global state which should be eliminated with DI pattern.

I was on the brink of implementing a singleton (yes, with a capital S) and happened upon your site and youtube videos. Supreme insight, great information.

Could you explain when one should realize that a singleton (with a _lower_ case s) is also bad? That is, designing your application so that certain pieces of the business logic are performed by an object that is instantiated only once. This, I grant, is harder to answer. But do you have some general advice?

One issue with lower-case singletons is threading and concurrency. In the following example, the concurrency is probably unavoidable. But perhaps in some instances, the concurrency could be avoided by not having a lower-case singleton object.

Using your video example of a house, door, and door knob, suppose there is another type of object, a Person object. Suppose we have two person objects, Harold and Lindsey. Normally, to enter the house, a Person object must
(1) unlock the door
(2) open the door
(3) close the door
calling the appropriate methods in the right order. A concurrency issue could occur if Harold and Lindsey both try to go through this sequence (certain safeguards could be put in place, but we all know how difficult threads are …)

So instead, we could say, “Let’s just make two instances of the same house”, and declare they are identical via some id or something like that. But the model is now detracting from the real world: there is really only one house!

Again, here, the concurrency is probably unavoidable, and there should really only be one instance of a house. But in other situations, should we instead avoid the lower-case singleton?