Singleton How should it be used

Question

Edit     From another question I provided an answer that has links to a lot of questions answers about singletons  More info about singletons here   So I have read the thread Singletons  good design or a crutch  And the argument still rages   I see Singletons as a Design Pattern  good and bad   The problem with Singleton is not the Pattern but rather the users  sorry everybody   Everybody and their father thinks they can implement one correctly  and from the many interviews I have done  most people can t   Also because everybody thinks they can implement a correct Singleton they abuse the Pattern and use it in situations that are not appropriate  replacing global variables with Singletons     So the main questions that need to be answered are    When should you use a Singleton How do you implement a Singleton correctly   My hope for this article is that we can collect together in a single place  rather than having to google and search multiple sites  an authoritative source of when  and then how  to use a Singleton correctly  Also appropriate would be a list of Anti-Usages and common bad implementations explaining why they fail to work and for good implementations their weaknesses   So get the ball rolling  I will hold my hand up and say this is what I use but probably has problems  I like  Scott Myers  handling of the subject in his books  Effective C        Good Situations to use Singletons  not many           Logging frameworks   Thread recycling pools            C   Singleton    Limitation  Single Threaded Design    See  http   www aristeia com Papers DDJ Jul Aug 2004 revised pdf         For problems associated with locking in multi threaded applications       Limitation     If you use this Singleton  A  within a destructor of another Singleton  B     This Singleton  A  must be fully constructed before the constructor of  B     is called      class MySingleton       private             Private Constructor         MySingleton               Stop the compiler generating methods of copy the object         MySingleton MySingleton const amp  copy                 Not Implemented         MySingleton amp  operator  MySingleton const amp  copy      Not Implemented      public          static MySingleton amp  getInstance                            The only instance                Guaranteed to be lazy initialized                Guaranteed that it will be destroyed correctly             static MySingleton instance              return instance                 OK  Lets get some criticism and other implementations together   -

User · Answer

Because a singleton only allows one instance to be created it effectively controls instance replication  for example you d not need multiple instances of a lookup - a morse lookup map for example  thus wrapping it in a singleton class is apt  And just because you have a single instance of the class does not mean you are also limited on the number of references to that instance  You can queue calls to avoid threading issues  to the instance and effect changes necessary  Yes  the general form of a singleton is a globally public one  you can certainly modify the design to create a more access restricted singleton  I haven t tired this before but I sure know it is possible  And to all those who commented saying the singleton pattern is utterly evil  you should know this  yes it is evil if you do not use it properly or within it confines of effective functionality and predictable behavior  do not GENERALIZE

User · Answer

Because a singleton only allows one instance to be created it effectively controls instance replication  for example you d not need multiple instances of a lookup - a morse lookup map for example  thus wrapping it in a singleton class is apt  And just because you have a single instance of the class does not mean you are also limited on the number of references to that instance  You can queue calls to avoid threading issues  to the instance and effect changes necessary  Yes  the general form of a singleton is a globally public one  you can certainly modify the design to create a more access restricted singleton  I haven t tired this before but I sure know it is possible  And to all those who commented saying the singleton pattern is utterly evil  you should know this  yes it is evil if you do not use it properly or within it confines of effective functionality and predictable behavior  do not GENERALIZE

User · Answer

I use Singletons as an interview test   When I ask a developer to name some design patterns  if all they can name is Singleton  they re not hired

User · Answer

One thing with patterns  don t generalize  They have all cases when they re useful  and when they fail   Singleton can be nasty when you have to test the code  You re generally stuck with one instance of the class  and can choose between opening up a door in constructor or some method to reset the state and so on   Other problem is that the Singleton in fact is nothing more than a global variable in disguise  When you have too much global shared state over your program  things tend to go back  we all know it   It may make dependency tracking harder  When everything depends on your Singleton  it s harder to change it  split to two  etc  You re generally stuck with it  This also hampers flexibility  Investigate some Dependency Injection framework to try to alleviate this issue

User · Answer

In desktop apps  I know  only us dinosaurs write these anymore   they are essential for getting relatively unchanging global application settings - the user language  path to help files  user preferences etc which would otherwise have to propogate into every class and every dialog   Edit - of course these should be read-only

User · Answer

Another implementation  class Singleton   public      static Singleton amp  Instance                    lazy initialize         if  instance     NULL  instance    new Singleton             return  instance          private      Singleton            static Singleton  instance

User · Answer

How do you implement a Singleton correctly      There s one issue I ve never seen mentioned  something I ran into at a previous job  We had C   singletons that were shared between DLLs  and the usual mechanics of ensuring a single instance of a class just don t work  The problem is that each DLL gets its own set of static variables  along with the EXE  If your get instance function is inline or part of a static library  each DLL will wind up with its own copy of the  singleton    The solution is to make sure the singleton code is only defined in one DLL or EXE  or create a singleton manager with those properties to parcel out instances

User · Answer

Singletons give you the ability to combine two bad traits in one class  That s wrong in pretty much every way   A singleton gives you    Global access to an object  and A guarantee that no more than one object of this type can ever be created   Number one is straightforward  Globals are generally bad  We should never make objects globally accessible unless we really need it   Number two may sound like it makes sense  but let s think about it  When was the last time you   accidentally  created a new object instead of referencing an existing one  Since this is tagged C    let s use an example from that language  Do you often accidentally write  std  ostream os  os  lt  lt   hello world n     When you intended to write  std  cout  lt  lt   hello world n     Of course not  We don t need protection against this error  because that kind of error just doesn t happen  If it does  the correct response is to go home and sleep for 12-20 hours and hope you feel better   If only one object is needed  simply create one instance  If one object should be globally accessible  make it a global  But that doesn t mean it should be impossible to create other instances of it   The  only one instance is possible  constraint doesn t really protect us against likely bugs  But it does make our code very hard to refactor and maintain  Because quite often we find out later that we did need more than one instance  We do have more than one database  we do have more than one configuration object  we do want several loggers  Our unit tests may want to be able to create and recreate these objects every test  to take a common example   So a singleton should be used if and only if  we need both the traits it offers   If we need global access  which is rare  because globals are generally discouraged  and we need to prevent anyone from ever creating more than one instance of a class  which sounds to me like a design issue   The only reason I can see for this is if creating two instances would corrupt our application state - probably because the class contains a number of static members or similar silliness  In which case the obvious answer is to fix that class  It shouldn t depend on being the only instance   If you need global access to an object  make it a global  like std  cout  But don t constrain the number of instances that can be created   If you absolutely  positively need to constrain the number of instances of a class to just one  and there is no way that creating a second instance can ever be handled safely  then enforce that  But don t make it globally accessible as well   If you do need both traits  then 1  make it a singleton  and 2  let me know what you need that for  because I m having a hard time imagining such a case

