Singleton Class with Threads

[Vinney Shanmugam]

If a singleton is not thread safe, and two threads enter getInstance() at the same time, there are chances for getting two different objects, provided getInstance() is not synchronized. Is this true first of all. If so, how to recreate it? I did try with the below program,

   
package test.threads;

class SingleTonThreads {
   
   private SingleTonThreads(){      
   }
   
   static SingleTonThreads tstt;
   
   public static SingleTonThreads getInstance(){
      if(tstt ==  null) {
         tstt = new SingleTonThreads();
         return tstt;
      }
      return tstt;
   }
   
   void checkIt(){
      System.out.println(" method in singleton class " + this);
   }
}

public class TestSingleTonThreads{
   
   public static void main(String...vin) {
      
      Thread tt = new Thread(){
        public void run(){
           SingleTonThreads st = SingleTonThreads.getInstance();
           st.checkIt();
        }
      };
      
      Thread tt1 = new Thread(){
         public void run(){
            SingleTonThreads st = SingleTonThreads.getInstance();
            st.checkIt();
         }
       };
       
       tt.start();
       tt1.start();
   }   
}
 

and didn't see two different objects created,

Output is:
======
method in singleton class test.threads.SingleTonThreads@a90653
method in singleton class test.threads.SingleTonThreads@a90653

[Peter Taucher]

There're plenty of discussions around about Singletons ... with several methods of achieving thread safety. I'd go with the 'construct at first class instantiation instead of getInstance method'.

In your case in the 'getInstance' method you check if 'tstt' is null. If the current thread isn't able to do the check, the instantioation and leaving the method (returning the singleton object) at once it is possible for another thread to get another instance of the singleton class. Try following code:

/**
 * SingletonThreadSafetyDemo (SingletonThreadSafetyDemo.java)
 * @author peter.taucher
 * @since 09.06.2010
 */
public class SingletonThreadSafetyDemo
{
    public static void main( String[] args )
    {
        Thread t1 = new Thread()
        {
            public void run()
            {
                System.out.println( "UnsafeSingleton: " + UnsafeSingleton.getInstance() );
                System.out.println( "SaferSingleton: " + SaferSingleton.getInstance() );
                System.out.println( "DoubleCheckedLockingSingleton: " + DoubleCheckedLockingSingleton.getInstance() );
            }
        };
        
        Thread t2 = new Thread()
        {
            public void run()
            {
                System.out.println( "UnsafeSingleton: " + UnsafeSingleton.getInstance() );
                System.out.println( "SaferSingleton: " + SaferSingleton.getInstance() );
                System.out.println( "DoubleCheckedLockingSingleton: " + DoubleCheckedLockingSingleton.getInstance() );
            }
        };
        
        t1.start();
        t2.start();
    }
}

class UnsafeSingleton
{
    static UnsafeSingleton instance;
    
    public static UnsafeSingleton getInstance()
    {
        if ( instance == null )
        {
            Thread.yield(); // !! 
            
            instance = new UnsafeSingleton();
        }
        
        return instance;
    }
}

class SaferSingleton
{
    static SaferSingleton instance = new SaferSingleton();
    
    public static SaferSingleton getInstance()
    {
        return instance;
    }
}

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

[Jim Hoglund]

I don't understand the problem. Your singleton method seems to be working
fine. The two Thread objects, tt and tt1, each grab a reference to the same
SingltonThreads object. They each report this to you in the System.out.
Where do you see a problem?

Jim ... ...

[Peter Taucher]

The problem is, that it's not thread-safe. Look into my example. It could happen that the curren thread is suspendend exactly inside the if clause but before returning a new instance. Another thread also calling getInstance would also run into the if clause and both reads may get different instances.

[Jim Hoglund]

Okay I see. So synchronize getInstance() or just the if() block.
It's very tough to get the JVM to swap threads in a particular place
and to another specific place, so I would just accept the risk as real
and do the synchronization. Also, the extra return statement is not
needed. Thanks.

Jim ... ...

[Henry Wong]

Jim Hoglund wrote:
It's very tough to get the JVM to swap threads in a particular place
and to another specific place, so I would just accept the risk as real
and do the synchronization. Also, the extra return statement is not
needed. Thanks.

With modern processors, and how they all have multiple cores, it gets even more complicated. Don't think of it as having context switches that happen at particular locations. With these processors, the threads are truly running in parallel.

Henry

[Vinney Shanmugam]

Hi Peter,

Thanks for the sample code. That's what I exactly wanted to write and didn't think of Thread.yield(). Your code solved my problem and cleared the air.



Thanks.

[Lalit Mehra]

Henry Wong wrote:

Jim Hoglund wrote:
It's very tough to get the JVM to swap threads in a particular place
and to another specific place, so I would just accept the risk as real
and do the synchronization. Also, the extra return statement is not
needed. Thanks.

With modern processors, and how they all have multiple cores, it gets even more complicated. Don't think of it as having context switches that happen at particular locations. With these processors, the threads are truly running in parallel.

Henry

Yes Henry and moreover ... with more and more advanced core processors coming up in the future ... just imagine how wonderful it would be to program

[Jim Hoglund]

Henry : A question. How is the reality of multiprocessors reflected in Java 1.6,
and what do I need to know for about this for SCJP-6? Is it true that physically,
with multiple processors, there may be multiple threads running (with OS magic),
but logically, based on the language spec, thread behavior is as described above?

