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

Should the singleton be designed so that it can be created and destroyed at any time in program or should it be created so that it is available in life-time of program. Which one is best practice? What are the advantages and disadvantages of both?
EDIT :- As per the link shared by Mat, the singleton should be static. But then what are the disadvantages of making it destroyable? One advantage is it memory can be saved when it is not useful.

share|improve this question
Thanks Mat. That was helpful. – Manoj R Dec 7 '12 at 8:28
Check out: – Loki Astari Dec 8 '12 at 4:41
Please, don't destroy the singleton. There's only one left. – Tulains Córdova Dec 8 '12 at 23:30

Whatever floats your boat.

If you need to destroy it (maybe to reclaim memory or maybe it has state that's no longer valid) you should do that.

If it holds state that's inconvenient to recreate on demand, you should keep it around.

If you have no particular reason to destroy it I think you should keep it around.

share|improve this answer

Singleton's introduce the same dependency as a global variable. Singleton's tend to introduce difficult to test implementations.

That said, I favor a singleton design that is implemented as a standard object. The singleton-ness of the object is an implementation detail where only one instance is created and made available.

The singleton instance is most often useful when it is lazily-constructed. That is only construct the object when it is needed.

The lazy instantiation of the object can often be used to help with testability of objects that are dependent on the singleton. For testing purposes you might introduce a mock object or alternative implementation that is instantiated.

Singleton's have there place in your toolbox. Understanding their limitations is important to using them successfully.

share|improve this answer

Singletons are completely appropriate solutions to some design problems. However, how the singleton is implemented matters here.

As a C# example,

public class MySingleton
    static MySingleton()
        Instance = new MySingleton();

    protected MySingleton()

    public MySingleton Instance
        protected set;

    //  Put public instance members and properties here.

Would be an example of a singleton that should never be destroyed. Its possible to have an internal static field to store the singleton reference, and to do a lazy instantiation if the internal value is null. But you then have to worry about ensuring singlethreaded access to test for null, potentially create and then obtain the singleton instance, just so you could free up the memory from this one object at some point.

It is really bad practice to create singletons by declaring the class static. It makes object destruction impossible, as well as making it a nightmare for mocking the interface in your unit tests.

share|improve this answer

A singleton should never be available, it's the definition of anti-pattern.

That said, the supposed benefit of the design is that it handles creation order and lifetime in such a way as to guarantee the thing always exists. Making it destroyable rather defeats the purpose.

share|improve this answer
Why is singleton the definition of an anti-pattern? – m3th0dman Dec 7 '12 at 15:49
@m3th0dman - SO question – Telastyn Dec 7 '12 at 16:18
I tend to disagree; I believe singletons are useful when properly used. Josh Bloch talks about the implementation in the great book Effective Java (if they were not to be used they would not have been placed there). They are present in frameworks (EJB 3 @Singleton annotation) and IDEs have generation facilities. – m3th0dman Dec 7 '12 at 17:27
@m3th0dman: an @Singleton is not the same as a static singleton, and doesn't have most of the downsides. It is only singleton in a single application session, and you can still instantiate it multiply or replace it for testing. Static singletons are evil! – Steven Schlansker Dec 7 '12 at 17:57
@Steven Schlansker: that's exactly the big tragedy of Singleton: most developers think it's defined by the static factory method, it's widely reviled because of the drawbacks of that design, but in the GoF book it all goes back to, the static factory was explicitly just an example of how access to a singleton might be implemented. – Michael Borgwardt Dec 7 '12 at 20:33

The best practice is just to not use a Singleton in the first place. But if you're going to use one, making it destroyable is even worse, and it's quite remarkable to have something worse than a regular Singleton.

share|improve this answer
I disagree. The main advantage of making it dynamically creatable and destroyable is that is that it makes it more likely you'll realize that it doesn't actually need to be a singleton. – Steven Burnap Dec 7 '12 at 17:48

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.