Is this valid Singleton pattern logic

[Rajat Jindal]

Is the following code is valid Singleton Pattern code?? If yes.. why people use synchronized with getInstance() and make it more complex. Even I have seen research papers with blocks having double synchronized checks and why don't we initialize it at the time when class get loaded into memory as shown below.

class SingletonObj
{
     private static SingletonObj obj = new SingletonObj();

     private SingletonObj(){}

      public static SingletonObj getInstance()
      {
              return obj;
      }
}

[Luigi Plinge]

I don't know where you have seen "synchronized" used, but your code is just fine. You can also make the instance a "public static final" field, which is simpler.

But the preferred way of creating a singleton, according to Effective Java, is to use an enum:

public enum SingletonObj {
    INSTANCE;
    // methods here
}

[Matthew Brown]

The synchronization is only needed if you don't want to create the singleton up front - if you want to do lazy initialisation instead. Sometimes people do that because creating the object needs some information that isn't available straight away. (And sometimes people do it because they think it's better to wait till the object is needed to create it - though that's usually not true).

For most purposes, if you really need a singleton (and there are often better alternatives) your method is fine, and Luigi's is even simpler.

[Jeff Verdegan]

Matthew Brown wrote:The synchronization is only needed if you don't want to create the singleton up front - if you want to do lazy initialisation instead.

And there's never a good reason for that.

For most purposes, if you really need a singleton (and there are often better alternatives) your method is fine, and Luigi's is even simpler.

I kind of don't like the enum singleton pattern. It seems like abuse of enums to me. Probably I'm just stubborn though. I seem to gradually dislike it less as time goes by.

@OP: If you like the enum, use that, as it's about as simple as it can get. If you prefer to write a singleton without using the enum, the right way to do that is:

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

  public static Whatever getInstance() {
    return instance;
  }

  // rest of class
}

[Matthew Brown]

Jeff Verdegan wrote:

Matthew Brown wrote:The synchronization is only needed if you don't want to create the singleton up front - if you want to do lazy initialisation instead.

And there's never a good reason for that.

Almost never. As I said, there can be situations where the information needed to create it isn't available up front. I've seen those, but can't think of any examples at the moment (partly because it's so long since I've used a genuine singleton).

[Rob Spoor]

The helper class technique is a much easier way:

class LazySingletonObj  
{  
    private SingletonObj(){}  

    private static class LazySingletonHelper
    {
        private static final SingletonObj INSTANCE = new SingletonObj();
    }
  
    public static SingletonObj getInstance()  
    {  
        return LazySingletonHelper.INSTANCE;
    }  
}

This still uses lazy initialization (the helper class is only loaded when getInstance() is called for the first time), but because class loading is atomic there is no need for any synchronization. If you can't use enums for whatever reason then I prefer this way.

[Jeff Verdegan]

Matthew Brown wrote:

Jeff Verdegan wrote:

Matthew Brown wrote:The synchronization is only needed if you don't want to create the singleton up front - if you want to do lazy initialisation instead.

And there's never a good reason for that.

Almost never.

Nope. Never. In another thread here (maybe more than one), I laid out in detail the only situation in which lazy instantiation could be useful, and that situation only occurs if you have a design error to start with. I can't be bothered to look it up now, but if you're interested, if you search for my name and singleton, you may find it.

As I said, there can be situations where the information needed to create it isn't available up front.

Meaning what? When you go to use the class, it will be loaded and initialized and the instance created. If the information you need isn't available then, you can't use it, and if it is available, then the fact that you need it and you're ready to use it means it's worth the cost to get it.