Jim ... ...

[R van Vliet]

Peter Taucher wrote:

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

Still broken i think, should be :

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

or ofcourse as was mentioned :

class EagerlyInitializedSingleton
{
    static EagerlyInitializedSingleton instance = new EagerlyInitializedSingleton() ;
    
    public static EagerlyInitializedSingleton getInstance()
    {
        return instance;
    }
}

[R van Vliet]

Jim Hoglund wrote:Henry : A question. How is the reality of multiprocessors reflected in Java 1.6,
and what do I need to know for about this for SCJP-6? Is it true that physically,
with multiple processors, there may be multiple threads running (with OS magic),
but logically, based on the language spec, thread behavior is as described above?

Jim ... ...

The language spec is not in the way of true thread concurrency, you just have to keep in mind that there are some things you have to take into account with problems such as the above. Due to writes potentially happening out of order on the CPU level double check locking can still fail unless you force the VM not to keep track of references/variables in a thread local way. The volatile keyword does just that in this case.

[Jim Hoglund]

Thanks. I have recently become a big fan of volatile and the "happens-before"
relationship that it guarantees. Have a great weekend!

Jim...

[Pat Farrell]

Any discussion of double checked access to singletons needs to point to a very nice, clear, article written by IBM thats shows how most "fixed" for singletons actually fail.

Double-checked locking and the Singleton pattern Note the subtitle of the article: "A comprehensive look at this broken programming idiom"

Its really a broken idiom, no matter that its described in the GOF book. I believe, very strongly, that Singletons are evil and should not be used, even with the "fixes" that the IBM article describes.

[Jim Hoglund]

Well I'm confused now. The IBM article by Peter Haggar claims that there is an unresolvable problem
with the singleton pattern. The foundation of his reasoning seems to be that "...thread B can preempt
thread A..." at certain critical moments, causing creation of more than one object, even if getInstance()
is synchronized. I suspect his conclusions, however, because the role of object locking in synchronized
methods is not discussed. If the Singleton class object will be locked before getInstance() can even
start, there can be no thread swaps; preventing preemption is the purpose of the lock. Am I missing
something here?

Jim ... ...

[Pat Farrell]

If you use his hack, which is to have a inner class called something like SingletonHelper, then the rules of Java say that the instance of the Helper has to be completed, so your code is then thread safe. So you have fixed the double-check thread problem, which is widespread in most attempts to "solve" the problem.

Then you have to look at the bigger issue. You have a thread safe approach to implement a Singleton, but should you? And there, the answer is NO. A singleton is really a big glob of application wide global data. This tends to greatly increase coupling between modules. It specifically makes proper unit testing nearly impossible. You can't test a unit when it depends on a wad of global data. The state of the unit is not bound up in the unit.

There are approaches to this, often described as "dependency injection" but I hate that term, as most of the web pages that attempt to define it make it a ton more complex than it needs to be, and thus it scares away programmers from using it. This makes them fall back into using Singletons, which makes unit testing impossible.

There are simple, clean solutions that can and should be used instead of the evil Singleton pattern.

[Mike Simmons]

Jim Hoglund wrote:Well I'm confused now. The IBM article by Peter Haggar claims that there is an unresolvable problem
with the singleton pattern.

No, he just says there's an unresolved problem with the double-checked locking idiom, which is one particular way of implementing a singleton. And he was quite correct back when this article was written in 2002. But the article is not correct now. The Java memory model was revised as of JDK 1.5, and using volatile with double-checked locking really does work. The brief editor's note referencing Brian Goetz' 2004 articles is also wrong - the referenced articles do not justify the flawed summary "the double-checked locking idiom is still broken under the new memory model". It's broken if you don't use volatile. It works fine if you do use volatile.

Jim Hoglund wrote:I suspect his conclusions, however, because the role of object locking in synchronized
methods is not discussed. If the Singleton class object will be locked before getInstance() can even
start, there can be no thread swaps; preventing preemption is the purpose of the lock. Am I missing
something here?

If you're locking the class object right at the outset of the getInstance() method, that's not double-checked locking - it's regular synchronization. It works, but it's more prone to bottleneck in cases of heavy thread contention. Which is a non-issue most of the time, but sometimes becomes a serious enough issue that people spend a lot of effort trying to avoid it.

I'm not a big fan of singletons - they were dreadfully overused ever since the Gang of Four book came out, and in many cases they're unnecessary or even counterproductive. And they were badly implemented for years. Double-checked locking, in particular, was a longtime source of bugs. Nonetheless, it is possible to use it in a thread-safe manner now. Whether you should, or whether you need a singleton at all, is another matter.

[Pat Farrell]

Mike Simmons wrote: they were dreadfully overused ever since the Gang of Four book came out, and in many cases they're unnecessary or even counterproductive.

Yes, the GoF book had some good stuff, but Singletons was not one of the good ideas.

I will argue that they are never necessary or even good. But that is a bit OT.

[Jim Hoglund]

Pat : I am not steeped in Java history, or tangled up in any of its
religious wars. (On JavaRanch some pretty strong feelings seem to
come out at times.) So I'm curious about problems with singletons.
Why should they be avoided?

Jim ... ...

[Pat Farrell]

Jim Hoglund wrote:So I'm curious about problems with singletons. Why should they be avoided?

I thought I did a good high level explanation of why just a few posts upthread.

We can go into more detail, but probably should start a fresh thread in a better section.