{"id":2124,"date":"2017-04-04T16:47:43","date_gmt":"2017-04-04T16:47:43","guid":{"rendered":"http:\/\/codethataint.com\/blog\/?p=2124"},"modified":"2024-11-07T10:28:01","modified_gmt":"2024-11-07T10:28:01","slug":"different-implementation-of-singleton-pattern","status":"publish","type":"post","link":"https:\/\/codethataint.com\/blog\/different-implementation-of-singleton-pattern\/","title":{"rendered":"Different Implementation of Singleton Pattern"},"content":{"rendered":"

When Singleton should be used?<\/strong>
\nSingleton should be used incase creation of Object is costly or heavy I.E. DBConnection. It should not be used if the Object is mutable.<\/p>\n

    \n
  1. Eager initialization<\/li>\n
  2. Lazy initialization<\/li>\n
  3. Static block initialization<\/li>\n
  4. Using Synchronized method<\/li>\n
  5. Using Synchronized block<\/li>\n
  6. Double Checked Locking<\/li>\n
  7. Enum Singleton<\/li>\n
  8. Initialization on demand holder idiom<\/li>\n<\/ol>\n

    3 Things are common across all singleton implementation<\/p>\n

    \nprivate constructor
    \npublic static getInstance Method
    \nprivate static instance field\n<\/p><\/blockquote>\n

    Eager initialization<\/strong>
    \nAn instance of Singleton Class is created at the time of class loading<\/p>\n

    EagerInitialized.java<\/strong><\/p>\n

    \r\npackage com.mugil.singleton;\r\n\r\npublic class EagerInitialized {\r\n\t\r\n\tprivate static final EagerInitialized instance = new EagerInitialized();\r\n\t\r\n\t\/\/Private Constructor\r\n\tprivate EagerInitialized()\r\n\t{\r\n\t}\r\n\t\r\n\tpublic static EagerInitialized getInstance()\r\n\t{\r\n         return instance;\r\n        }\t\r\n}\r\n<\/pre>\n
    Lazy Initialization<\/strong>
    \nWith lazy initialization you crate instance only when its needed and not when the class is loaded<\/p>\n
    LazyInitialized.java<\/strong><\/p>\n
    \r\npackage com.mugil.singleton;\r\n\r\npublic class LazyInitialized \r\n{\r\n\tpublic static  LazyInitialized instance = null; \r\n\t\r\n\tprivate LazyInitialized()\r\n\t{\r\n\t\t\r\n\t}\r\n\t\r\n\tpublic static LazyInitialized getInstance(){\r\n        if(instance == null){\r\n            instance = new LazyInitialized();\r\n        }\r\n        return instance;\r\n    }\r\n}\r\n<\/pre>\n
    Static Block Initialization<\/strong>
    \nStatic block initialization is similar to eager initialization, except that an instance of class is created in the static block that provides an option for exception handling.<\/p>\n
    StaticBlockInitialized.java<\/strong><\/p>\n
    \r\npackage com.mugil.singleton;\r\n\r\npublic class StaticBlockInitialized {\r\n\r\n\tprivate static StaticBlockInitialized instance;\r\n\r\n\tprivate StaticBlockInitialized() {\r\n\t}\r\n\r\n\t\/\/ Static block initialization for exception handling\r\n\tstatic {\r\n\t\ttry {\r\n\t\t\tinstance = new StaticBlockInitialized();\r\n\t\t} catch (Exception e) {\r\n\t\t\tthrow new RuntimeException("Exception occurred in creating singleton instance");\r\n\t\t}\r\n\t}\r\n\r\n\tpublic static StaticBlockInitialized getInstance() {\r\n\t\treturn instance;\r\n\t}\r\n}\r\n<\/pre>\n
    Using Synchronized Method<\/strong>
    \nThe easier way to create a thread-safe singleton class is to make the access method synchronized, so that only one thread can execute this method at a time.<\/p>\n
    ThreadSafeSing.java<\/strong><\/p>\n
    \r\npackage com.mugil.singleton;\r\n\r\npublic class ThreadSafeSing {\r\n\r\n    private static ThreadSafeSinginstance;\r\n    \r\n    private ThreadSafeSing(){}\r\n    \r\n    public static synchronized ThreadSafeSing getInstance(){\r\n        if(instance == null){\r\n            instance = new ThreadSafeSing();\r\n        }\r\n        return instance;\r\n    }    \r\n}\r\n<\/pre>\n
    Using Synchronized Block<\/strong>
    \nThe easier way to create a thread-safe singleton class is to make the access method synchronized, so that only one thread can execute this method at a time. Refer the link for the same Link<\/a><\/p>\n
    ThreadSafeSing.java<\/strong><\/p>\n
    \r\npackage com.mugil.singleton;\r\n\r\npublic class ThreadSafeSing {\r\n    private static ThreadSafeSinginstance;\r\n    \r\n    private ThreadSafeSing(){}\r\n    \r\n    public static ThreadSafeSing getInstance(){\r\n        Synchronized(ThreadSafeSing.class){ \r\n          if(instance == null){\r\n            instance = new ThreadSafeSing();\r\n          }\r\n        }\r\n        return instance;\r\n    }    \r\n}\r\n<\/pre>\n
    Double Checked Locking Singleton<\/strong>
    \nAbove Implementation of Singleton provides thread safety buy has a hit over performance. The performance hit happens when two threads try to get the instance of object in getInstance() method but only one is allowed within Synchronized block while the other needs to wait until the first is done checking irrespective of the instance is already created or not.<\/p>\n
    In the Below method of Implementing Singleton, we again use Synchronized Block but we do the check for the availability of the object instance even before taking lock.<\/p>\n
    DCCSingleton.java<\/strong><\/p>\n
    \r\npackage com.mugil.singleton;\r\n\r\npublic class DCCSingleton{\r\n\r\n    private static DCCSingletoninstance;\r\n    \r\n    private DCCSingleton(){}\r\n    \r\n   public static DCCSingleton getInstanceUsingDoubleLocking()\r\n   {\r\n    if(instance == null){\r\n        synchronized (DCCSingleton.class) {\r\n            if(instance == null){\r\n                instance = new DCCSingleton();\r\n            }\r\n        }\r\n    }\r\n    return instance;\r\n  }    \r\n}\r\n<\/pre>\n
    Refer the Link<\/a> for how Double Checked Locking works<\/p>\n
    ENUM Singleton<\/strong>
    \nenum fields are compile time constants, but they are instances of their enum type. And, they’re constructed when the enum type is referenced for the first time.
    \nENUMSingleton.java<\/strong>
    \nSimple Singleton using enum for DBConnection<\/p>\n
    \r\npublic enum EnumSingleton\r\n{\r\n    INSTANCE;\r\n\r\n    \/\/ instance vars, constructor\r\n    private final Connection connection;\r\n\r\n    private Singleton()\r\n    {\r\n        \/\/Initialize the connection\r\n        connection = DB.getConnection();\r\n    }\r\n\r\n    public Connection getConnection(){\r\n       return connection;\r\n    }\r\n\r\n    \/\/ Static getter\r\n    public static Singleton getInstance()\r\n    {\r\n        return INSTANCE;\r\n    }\r\n}\r\n<\/pre>\n
    The way it works we can either use getInstance() method or directly call EnumSingleton.INSTANCE to access connection Object.<\/p>\n
    The Connection can be created using the Below Code<\/p>\n
    \r\n  Connection Conn = Singleton.getInstance().getConnection();\r\n<\/pre>\n
    Minimal Implementation using ENUM<\/strong><\/p>\n
    \r\npublic enum MySingleton {\r\n  INSTANCE;   \r\n}\r\n<\/pre>\n
    In the above code we may get a doubt how the object is created as we have a empty private constructor which is never invoked?.<\/strong><\/p>\n
    The above code gets converted as one below. Above code has an implicit empty constructor. Lets make it explicit instead,<\/p>\n
    \r\npublic enum MySingleton {\r\n    INSTANCE;\r\n    private MySingleton() {\r\n        System.out.println("Here");\r\n    }\r\n}\r\n<\/pre>\n
    Now when we make a call as below the private constructor is invoked and object gets created<\/p>\n
    \r\npublic static void main(String[] args) {\r\n    System.out.println(MySingleton.INSTANCE);\r\n}\r\n<\/pre>\n
    Output<\/strong><\/p>\n
    \r\nHere\r\nINSTANCE\r\n<\/pre>\n
    Initialization on demand holder idiom<\/strong>
    \nHow it works?<\/strong><\/p>\n
      \n
    1. The Below implementation is a lazy loading and thread safe method of creating Singleton<\/li>\n
    2. On calling the getInstance() method the lazySingletonClass would be initialized which in turn makes the INSTANCE to be initialized.<\/li>\n
    3. Class initialization is inherently thread-safe and if you can have an object initialized on class initialization the object creation too are thread-safe.<\/li>\n
    4. Singleton instance variable will never be created and or initialized until getInstance() is invoked. And again since class initialization is thread-safe the instance variable of IntiailizationOnDemandClassholder will be loaded safely, once and is visible to all threads.<\/li>\n<\/ol>\n
      \r\npublic class Singleton {\r\n    private Singleton(){}\r\n\r\n    public static class lazySingletonClass{\r\n      private static final Singleton INSTANCE = new Singleton();\r\n    }\r\n\r\n    public Singleton getInstance(){\r\n        return lazySingletonClass.INSTANCE;\r\n    }\r\n}\r\n<\/pre>\n\n\n\n\n\n\n\n\n\n\n\n
      <\/th>\nWhen Object is Created<\/th>\nThread Safe<\/th>\nPerformance<\/th>\nComments<\/th>\n<\/tr>\n<\/thead>\n
      Eager Initialization<\/strong><\/td>\nObject Gets Created once the Class is Loaded<\/td>\nYes<\/td>\nBad<\/td>\nObject is created everytime when the class is accessed<\/td>\n<\/tr>\n
      Lazy Initialization<\/strong><\/td>\nObject is Created once required<\/td>\nNo<\/td>\n<\/td>\nIn lazy initialization you give a public API to get the instance. In multi-threaded environment it poses challenges to avoid unnecessary object creation<\/td>\n<\/tr>\n
      Static Block Initialization<\/strong><\/td>\nObject is Created once Static Block is loaded<\/td>\nYes<\/td>\nBad<\/td>\nNot a good idea to load resources from static block as it causes performance hit during app startup<\/td>\n<\/tr>\n
      Synchronized Method<\/strong><\/td>\nObject is Created once getInstance  is called<\/td>\nYes<\/td>\nBad<\/td>\nThread safety is guaranteed.Slow performance because of whole method  locking is done<\/td>\n<\/tr>\n
      Synchronized Block<\/strong><\/td>\nObject is Created once getInstance  is called<\/td>\nNo<\/td>\n<\/td>\nTwo singleton instances may be created when context switching happens after checking instance is null<\/td>\n<\/tr>\n
      Double Checked Locking<\/strong><\/td>\nObject is Created once getInstance  is called<\/td>\nYes<\/td>\nGood<\/td>\nInstance check is done twice<\/td>\n<\/tr>\n
      Enum Implementation<\/strong><\/td>\nObject Created using enum is referenced<\/td>\nYes<\/td>\nGood<\/td>\n<\/td>\n<\/tr>\n
      Initialization on demand holder idiom<\/strong><\/td>\nObject Created when static class is initiazlied by calling getInstance method<\/td>\nYes<\/td>\nGood<\/td>\nClass initialization is inherently thread-safe and if you can have an object initialized on class initialization the object creation too are thread-safe<\/td>\n<\/tr>\n<\/table>\n
      Note<\/strong>
      \nDont be confused between Class Loading and Initialization<\/em>. In the Initialization on demand holder<\/strong> method of singleton you can easily get confused as the static inner class wont be loaded when the outer class loads.   The implementation relies on the fact that during initialization phase of execution within the Java Virtual Machine (JVM) as specified by the Java Language Specification (JLS) When the class Singleton <\/strong>is loaded by the JVM, the class goes through initialization. Since the class does not have any static variables to initialize, the initialization completes trivially. The static class definition lazySingletonClass<\/strong>within it is not initialized until the JVM determines that lazySingletonClass<\/strong>must be executed. The static class lazySingletonClass<\/strong>is only executed when the static method getInstance is invoked on the class<\/p>\n
       The static class lazySingletonClass <\/strong>is only executed when the static method getInstance is invoked on the class Singleton <\/strong>, and the first time this happens the JVM will load and initialize the lazySingletonClass<\/strong> class. The initialization of the lazySingletonClass<\/strong>class results in static variable INSTANCE being initialized by executing the (private) constructor for the outer class Something. Since the class initialization phase is guaranteed by the JLS to be sequential, i.e., non-concurrent, no further synchronization is required in the static getInstance method during loading and initialization<\/p>\n","protected":false},"excerpt":{"rendered":"
      When Singleton should be used? Singleton should be used incase creation of Object is costly or heavy I.E. DBConnection. It should not be used if the Object is mutable. Eager initialization Lazy initialization Static block initialization Using Synchronized method Using Synchronized block Double Checked Locking Enum Singleton Initialization on demand holder idiom 3 Things are… Continue reading →<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[227,64],"tags":[],"class_list":["post-2124","post","type-post","status-publish","format-standard","hentry","category-singleton","category-design-patterns"],"_links":{"self":[{"href":"https:\/\/codethataint.com\/blog\/wp-json\/wp\/v2\/posts\/2124","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/codethataint.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/codethataint.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/codethataint.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/codethataint.com\/blog\/wp-json\/wp\/v2\/comments?post=2124"}],"version-history":[{"count":6,"href":"https:\/\/codethataint.com\/blog\/wp-json\/wp\/v2\/posts\/2124\/revisions"}],"predecessor-version":[{"id":5300,"href":"https:\/\/codethataint.com\/blog\/wp-json\/wp\/v2\/posts\/2124\/revisions\/5300"}],"wp:attachment":[{"href":"https:\/\/codethataint.com\/blog\/wp-json\/wp\/v2\/media?parent=2124"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/codethataint.com\/blog\/wp-json\/wp\/v2\/categories?post=2124"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/codethataint.com\/blog\/wp-json\/wp\/v2\/tags?post=2124"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}