Java: Lazy Initializing Singleton

Question

The pattern to create singletons seems to be something like:

public class Singleton {
    private static final Singleton instance = new Singleton();
    private Singleton(){
    }

    public static Singleton getInstance()
    {
        return instance;
    }
}

However my problem is how do you Unit with a class like this if the Singleton Constructor does something that is not unit test friendly e.g. calls external service , jndi lookup etc.

I would think i could refactor it like:

public class Singleton {
    private static Singleton instance;
    private Singleton(){
    }

    public synchronized static Singleton getInstance()
    {
        if(instance == null)
             instance = new Singleton();
        return instance;
    }

     //for the unit tests
     public static void setInstance(Singleton s)
     {
          instancce = s;
     }
}

The problem now is that just for unit testability I have forced the getInstance to be synchronized so just for testing aspect it will have a negative impact on the real application. Is there a way around it, it seems any other sort of lazy initialization will not work because of the broken nature of double locking pattern in java.

You have identified a key downside of the Singleton pattern: It locks you into a specific implementation of the Singleton interface. Yes, you can get around this in various ways, most terribly ugly. Instead, ask yourself if you really need a singleton at all. — hifier, May 01 '11 at 16:44
Why would you ever need lazy initialization past what Java already automatically provides for every type? — Lew Bloch, Jul 06 '16 at 21:39

Peter Lawrey · Answer 1 · 2017-01-15T21:57:58.240

You can use an enum as a Singleton

enum Singleton {
    INSTANCE;
}

Say your singleton does something undesirable in unit tests, you can;

// in the unit test before using the Singleton, or any other global flag.
System.setProperty("unit.testing", "true");

Singleton.INSTANCE.doSomething();

enum Singleton {
    INSTANCE;
    {
        if(Boolean.getBoolean("unit.testing")) {
           // is unit testing.
        } else {
           // normal operation.
        }
    }
}

Note: there is no synchronised blocks or explicit lock needed. The INSTANCE will not be loaded until the .class is accessed and not initialised until a member is used. provided you only use Singleton.INSTANCE and not Singleton.class there won't be a problem with the value used to initialise changing later.

Edit: if you use just the Singleton.class this might not initialise the class. It doesn't in this example on Java 8 update 112.

public class ClassInitMain {
    public static void main(String[] args) {
        System.out.println("Printing a class reference");
        Class clazz = Singleton.class;
        System.out.println("clazz = " + clazz);
        System.out.println("\nUsing an enum value");
        Singleton instance = Singleton.INSTANCE;
    }

    static enum Singleton {
        INSTANCE;

        Singleton() {
            System.out.println(getClass() + " initialised");
        }
    }
}

prints

Printing a class reference
clazz = class ClassInitMain$Singleton

Using an enum value
class ClassInitMain$Singleton initialised

The instance will be loaded even via a reference to `.class`, but not initialized. — Lew Bloch, Jan 13 '17 at 20:09
@LewBloch There might be JVMs where this happens, but Oracle JVM 8 update 112 doesn't. — Peter Lawrey, Jan 14 '17 at 10:32
Not correct. The JLS explains. The type loads on the reference to the `.class` literal, obviously, or else the literal wouldn't be in memory to reference in the first place. That will load the type, but not initialize it. You probably confused loading and initialization. — Lew Bloch, Jan 14 '17 at 15:53
Reference to the `.class` by itself was always enough to load a type, but according to the JLS going back to at least Java 1.4, was never supposed to trigger type initialization. Prior to Java 1.5 the Sun JVMs had a bug wherein such references in fact did trigger type initialization. They fixed that bug in Java 5, and since then that feature has worked according to spec. — Lew Bloch, Jan 15 '17 at 17:51
@LewBloch hmmm. I have reworded it as it was confusing I admit. — Peter Lawrey, Jan 15 '17 at 21:58

score 6 · Accepted Answer · answered Apr 30 '11 at 14:14

6

You could use the Factory pattern to create the singleton, and switch implementations depending on evironment.

Or, avoid using the singleton pattern, and use Dependency Injection instead.

answered Apr 30 '11 at 14:14

Joel

29,538
35
110
138

Lew Bloch · Answer 3 · 2017-01-13T20:07:30.177

4

Double-checked locking is broken in every language, not just Java.

I tend to eschew singletons, but you can use the holder pattern just fine if you need them, as recommended in Josh Bloch's Effective Java:

public class Foo
{
  static class Holder
  {
    static final Foo instance = new Foo();
  }

  public static Foo getInstance()
  {
    return Holder.instance;
  }

  private Foo()
  {
  }

  // ...
}

EDIT: Repaired the reference.

edited Jan 13 '17 at 20:07

answered Mar 20 '12 at 22:58

Lew Bloch

3,364
1
16
10

Although I mentioned the holder class solution to implementing singletons, that is nearly always overengineering. The simplest, most reliable, and nearly always correct approach is to define an enum with a single constant, as @Peter Lawrey pointed out. – Lew Bloch Jan 15 '17 at 17:47

score 2 · Answer 4 · answered Apr 30 '11 at 18:15

You can dependency inject the singleton instance, override the getInstance() from the unit test code, use aspect oriented programming to intercept the method call and return a different object, or use a tool like jmockit which lets you mock pretty much anything, including statics, final classes, constructors, and all the stuff people normally say is "untestable."

One approach I've taken in legacy systems (where I wanted to make something testable with a minimal impact on the system's architecture) was to modify the factory methods (getInstance) to check a system property for an alternate implementation that I would instantiate instead. This was set to an alternate, mock object in the unit test suite.

As for the "double checked locking is broken" statement, that's not really true anymore, if you use the volatile keyword, and Java >= 1.5. It was broken (even with volatile) with 1.4 and earlier, but if you know your code will be run on only recent JVMs, I wouldn't worry about it. But I also wouldn't use a singleton anyway: having a DI/IOC container manage the lifecycle of the object would solve both of your problems (testability and synchronized accessor bottleneck) much more elegantly.

hmm I like the idea of a System Property which could flag for unit testing. Ideally it would be nice to change to not use the Singleton but that its a bit above me , large old code base and no time to re-factor :(. — bluphoenix, May 01 '11 at 12:11

score 0 · Answer 5 · answered Apr 30 '11 at 19:17

How about you lazy initialize in the build phase where you execute the unit tests. Then you change the code back to inline initialize before it's compiled for distribution.

Your production code is inline initialized, except during your tests. Perhaps this discrepancy btw production and testing code could introdude bugs, but which?

(Of course if this is a solution, we let a build phase + tool do the work. I see this facilitated with maven and dp4j).

Java: Lazy Initializing Singleton

5 Answers5

Linked

Related