User · Answer

Modern C   Design by Alexandrescu has a thread-safe  inheritable generic singleton   For my 2p-worth  I think it s important to have defined lifetimes for your singletons  when it s absolutely necessary to use them    I normally don t let the static get   function instantiate anything  and leave set-up and destruction to some dedicated section of the main application   This helps highlight dependencies between singletons - but  as stressed above  it s best to just avoid them if possible

User · Answer

In desktop apps  I know  only us dinosaurs write these anymore   they are essential for getting relatively unchanging global application settings - the user language  path to help files  user preferences etc which would otherwise have to propogate into every class and every dialog   Edit - of course these should be read-only

User · Answer

Most people use singletons when they are trying to make themselves feel good about using a global variable  There are legitimate uses  but most of the time when people use them  the fact that there can only be one instance is just a trivial fact compared to the fact that it s globally accessible

User · Answer

Answer  Use a Singleton if   You need to have one and only one object of a type in system  Do not use a Singleton if   You want to save memory You want to try something new You want to show off how much you know Because everyone else is doing it  See cargo cult programmer in wikipedia  In user interface widgets It is supposed to be a cache In strings In Sessions I can go all day long  How to create the best singleton   The smaller  the better  I am a minimalist Make sure it is thread safe Make sure it is never null Make sure it is created only once Lazy or system initialization  Up to your requirements Sometimes the OS or the JVM creates singletons for you  e g  in Java every class definition is a singleton  Provide a destructor or somehow figure out how to dispose resources Use little memory

User · Answer

Singletons basically let you have complex global state in languages which otherwise make it difficult or impossible to have complex global variables   Java in particular uses singletons as a replacement for global variables  since everything must be contained within a class   The closest it comes to global variables are public static variables  which may be used as if they were global with import static  C   does have global variables  but the order in which constructors of global class variables are invoked is undefined   As such  a singleton lets you defer the creation of a global variable until the first time that variable is needed   Languages such as Python and Ruby use singletons very little because you can use global variables within a module instead   So when is it good bad to use a singleton   Pretty much exactly when it would be good bad to use a global variable

User · Answer

If you are the one who created the singleton and who uses it  dont make it as singleton  it doesn t have sense because you can control the singularity of the object without making it singleton  but it makes sense when you a developer of a library and you want to supply only one object to your users  in this case you are the who created the singleton  but you aren t the user    Singletons are objects so use them as objects  many people accesses to singletons directly through calling the method which returns it  but this is harmful because you are making your code knows that object is singleton  I prefer to use singletons as objects  I pass them through the constructor and I use them as ordinary objects  by that way  your code doesn t know if these objects are singletons or not and that makes the dependencies more clear and it helps a little for refactoring

User · Answer

Another implementation  class Singleton   public      static Singleton amp  Instance                    lazy initialize         if  instance     NULL  instance    new Singleton             return  instance          private      Singleton            static Singleton  instance

User · Answer

Modern C   Design by Alexandrescu has a thread-safe  inheritable generic singleton   For my 2p-worth  I think it s important to have defined lifetimes for your singletons  when it s absolutely necessary to use them    I normally don t let the static get   function instantiate anything  and leave set-up and destruction to some dedicated section of the main application   This helps highlight dependencies between singletons - but  as stressed above  it s best to just avoid them if possible

User · Answer

Singletons are handy when you ve got a lot code being run when you initialize and object   For example  when you using iBatis when you setup a persistence object it has to read all the configs  parse the maps  make sure its all correct  etc   before getting to your code   If you did this every time  performance would be much degraded   Using it in a singleton  you take that hit once and then all subsequent calls don t have to do it

User · Answer

I use Singletons as an interview test   When I ask a developer to name some design patterns  if all they can name is Singleton  they re not hired

User · Answer

Most people use singletons when they are trying to make themselves feel good about using a global variable  There are legitimate uses  but most of the time when people use them  the fact that there can only be one instance is just a trivial fact compared to the fact that it s globally accessible

User · Answer

Modern C   Design by Alexandrescu has a thread-safe  inheritable generic singleton   For my 2p-worth  I think it s important to have defined lifetimes for your singletons  when it s absolutely necessary to use them    I normally don t let the static get   function instantiate anything  and leave set-up and destruction to some dedicated section of the main application   This helps highlight dependencies between singletons - but  as stressed above  it s best to just avoid them if possible

User · Answer

The problem with singletons is not their implementation   It is that they conflate two different concepts  neither of which is obviously desirable   1  Singletons provide a global access mechanism to an object   Although they might be marginally more threadsafe or marginally more reliable in languages without a well-defined initialization order  this usage is still the moral equivalent of a global variable   It s a global variable dressed up in some awkward syntax  foo  get instance   instead of g foo  say   but it serves the exact same purpose  a single object accessible across the entire program  and has the exact same drawbacks   2  Singletons prevent multiple instantiations of a class   It s rare  IME  that this kind of feature should be baked into a class   It s normally a much more contextual thing  a lot of the things that are regarded as one-and-only-one are really just happens-to-be-only-one   IMO a more appropriate solution is to just create only one instance--until you realize that you need more than one instance

User · Answer

