Re: Thread-safe Singleton Design Implementation

On Jul 31, 3:47 pm, David Gourley <d...@NOSPAM.gourley.plus.com>
wrote:


I don't see why this would happen; the pattern doesn't produce a
deeply nested call chain unless all classloading does on that
implementation. In fact, the call chain is longer by as little as just
1 stack frame:

public class Singleton1 {
    private static Singleton1 instance = null;
    private Singleton1 () { ... }
    public static Singleton1 getInstance () {
        synchronized (Singleton1.class) {
            if (instance == null) instance = new Singleton1();
            return instance;
        }
    }
}

The ... is in Singleton1.Singleton1() called from
Singleton1.getInstance()

public class Singleton2 {
    private static class SingletonHolder {
        public static final Singleton2 instance = new Singleton2();
    }
    Singleton2 () { ... }
    public static Singleton2 getInstance () { return
SingletonHolder.instance; }
}

The ... is in Singleton2.Singleton2() called from
SingletonHolder.<static initializer> called from
Singleton2.getInstance()

There may be a few more between getInstance and the static initializer
depending on how the class loading implementation you use works,
likely including a loadClass(), but if it's pathologically many the
class loading implementation you use ... well, to put it bluntly, it
fucking blows. It is likely to cause problems at any point in the code
that happens to trigger class loading, whether singleton-related or
not.

In particular, the complexity of the singleton class itself doesn't
contribute anything to the nesting depth of calls unless the class
loader is really brain-dead and does some sort of recursion instead of
iteration on its members. So if the maximum is, say, 32768 nested
method calls, you're no more likely to exceed that if Singleton2 has
dozens of fields and methods than if Singleton2 has only one field and
one method, assuming a sane classloader implementation.