Java Singleton explanation needed

Question

Usually I use the first implementation. Couple of days ago I found another. Can anyone explain me the difference between these 2 implementations ? The 2nd implementation is thread safe? What is the advantage of using inner class in the 2nd example?

//--1st Impl
public class Singleton{

      private static Singleton _INSTANCE;

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

//--2nd Impl
public class Singleton {
      private Singleton() {}

      private static class SingletonHolder { 
            private static final Singleton _INSTANCE = new Singleton();
      }

      public static Singleton getInstance() {
            return SingletonHolder._INSTANCE;
      }
}

You might be interested to check this one: http://www.ibm.com/developerworks/java/library/j-dcl/index.html — Vikdor, Dec 01 '12 at 04:28
Look, if you really need a singleton [***USE AN ENUM AND BE DONE WITH IT.***](http://stackoverflow.com/q/70689/139010) `` — Matt Ball, Dec 01 '12 at 04:30
I Thank for everyone. Now I can understand these 2 implementations. — sura2k, Dec 01 '12 at 04:51

score 7 · Accepted Answer · answered Dec 01 '12 at 04:27

7

The first implementation uses what is called a "double checked lock". This is a Very Bad Thing. It looks thread-safe, but in fact it is not.

The second implementation is, indeed, thread-safe.

The explanation for why the first implementation is broken is fairly involved, so I'd recommend you get a copy of Brian Goetz's Java Concurrency in Practice for a detailed explanation. The short version is that the compiler is allowed to assign the _INSTANCE variable before the constructor has completed, which can cause a second thread to see a partially-constructed object.

answered Dec 01 '12 at 04:27

Cameron Skinner

51,692
2
65
86

1

The first implementation can be _very_ easily made thread safe in Java 5+ with `volatile`. – Matt Ball Dec 01 '12 at 04:29
@MattBall: But as written it is not. – Cameron Skinner Dec 01 '12 at 04:31
1

Yes. But that's why you should avoid double-checked locking: it's too easy to screw it up. – Cameron Skinner Dec 01 '12 at 04:36
1

Why do we need to have a holder. Why cant we directly have this "private static final Singleton _INSTANCE = new Singleton();". It will still be singleton and initialized at same time – Jatin Dec 01 '12 at 05:04
@Jatin because it's too simple, people fear simple. – irreputable Dec 01 '12 at 05:16

Jatin · Answer 2 · 2012-12-01T04:33:38.810

3

The first implementation is only and only thread-safe if the _INSTANCE is made volatile. The second one is thread safe because the _INSTANCE is only initialized once the SingletonHolder is loaded by the class loader.

So when the inner class is accessed for the time (much later than the whole program was loaded), the class loader loads the inner-class and initializes the variable. So for any later access, the object is readily available Hence the method getInstance() is thread-safe.

The beauty of the second implementation, is you dont have to worry about synchronization or count as class loader does it for you

edited Dec 01 '12 at 04:33

answered Dec 01 '12 at 04:28

Jatin

31,116
15
98
163

No, the first is not. Double-checked locking is not thread-safe. – Cameron Skinner Dec 01 '12 at 04:28
It is @CameronSkinner given that the variable is made volatile – Jatin Dec 01 '12 at 04:31
2

Better. I didn't downvote, but I would be removing it if I had :) – Cameron Skinner Dec 01 '12 at 04:35
@Jatin: You explained it at the end. Thanks to you and Cameron! – sura2k Dec 01 '12 at 04:56

Evgeniy Dorofeev · Answer 3 · 2012-12-01T05:50:49.337

#1 is designed to ensure lazy initialization. But, in the given case, #2 ensures lazy initialization too. _INSTANCE is created only when Singleton.class is loaded, and Singleton.class is loaded on first invocation of getSingleton(). There is no other method in the class. No double checked locking needed. And of course in #1 _INSTANCE should be volatile.

Note: I do not agree that double checked locking is bad. When implemented correctly it may be very useful.

Daniel Pryden · Answer 4 · 2012-12-01T04:38:34.897

0

The first code snippet is an example of the double-checked locking idiom, which used to be quite popular but is now known to be unsafe and should never be used.

The second snippet uses the combination of the semantics of class loading and of the final keyword, as defined by the Java language specification, to ensure lazy initialization and thread safety, so it is much better.

edited Dec 01 '12 at 04:38

answered Dec 01 '12 at 04:30

Daniel Pryden

59,486
16
97
135

`final` doesn't ensure either lazy initialization or thread safety. The second implementation is taking advantage of the way class loading works. – Cameron Skinner Dec 01 '12 at 04:33
@CameronSkinner: yes, but the definite assignment semantics of `final` ensure that only one instance is ever assigned, and that the write is safely published to other threads. – Daniel Pryden Dec 01 '12 at 04:36
Fair enough. `final` still has nothing to do with laziness, however. – Cameron Skinner Dec 01 '12 at 04:37

Java Singleton explanation needed

4 Answers4