Modern C   Design by Alexandrescu has a thread-safe  inheritable generic singleton   For my 2p-worth  I think it s important to have defined lifetimes for your singletons  when it s absolutely necessary to use them    I normally don t let the static get   function instantiate anything  and leave set-up and destruction to some dedicated section of the main application   This helps highlight dependencies between singletons - but  as stressed above  it s best to just avoid them if possible

User · Answer

As others have noted  major downsides to singletons include the inability to extend them  and losing the power to instantiate more than one instance  e g  for testing purposes   Some useful aspects of singletons    lazy or upfront instantiation handy for an object which requires setup and or state   However  you don t have to use a singleton to get these benefits  You can write a normal object that does the work  and then have people access it via a factory  a separate object   The factory can worry about only instantiating one  and reusing it  etc   if need be  Also  if you program to an interface rather than a concrete class  the factory can use strategies  i e  you can switch in and out various implementations of the interface    Finally  a factory lends itself to dependency injection technologies like Spring etc

User · Answer

In desktop apps  I know  only us dinosaurs write these anymore   they are essential for getting relatively unchanging global application settings - the user language  path to help files  user preferences etc which would otherwise have to propogate into every class and every dialog   Edit - of course these should be read-only

User · Answer

The Meyers singleton pattern works well enough most of the time  and on the occasions it does it doesn t necessarily pay to look for anything better  As long as the constructor will never throw and there are no dependencies between singletons   A singleton is an implementation for a globally-accessible object  GAO from now on  although not all GAOs are singletons    Loggers themselves should not be singletons but the means to log should ideally be globally-accessible  to decouple where the log message is being generated from where or how it gets logged   Lazy-loading   lazy evaluation is a different concept and singleton usually implements that too  It comes with a lot of its own issues  in particular thread-safety and issues if it fails with exceptions such that what seemed like a good idea at the time turns out to be not so great after all   A bit like COW implementation in strings    With that in mind  GOAs can be initialised like this   namespace    T1   pt1   NULL  T2   pt2   NULL  T3   pt3   NULL  T4   pt4   NULL      int main  int argc  char  argv         T1 t1 args1      T2 t2 args2      T3 t3 args3      T4 t4 args4       pt1    amp t1     pt2    amp t2     pt3    amp t3     pt4    amp t4      dostuff        T1 amp  getT1        return  pt1     T2 amp  getT2        return  pt2     T3 amp  getT3       return  pt3     T4 amp  getT4       return  pt4      It does not need to be done as crudely as that  and clearly in a loaded library that contains objects you probably want some other mechanism to manage their lifetime   Put them in an object that you get when you load the library     As for when I use singletons  I used them for 2 things - A singleton table that indicates what libraries have been loaded with dlopen - A message handler that loggers can subscribe to and that you can send messages to  Required specifically for signal handlers

User · Answer

I think this is the most robust version for C    using System  using System Collections  using System Threading   namespace DoFactory GangOfFour Singleton RealWorld         MainApp test application    class MainApp         static void Main               LoadBalancer b1   LoadBalancer GetLoadBalancer          LoadBalancer b2   LoadBalancer GetLoadBalancer          LoadBalancer b3   LoadBalancer GetLoadBalancer          LoadBalancer b4   LoadBalancer GetLoadBalancer              Same instance        if  b1    b2  amp  amp  b2    b3  amp  amp  b3    b4                  Console WriteLine  Same instance n                      All are the same instance -- use b1 arbitrarily          Load balance 15 server requests       for  int i   0  i  lt  15  i                    Console WriteLine b1 Server                     Wait for user       Console Read                         Singleton     class LoadBalancer         private static LoadBalancer instance      private ArrayList servers   new ArrayList         private Random random   new Random            Lock synchronization object     private static object syncLock   new object            Constructor  protected      protected LoadBalancer                  List of available servers       servers Add  ServerI          servers Add  ServerII          servers Add  ServerIII          servers Add  ServerIV          servers Add  ServerV               public static LoadBalancer GetLoadBalancer                  Support multithreaded applications through           Double checked locking  pattern which  once          the instance exists  avoids locking each          time the method is invoked       if  instance    null                  lock  syncLock                      if  instance    null                          instance   new LoadBalancer                                         return instance                Simple  but effective random load balancer      public string Server             get                 int r   random Next servers Count           return servers r  ToString                          Here is the  NET-optimised version   using System  using System Collections   namespace DoFactory GangOfFour Singleton NETOptimized         MainApp test application    class MainApp          static void Main               LoadBalancer b1   LoadBalancer GetLoadBalancer          LoadBalancer b2   LoadBalancer GetLoadBalancer          LoadBalancer b3   LoadBalancer GetLoadBalancer          LoadBalancer b4   LoadBalancer GetLoadBalancer              Confirm these are the same instance       if  b1    b2  amp  amp  b2    b3  amp  amp  b3    b4                  Console WriteLine  Same instance n                      All are the same instance -- use b1 arbitrarily          Load balance 15 requests for a server       for  int i   0  i  lt  15  i                    Console WriteLine b1 Server                     Wait for user       Console Read                        Singleton    sealed class LoadBalancer            Static members are lazily initialized          NET guarantees thread safety for static initialization     private static readonly LoadBalancer instance         new LoadBalancer         private ArrayList servers   new ArrayList        private Random random   new Random            Note  constructor is private      private LoadBalancer                  List of available servers       servers Add  ServerI          servers Add  ServerII          servers Add  ServerIII          servers Add  ServerIV          servers Add  ServerV               public static LoadBalancer GetLoadBalancer               return instance                Simple  but effective load balancer     public string Server             get                 int r   random Next servers Count           return servers r  ToString                          You can find this pattern at dotfactory com

User · Answer

The first example isn t thread safe - if two threads call getInstance at the same time  that static is going to be a PITA   Some form of mutex would help

User · Answer

I still don t get why a singleton has to be global    I was going to produce a singleton where I hid a database inside the class as a private constant static variable and make class functions that utilize the database without ever exposing the database to the user   I don t see why this functionality would be bad

