0

We had design patterns in school and learned the implementation of a singleton (lazy / not thread safe one) like this:

package com.crunchify.tutorials;
public class CrunchifySingleton {

    private static CrunchifySingleton instance = null;

    protected CrunchifySingleton() {
    }

    // Lazy Initialization (If required then only)
    public static CrunchifySingleton getInstance() {
        if (instance == null) {
            // Thread Safe. Might be costly operation in some case
            synchronized (CrunchifySingleton.class) {
                if (instance == null) {
                    instance = new CrunchifySingleton();
                }
            }
        }
        return instance;
    }
}

Now I found the implementation like this:

package com.crunchify.tutorials;

public class ThreadSafeSingleton {

    private static final Object instance = new Object();

    private ThreadSafeSingleton() {
    }

    // Runtime initialization
    // By defualt ThreadSafe
    public static Object getInstance() {
        return instance;
    }
}

Now I am wondering when the first implementation makes more sense to use, because according to http://crunchify.com/thread-safe-and-a-fast-singleton-implementation-in-java/ the second one is thread safe and needs less lines.

Gildraths
  • 376
  • 1
  • 10
  • 1
    Yes, but the second one isn't lazy. – Kayaman May 23 '16 at 13:54
  • @Kayaman what is the advantage when the singleton is lazy and not thread safe? That's what I'm not getting. Thank you for your answer! – Gildraths May 23 '16 at 13:55
  • 1
    The number of times that a singleton is really necessary is very small; the number of times that you actually need a lazily-initialized lazy singleton is even smaller again. – Andy Turner May 23 '16 at 13:56
  • 1
    "what is the advantage when the singleton is lazy and not thread safe?" It's an advantage when you want mutable global state and race conditions in your program. Y'know, when predictable behaviour just isn't exciting enough. – Andy Turner May 23 '16 at 13:57
  • This has often been discussed before. For example here http://stackoverflow.com/questions/70689/what-is-an-efficient-way-to-implement-a-singleton-pattern-in-java – D Levant May 23 '16 at 13:58
  • @AndyTurner I was using them for producer / consumer queues and for factories. Are those correct uses or would references have been better? – Gildraths May 23 '16 at 13:58
  • If you want a lazy one, why not a lazy *and* thread-safe one? The need for unsafe lazy singletons is like 0 (especially the version that you posted that tries but fails to be safe). – zapl May 23 '16 at 14:01
  • @zapl You mean the second version is not thread safe? According to the tutorial the Object is created at class-load time according to the link: http://crunchify.com/thread-safe-and-a-fast-singleton-implementation-in-java/ – Gildraths May 23 '16 at 14:08
  • The first one isn't. For non-obvious reasons: See "UnsafeDCLFactory" in http://shipilev.net/blog/2014/safe-public-construction/ - but there are both lazy and eager versions that are thread-safe. – zapl May 23 '16 at 14:23

2 Answers2

0

Difference is in the time singleton object is instantiated. Second snippet instantiates singleton object only once at class instantiation time. It is useful if no additional data required for this process. Note that if instantiation error occured (does not matter in that simple case: just Object) singleton class would not be available at all.

First snippet instantiates singleton object when it is being requested. You may modify that class to provide some mechanism to store any initialization data and/or catch instantiation errors.

S. Kadakov
  • 861
  • 1
  • 6
  • 15
0

how to prevent multiple instances of a Singleton due to whatever reasons. Double checked locking of Singleton is a way to ensure only one instance of Singleton class is created through application life cycle. As name suggests, in double checked locking, code checks for an existing instance of Singleton class twice with and without locking to double ensure that no more than one instance of singleton gets created.

Sumon Mal
  • 71
  • 4