Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I am having a memory leak when running a test suite due to singleton objects are created and not cleared after each test case. And these singleton objects are holding references to heavy objects.

So I don't know if there is a better solution than clearing the singleton objects in the tearDown() methods in each test class!

What do you think?

share|improve this question
Singeltons are notorious for making unit tests harder to write. – Loki Astari Sep 24 '11 at 11:36
up vote 2 down vote accepted

typically, this means the singleton has outgrown its original intention, and should be made a standard object (read: not a singleton).

testability is one major reason. pains updating programs to use multiple instances are another. yet another: it's often a difficult bottleneck at execution. the singleton pattern is often overused, used for the wrong reasons, and leads to issues (like this).

so, you typically just make the object not function as a singleton anymore, or abstract its true shared exclusive data (if any) behind the interface of some class. this shared data and init/destroy sequence indicates that it is a singleton for the wrong reasons, or has grown to provide too much functionality.

as far as heavy objects: you can create initializers/constructors to support this use: ObjectWithMovie(movie)

if you absolutely need (often for historic reasons, unless your team continues to write singletons) a big blob of global mutable state (which is the current sum of your program's singletons and other global state), i prefer to make one class to hold these -- then the holder is the only singleton and responsible for initialization/destruction. then the complexity of your global shared state becomes more obvious (coincidentally, the reason many people don't like doing this).

anyways, the singleton is tough to test and from what i have seen, most uses have been made singletons for no good reason -- this is just becomes a pain when you need to test, reuse, extend, et cetera.

then you can happily execute all your tests (in parallel) without elaborate start up/tear down sequences.

good luck

share|improve this answer

So I don't know if there is a better solution than clearing the singleton objects in the tearDown() methods in each test class!!

Get rid of the singletons. Singletons are hard to test anyway (global state). Use dependency injection instead. Mock heavy objects with lightweight ones if you're still in trouble.

If you really can't get rid of those singletons, then try to "clear" them after each test. The "clear" needn't necessarily be in the tearDown() method, although it's a good place for such tasks.

share|improve this answer

Remove the Singletons. Then your problem is solved.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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