User · Answer

I use Singletons as an interview test   When I ask a developer to name some design patterns  if all they can name is Singleton  they re not hired

User · Answer

One thing with patterns  don t generalize  They have all cases when they re useful  and when they fail   Singleton can be nasty when you have to test the code  You re generally stuck with one instance of the class  and can choose between opening up a door in constructor or some method to reset the state and so on   Other problem is that the Singleton in fact is nothing more than a global variable in disguise  When you have too much global shared state over your program  things tend to go back  we all know it   It may make dependency tracking harder  When everything depends on your Singleton  it s harder to change it  split to two  etc  You re generally stuck with it  This also hampers flexibility  Investigate some Dependency Injection framework to try to alleviate this issue

User · Answer

One thing with patterns  don t generalize  They have all cases when they re useful  and when they fail   Singleton can be nasty when you have to test the code  You re generally stuck with one instance of the class  and can choose between opening up a door in constructor or some method to reset the state and so on   Other problem is that the Singleton in fact is nothing more than a global variable in disguise  When you have too much global shared state over your program  things tend to go back  we all know it   It may make dependency tracking harder  When everything depends on your Singleton  it s harder to change it  split to two  etc  You re generally stuck with it  This also hampers flexibility  Investigate some Dependency Injection framework to try to alleviate this issue

User · Answer

The Meyers singleton pattern works well enough most of the time  and on the occasions it does it doesn t necessarily pay to look for anything better  As long as the constructor will never throw and there are no dependencies between singletons   A singleton is an implementation for a globally-accessible object  GAO from now on  although not all GAOs are singletons    Loggers themselves should not be singletons but the means to log should ideally be globally-accessible  to decouple where the log message is being generated from where or how it gets logged   Lazy-loading   lazy evaluation is a different concept and singleton usually implements that too  It comes with a lot of its own issues  in particular thread-safety and issues if it fails with exceptions such that what seemed like a good idea at the time turns out to be not so great after all   A bit like COW implementation in strings    With that in mind  GOAs can be initialised like this   namespace    T1   pt1   NULL  T2   pt2   NULL  T3   pt3   NULL  T4   pt4   NULL      int main  int argc  char  argv         T1 t1 args1      T2 t2 args2      T3 t3 args3      T4 t4 args4       pt1    amp t1     pt2    amp t2     pt3    amp t3     pt4    amp t4      dostuff        T1 amp  getT1        return  pt1     T2 amp  getT2        return  pt2     T3 amp  getT3       return  pt3     T4 amp  getT4       return  pt4      It does not need to be done as crudely as that  and clearly in a loaded library that contains objects you probably want some other mechanism to manage their lifetime   Put them in an object that you get when you load the library     As for when I use singletons  I used them for 2 things - A singleton table that indicates what libraries have been loaded with dlopen - A message handler that loggers can subscribe to and that you can send messages to  Required specifically for signal handlers

User · Answer

As others have noted  major downsides to singletons include the inability to extend them  and losing the power to instantiate more than one instance  e g  for testing purposes   Some useful aspects of singletons    lazy or upfront instantiation handy for an object which requires setup and or state   However  you don t have to use a singleton to get these benefits  You can write a normal object that does the work  and then have people access it via a factory  a separate object   The factory can worry about only instantiating one  and reusing it  etc   if need be  Also  if you program to an interface rather than a concrete class  the factory can use strategies  i e  you can switch in and out various implementations of the interface    Finally  a factory lends itself to dependency injection technologies like Spring etc

User · Answer

Singletons basically let you have complex global state in languages which otherwise make it difficult or impossible to have complex global variables   Java in particular uses singletons as a replacement for global variables  since everything must be contained within a class   The closest it comes to global variables are public static variables  which may be used as if they were global with import static  C   does have global variables  but the order in which constructors of global class variables are invoked is undefined   As such  a singleton lets you defer the creation of a global variable until the first time that variable is needed   Languages such as Python and Ruby use singletons very little because you can use global variables within a module instead   So when is it good bad to use a singleton   Pretty much exactly when it would be good bad to use a global variable

User · Answer

Singletons are handy when you ve got a lot code being run when you initialize and object   For example  when you using iBatis when you setup a persistence object it has to read all the configs  parse the maps  make sure its all correct  etc   before getting to your code   If you did this every time  performance would be much degraded   Using it in a singleton  you take that hit once and then all subsequent calls don t have to do it

User · Answer

The first example isn t thread safe - if two threads call getInstance at the same time  that static is going to be a PITA   Some form of mutex would help

User · Answer

I find them useful when I have a class that encapsulates a lot of memory  For example in a recent game I ve been working on I have an influence map class that contains a collection of very large arrays of contiguous memory  I want that all allocated at startup  all freed at shutdown and I definitely want only one copy of it  I also have to access it from many places  I find the singleton pattern to be very useful in this case   I m sure there are other solutions but I find this one very useful and easy to implement

User · Answer

But when I need something like a Singleton  I often end up using a Schwarz Counter to instantiate it

User · Answer

Singletons basically let you have complex global state in languages which otherwise make it difficult or impossible to have complex global variables   Java in particular uses singletons as a replacement for global variables  since everything must be contained within a class   The closest it comes to global variables are public static variables  which may be used as if they were global with import static  C   does have global variables  but the order in which constructors of global class variables are invoked is undefined   As such  a singleton lets you defer the creation of a global variable until the first time that variable is needed   Languages such as Python and Ruby use singletons very little because you can use global variables within a module instead   So when is it good bad to use a singleton   Pretty much exactly when it would be good bad to use a global variable

User · Answer

