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?

  • 3
    Singeltons are notorious for making unit tests harder to write. – Martin York Sep 24 '11 at 11:36
  • @Martin York: whatever your problems with singletons are, the problem is that this is not a singleton. – gnasher729 Mar 2 '20 at 20:26
  • @gnasher729 Nothing against singletons. Just pointing out common issue with them. – Martin York Mar 3 '20 at 0:15

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


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.


Remove the Singletons. Then your problem is solved.

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.