I think this is the most robust version for C    using System  using System Collections  using System Threading   namespace DoFactory GangOfFour Singleton RealWorld         MainApp test application    class MainApp         static void Main               LoadBalancer b1   LoadBalancer GetLoadBalancer          LoadBalancer b2   LoadBalancer GetLoadBalancer          LoadBalancer b3   LoadBalancer GetLoadBalancer          LoadBalancer b4   LoadBalancer GetLoadBalancer              Same instance        if  b1    b2  amp  amp  b2    b3  amp  amp  b3    b4                  Console WriteLine  Same instance n                      All are the same instance -- use b1 arbitrarily          Load balance 15 server requests       for  int i   0  i  lt  15  i                    Console WriteLine b1 Server                     Wait for user       Console Read                         Singleton     class LoadBalancer         private static LoadBalancer instance      private ArrayList servers   new ArrayList         private Random random   new Random            Lock synchronization object     private static object syncLock   new object            Constructor  protected      protected LoadBalancer                  List of available servers       servers Add  ServerI          servers Add  ServerII          servers Add  ServerIII          servers Add  ServerIV          servers Add  ServerV               public static LoadBalancer GetLoadBalancer                  Support multithreaded applications through           Double checked locking  pattern which  once          the instance exists  avoids locking each          time the method is invoked       if  instance    null                  lock  syncLock                      if  instance    null                          instance   new LoadBalancer                                         return instance                Simple  but effective random load balancer      public string Server             get                 int r   random Next servers Count           return servers r  ToString                          Here is the  NET-optimised version   using System  using System Collections   namespace DoFactory GangOfFour Singleton NETOptimized         MainApp test application    class MainApp          static void Main               LoadBalancer b1   LoadBalancer GetLoadBalancer          LoadBalancer b2   LoadBalancer GetLoadBalancer          LoadBalancer b3   LoadBalancer GetLoadBalancer          LoadBalancer b4   LoadBalancer GetLoadBalancer              Confirm these are the same instance       if  b1    b2  amp  amp  b2    b3  amp  amp  b3    b4                  Console WriteLine  Same instance n                      All are the same instance -- use b1 arbitrarily          Load balance 15 requests for a server       for  int i   0  i  lt  15  i                    Console WriteLine b1 Server                     Wait for user       Console Read                        Singleton    sealed class LoadBalancer            Static members are lazily initialized          NET guarantees thread safety for static initialization     private static readonly LoadBalancer instance         new LoadBalancer         private ArrayList servers   new ArrayList        private Random random   new Random            Note  constructor is private      private LoadBalancer                  List of available servers       servers Add  ServerI          servers Add  ServerII          servers Add  ServerIII          servers Add  ServerIV          servers Add  ServerV               public static LoadBalancer GetLoadBalancer               return instance                Simple  but effective load balancer     public string Server             get                 int r   random Next servers Count           return servers r  ToString                          You can find this pattern at dotfactory com

User · Answer

I find them useful when I have a class that encapsulates a lot of memory  For example in a recent game I ve been working on I have an influence map class that contains a collection of very large arrays of contiguous memory  I want that all allocated at startup  all freed at shutdown and I definitely want only one copy of it  I also have to access it from many places  I find the singleton pattern to be very useful in this case   I m sure there are other solutions but I find this one very useful and easy to implement

User · Answer

Anti-Usage    One major problem with excessive singleton usage is that the pattern prevents easy extension and swapping of alternate implementations  The class-name is hard coded wherever the singleton is used

User · Answer

But when I need something like a Singleton  I often end up using a Schwarz Counter to instantiate it

User · Answer

The first example isn t thread safe - if two threads call getInstance at the same time  that static is going to be a PITA   Some form of mutex would help

User · Answer

Anti-Usage    One major problem with excessive singleton usage is that the pattern prevents easy extension and swapping of alternate implementations  The class-name is hard coded wherever the singleton is used

User · Answer

Singletons basically let you have complex global state in languages which otherwise make it difficult or impossible to have complex global variables   Java in particular uses singletons as a replacement for global variables  since everything must be contained within a class   The closest it comes to global variables are public static variables  which may be used as if they were global with import static  C   does have global variables  but the order in which constructors of global class variables are invoked is undefined   As such  a singleton lets you defer the creation of a global variable until the first time that variable is needed   Languages such as Python and Ruby use singletons very little because you can use global variables within a module instead   So when is it good bad to use a singleton   Pretty much exactly when it would be good bad to use a global variable

User · Answer

But when I need something like a Singleton  I often end up using a Schwarz Counter to instantiate it

User · Answer

How do you implement a Singleton correctly      There s one issue I ve never seen mentioned  something I ran into at a previous job  We had C   singletons that were shared between DLLs  and the usual mechanics of ensuring a single instance of a class just don t work  The problem is that each DLL gets its own set of static variables  along with the EXE  If your get instance function is inline or part of a static library  each DLL will wind up with its own copy of the  singleton    The solution is to make sure the singleton code is only defined in one DLL or EXE  or create a singleton manager with those properties to parcel out instances

User · Answer

The problem with singletons is not their implementation   It is that they conflate two different concepts  neither of which is obviously desirable   1  Singletons provide a global access mechanism to an object   Although they might be marginally more threadsafe or marginally more reliable in languages without a well-defined initialization order  this usage is still the moral equivalent of a global variable   It s a global variable dressed up in some awkward syntax  foo  get instance   instead of g foo  say   but it serves the exact same purpose  a single object accessible across the entire program  and has the exact same drawbacks   2  Singletons prevent multiple instantiations of a class   It s rare  IME  that this kind of feature should be baked into a class   It s normally a much more contextual thing  a lot of the things that are regarded as one-and-only-one are really just happens-to-be-only-one   IMO a more appropriate solution is to just create only one instance--until you realize that you need more than one instance

User · Answer

If you are the one who created the singleton and who uses it  dont make it as singleton  it doesn t have sense because you can control the singularity of the object without making it singleton  but it makes sense when you a developer of a library and you want to supply only one object to your users  in this case you are the who created the singleton  but you aren t the user    Singletons are objects so use them as objects  many people accesses to singletons directly through calling the method which returns it  but this is harmful because you are making your code knows that object is singleton  I prefer to use singletons as objects  I pass them through the constructor and I use them as ordinary objects  by that way  your code doesn t know if these objects are singletons or not and that makes the dependencies more clear and it helps a little for refactoring

User · Answer

Below is the better approach for implementing a thread safe singleton pattern with deallocating the memory in destructor itself  But I think the destructor should be an optional because singleton instance will be automatically destroyed when the program terminates    include lt iostream gt   include lt mutex gt   using namespace std  std  mutex mtx   class MySingleton  private      static MySingleton   singletonInstance      MySingleton         MySingleton    public      static MySingleton  GetInstance        MySingleton const MySingleton amp     delete      const MySingleton amp  operator  const MySingleton amp     delete      MySingleton MySingleton amp  amp  other  noexcept   delete      MySingleton amp  operator  MySingleton amp  amp  other  noexcept   delete      MySingleton  MySingleton  singletonInstance   nullptr  MySingleton  MySingleton       MySingleton   MySingleton        delete singletonInstance      MySingleton  MySingleton  GetInstance        if  singletonInstance    NULL           std  lock guard lt std  mutex gt  lock mtx           if  singletonInstance    NULL              singletonInstance   new MySingleton              return singletonInstance      Regarding the situations where we need to use singleton classes can be- If we want to maintain the state of the instance throughout the execution of the program If we are involved in writing into execution log of an application where only one instance of the file need to be used    and so on  It will be appreciable if anybody can suggest optimisation in my above code

User · Answer

The real downfall of Singletons is that they break inheritance  You can t derive a new class to give you extended functionality unless you have access to the code where the Singleton is referenced  So  beyond the fact the the Singleton will make your code tightly coupled  fixable by a Strategy Pattern     aka Dependency Injection  it will also prevent you from closing off sections of the code from revision  shared libraries    So even the examples of loggers or thread pools are invalid and should be replaced by Strategies

User · Answer

Singletons are handy when you ve got a lot code being run when you initialize and object   For example  when you using iBatis when you setup a persistence object it has to read all the configs  parse the maps  make sure its all correct  etc   before getting to your code   If you did this every time  performance would be much degraded   Using it in a singleton  you take that hit once and then all subsequent calls don t have to do it

User · Answer

I think this is the most robust version for C    using System  using System Collections  using System Threading   namespace DoFactory GangOfFour Singleton RealWorld         MainApp test application    class MainApp         static void Main               LoadBalancer b1   LoadBalancer GetLoadBalancer          LoadBalancer b2   LoadBalancer GetLoadBalancer          LoadBalancer b3   LoadBalancer GetLoadBalancer          LoadBalancer b4   LoadBalancer GetLoadBalancer              Same instance        if  b1    b2  amp  amp  b2    b3  amp  amp  b3    b4                  Console WriteLine  Same instance n                      All are the same instance -- use b1 arbitrarily          Load balance 15 server requests       for  int i   0  i  lt  15  i                    Console WriteLine b1 Server                     Wait for user       Console Read                         Singleton     class LoadBalancer         private static LoadBalancer instance      private ArrayList servers   new ArrayList         private Random random   new Random            Lock synchronization object     private static object syncLock   new object            Constructor  protected      protected LoadBalancer                  List of available servers       servers Add  ServerI          servers Add  ServerII          servers Add  ServerIII          servers Add  ServerIV          servers Add  ServerV               public static LoadBalancer GetLoadBalancer                  Support multithreaded applications through           Double checked locking  pattern which  once          the instance exists  avoids locking each          time the method is invoked       if  instance    null                  lock  syncLock                      if  instance    null                          instance   new LoadBalancer                                         return instance                Simple  but effective random load balancer      public string Server             get                 int r   random Next servers Count           return servers r  ToString                          Here is the  NET-optimised version   using System  using System Collections   namespace DoFactory GangOfFour Singleton NETOptimized         MainApp test application    class MainApp          static void Main               LoadBalancer b1   LoadBalancer GetLoadBalancer          LoadBalancer b2   LoadBalancer GetLoadBalancer          LoadBalancer b3   LoadBalancer GetLoadBalancer          LoadBalancer b4   LoadBalancer GetLoadBalancer              Confirm these are the same instance       if  b1    b2  amp  amp  b2    b3  amp  amp  b3    b4                  Console WriteLine  Same instance n                      All are the same instance -- use b1 arbitrarily          Load balance 15 requests for a server       for  int i   0  i  lt  15  i                    Console WriteLine b1 Server                     Wait for user       Console Read                        Singleton    sealed class LoadBalancer            Static members are lazily initialized          NET guarantees thread safety for static initialization     private static readonly LoadBalancer instance         new LoadBalancer         private ArrayList servers   new ArrayList        private Random random   new Random            Note  constructor is private      private LoadBalancer                  List of available servers       servers Add  ServerI          servers Add  ServerII          servers Add  ServerIII          servers Add  ServerIV          servers Add  ServerV               public static LoadBalancer GetLoadBalancer               return instance                Simple  but effective load balancer     public string Server             get                 int r   random Next servers Count           return servers r  ToString                          You can find this pattern at dotfactory com

User · Answer

I still don t get why a singleton has to be global    I was going to produce a singleton where I hid a database inside the class as a private constant static variable and make class functions that utilize the database without ever exposing the database to the user   I don t see why this functionality would be bad

User · Answer

The real downfall of Singletons is that they break inheritance  You can t derive a new class to give you extended functionality unless you have access to the code where the Singleton is referenced  So  beyond the fact the the Singleton will make your code tightly coupled  fixable by a Strategy Pattern     aka Dependency Injection  it will also prevent you from closing off sections of the code from revision  shared libraries    So even the examples of loggers or thread pools are invalid and should be replaced by Strategies

User · Answer

I use Singletons as an interview test   When I ask a developer to name some design patterns  if all they can name is Singleton  they re not hired

User · Answer

The problem with singletons is not their implementation   It is that they conflate two different concepts  neither of which is obviously desirable   1  Singletons provide a global access mechanism to an object   Although they might be marginally more threadsafe or marginally more reliable in languages without a well-defined initialization order  this usage is still the moral equivalent of a global variable   It s a global variable dressed up in some awkward syntax  foo  get instance   instead of g foo  say   but it serves the exact same purpose  a single object accessible across the entire program  and has the exact same drawbacks   2  Singletons prevent multiple instantiations of a class   It s rare  IME  that this kind of feature should be baked into a class   It s normally a much more contextual thing  a lot of the things that are regarded as one-and-only-one are really just happens-to-be-only-one   IMO a more appropriate solution is to just create only one instance--until you realize that you need more than one instance

User · Answer

Singletons are handy when you ve got a lot code being run when you initialize and object   For example  when you using iBatis when you setup a persistence object it has to read all the configs  parse the maps  make sure its all correct  etc   before getting to your code   If you did this every time  performance would be much degraded   Using it in a singleton  you take that hit once and then all subsequent calls don t have to do it

User · Answer

The problem with singletons is not their implementation   It is that they conflate two different concepts  neither of which is obviously desirable   1  Singletons provide a global access mechanism to an object   Although they might be marginally more threadsafe or marginally more reliable in languages without a well-defined initialization order  this usage is still the moral equivalent of a global variable   It s a global variable dressed up in some awkward syntax  foo  get instance   instead of g foo  say   but it serves the exact same purpose  a single object accessible across the entire program  and has the exact same drawbacks   2  Singletons prevent multiple instantiations of a class   It s rare  IME  that this kind of feature should be baked into a class   It s normally a much more contextual thing  a lot of the things that are regarded as one-and-only-one are really just happens-to-be-only-one   IMO a more appropriate solution is to just create only one instance--until you realize that you need more than one instance

User · Answer

But when I need something like a Singleton  I often end up using a Schwarz Counter to instantiate it

User · Answer

Anti-Usage    One major problem with excessive singleton usage is that the pattern prevents easy extension and swapping of alternate implementations  The class-name is hard coded wherever the singleton is used

User · Answer

Singletons give you the ability to combine two bad traits in one class  That s wrong in pretty much every way   A singleton gives you    Global access to an object  and A guarantee that no more than one object of this type can ever be created   Number one is straightforward  Globals are generally bad  We should never make objects globally accessible unless we really need it   Number two may sound like it makes sense  but let s think about it  When was the last time you   accidentally  created a new object instead of referencing an existing one  Since this is tagged C    let s use an example from that language  Do you often accidentally write  std  ostream os  os  lt  lt   hello world n     When you intended to write  std  cout  lt  lt   hello world n     Of course not  We don t need protection against this error  because that kind of error just doesn t happen  If it does  the correct response is to go home and sleep for 12-20 hours and hope you feel better   If only one object is needed  simply create one instance  If one object should be globally accessible  make it a global  But that doesn t mean it should be impossible to create other instances of it   The  only one instance is possible  constraint doesn t really protect us against likely bugs  But it does make our code very hard to refactor and maintain  Because quite often we find out later that we did need more than one instance  We do have more than one database  we do have more than one configuration object  we do want several loggers  Our unit tests may want to be able to create and recreate these objects every test  to take a common example   So a singleton should be used if and only if  we need both the traits it offers   If we need global access  which is rare  because globals are generally discouraged  and we need to prevent anyone from ever creating more than one instance of a class  which sounds to me like a design issue   The only reason I can see for this is if creating two instances would corrupt our application state - probably because the class contains a number of static members or similar silliness  In which case the obvious answer is to fix that class  It shouldn t depend on being the only instance   If you need global access to an object  make it a global  like std  cout  But don t constrain the number of instances that can be created   If you absolutely  positively need to constrain the number of instances of a class to just one  and there is no way that creating a second instance can ever be handled safely  then enforce that  But don t make it globally accessible as well   If you do need both traits  then 1  make it a singleton  and 2  let me know what you need that for  because I m having a hard time imagining such a case

User · Answer

Below is the better approach for implementing a thread safe singleton pattern with deallocating the memory in destructor itself  But I think the destructor should be an optional because singleton instance will be automatically destroyed when the program terminates    include lt iostream gt   include lt mutex gt   using namespace std  std  mutex mtx   class MySingleton  private      static MySingleton   singletonInstance      MySingleton         MySingleton    public      static MySingleton  GetInstance        MySingleton const MySingleton amp     delete      const MySingleton amp  operator  const MySingleton amp     delete      MySingleton MySingleton amp  amp  other  noexcept   delete      MySingleton amp  operator  MySingleton amp  amp  other  noexcept   delete      MySingleton  MySingleton  singletonInstance   nullptr  MySingleton  MySingleton       MySingleton   MySingleton        delete singletonInstance      MySingleton  MySingleton  GetInstance        if  singletonInstance    NULL           std  lock guard lt std  mutex gt  lock mtx           if  singletonInstance    NULL              singletonInstance   new MySingleton              return singletonInstance      Regarding the situations where we need to use singleton classes can be- If we want to maintain the state of the instance throughout the execution of the program If we are involved in writing into execution log of an application where only one instance of the file need to be used    and so on  It will be appreciable if anybody can suggest optimisation in my above code

User · Answer

The first example isn t thread safe - if two threads call getInstance at the same time  that static is going to be a PITA   Some form of mutex would help

User · Answer

One thing with patterns  don t generalize  They have all cases when they re useful  and when they fail   Singleton can be nasty when you have to test the code  You re generally stuck with one instance of the class  and can choose between opening up a door in constructor or some method to reset the state and so on   Other problem is that the Singleton in fact is nothing more than a global variable in disguise  When you have too much global shared state over your program  things tend to go back  we all know it   It may make dependency tracking harder  When everything depends on your Singleton  it s harder to change it  split to two  etc  You re generally stuck with it  This also hampers flexibility  Investigate some Dependency Injection framework to try to alleviate this issue

User · Answer

Answer  Use a Singleton if   You need to have one and only one object of a type in system  Do not use a Singleton if   You want to save memory You want to try something new You want to show off how much you know Because everyone else is doing it  See cargo cult programmer in wikipedia  In user interface widgets It is supposed to be a cache In strings In Sessions I can go all day long  How to create the best singleton   The smaller  the better  I am a minimalist Make sure it is thread safe Make sure it is never null Make sure it is created only once Lazy or system initialization  Up to your requirements Sometimes the OS or the JVM creates singletons for you  e g  in Java every class definition is a singleton  Provide a destructor or somehow figure out how to dispose resources Use little memory

User · Answer

In desktop apps  I know  only us dinosaurs write these anymore   they are essential for getting relatively unchanging global application settings - the user language  path to help files  user preferences etc which would otherwise have to propogate into every class and every dialog   Edit - of course these should be read-only

User · Answer

Answer  Use a Singleton if   You need to have one and only one object of a type in system  Do not use a Singleton if   You want to save memory You want to try something new You want to show off how much you know Because everyone else is doing it  See cargo cult programmer in wikipedia  In user interface widgets It is supposed to be a cache In strings In Sessions I can go all day long  How to create the best singleton   The smaller  the better  I am a minimalist Make sure it is thread safe Make sure it is never null Make sure it is created only once Lazy or system initialization  Up to your requirements Sometimes the OS or the JVM creates singletons for you  e g  in Java every class definition is a singleton  Provide a destructor or somehow figure out how to dispose resources Use little memory

User · Answer

Answer  Use a Singleton if   You need to have one and only one object of a type in system  Do not use a Singleton if   You want to save memory You want to try something new You want to show off how much you know Because everyone else is doing it  See cargo cult programmer in wikipedia  In user interface widgets It is supposed to be a cache In strings In Sessions I can go all day long  How to create the best singleton   The smaller  the better  I am a minimalist Make sure it is thread safe Make sure it is never null Make sure it is created only once Lazy or system initialization  Up to your requirements Sometimes the OS or the JVM creates singletons for you  e g  in Java every class definition is a singleton  Provide a destructor or somehow figure out how to dispose resources Use little memory

User · Answer

I think this is the most robust version for C    using System  using System Collections  using System Threading   namespace DoFactory GangOfFour Singleton RealWorld         MainApp test application    class MainApp         static void Main               LoadBalancer b1   LoadBalancer GetLoadBalancer          LoadBalancer b2   LoadBalancer GetLoadBalancer          LoadBalancer b3   LoadBalancer GetLoadBalancer          LoadBalancer b4   LoadBalancer GetLoadBalancer              Same instance        if  b1    b2  amp  amp  b2    b3  amp  amp  b3    b4                  Console WriteLine  Same instance n                      All are the same instance -- use b1 arbitrarily          Load balance 15 server requests       for  int i   0  i  lt  15  i                    Console WriteLine b1 Server                     Wait for user       Console Read                         Singleton     class LoadBalancer         private static LoadBalancer instance      private ArrayList servers   new ArrayList         private Random random   new Random            Lock synchronization object     private static object syncLock   new object            Constructor  protected      protected LoadBalancer                  List of available servers       servers Add  ServerI          servers Add  ServerII          servers Add  ServerIII          servers Add  ServerIV          servers Add  ServerV               public static LoadBalancer GetLoadBalancer                  Support multithreaded applications through           Double checked locking  pattern which  once          the instance exists  avoids locking each          time the method is invoked       if  instance    null                  lock  syncLock                      if  instance    null                          instance   new LoadBalancer                                         return instance                Simple  but effective random load balancer      public string Server             get                 int r   random Next servers Count           return servers r  ToString                          Here is the  NET-optimised version   using System  using System Collections   namespace DoFactory GangOfFour Singleton NETOptimized         MainApp test application    class MainApp          static void Main               LoadBalancer b1   LoadBalancer GetLoadBalancer          LoadBalancer b2   LoadBalancer GetLoadBalancer          LoadBalancer b3   LoadBalancer GetLoadBalancer          LoadBalancer b4   LoadBalancer GetLoadBalancer              Confirm these are the same instance       if  b1    b2  amp  amp  b2    b3  amp  amp  b3    b4                  Console WriteLine  Same instance n                      All are the same instance -- use b1 arbitrarily          Load balance 15 requests for a server       for  int i   0  i  lt  15  i                    Console WriteLine b1 Server                     Wait for user       Console Read                        Singleton    sealed class LoadBalancer            Static members are lazily initialized          NET guarantees thread safety for static initialization     private static readonly LoadBalancer instance         new LoadBalancer         private ArrayList servers   new ArrayList        private Random random   new Random            Note  constructor is private      private LoadBalancer                  List of available servers       servers Add  ServerI          servers Add  ServerII          servers Add  ServerIII          servers Add  ServerIV          servers Add  ServerV               public static LoadBalancer GetLoadBalancer               return instance                Simple  but effective load balancer     public string Server             get                 int r   random Next servers Count           return servers r  ToString                          You can find this pattern at dotfactory com

User · Answer

The real downfall of Singletons is that they break inheritance  You can t derive a new class to give you extended functionality unless you have access to the code where the Singleton is referenced  So  beyond the fact the the Singleton will make your code tightly coupled  fixable by a Strategy Pattern     aka Dependency Injection  it will also prevent you from closing off sections of the code from revision  shared libraries    So even the examples of loggers or thread pools are invalid and should be replaced by Strategies

User · Answer

Anti-Usage    One major problem with excessive singleton usage is that the pattern prevents easy extension and swapping of alternate implementations  The class-name is hard coded wherever the singleton is used

User · Answer

The real downfall of Singletons is that they break inheritance  You can t derive a new class to give you extended functionality unless you have access to the code where the Singleton is referenced  So  beyond the fact the the Singleton will make your code tightly coupled  fixable by a Strategy Pattern     aka Dependency Injection  it will also prevent you from closing off sections of the code from revision  shared libraries    So even the examples of loggers or thread pools are invalid and should be replaced by Strategies

[c++] Singleton: How should it be used

Examples related to c++

Examples related to design-patterns

Examples related to singleton