Synchronization

[Vallabhaneni Suresh Kumar]

When would you use a synchronized method and when a synchronized block?

Thank you

[Seb Mathe]

I can give you the example of two implementations of the Singleton pattern

public class Singleton {
  private static Singleton instance = null;
  private Singleton() {
    // Constructor
  }
 
  //static getInstance() method
 
  //Singleton methods...
}

getInstance Option 1

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

getInstance Option 2

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

Both options will ensure that the Singleton's constructor will be called just one time.

With option 1, a lock is required every time the method getInstance is called, even if instance is not null.

With option 2, if instance has been created, no lock is required : the code seems to be more efficient.

Note that there are others problems with option 2 due to "out-of-order writes" but that's not the question...
[ September 29, 2005: Message edited by: Seb Mathe ]

[Henry Wong]

With option 2, if instance has been created, no lock is required : the code seems to be more efficient.

First, synchronization is now much more efficient. I would not worry about it too much anymore.

Second, while the code in option 2 will work in getting you a singleton, there is no guarantee that "if instance has been created, no lock is required". The reason is because the compiler will detect the common condition, and optimize it by moving the outer loop into the synchronization block. Search "double checked locking" for more information.

Henry

[Stan James]

How to choose between writing a synchronized method or a synchronized block?

A synchronized method syncs on the object instance that is running the method. This may not be the right level of granularity for some problems. It may block other threads for longer than really necessary. Static methods have no "this" and lock on the class which is even larger granularity.

A synchronized block specifies what object we lock on, so it can use "this" or any other object that happens to be shared by multiple threads, including a static variable shared by all instances of the class. We can have a short synchronized block in the middle of a long running method and only lock for that short amount of time.

At a rather deep theoretical level a synchronized method is leaky encapsulation because it "exposes the monitor" which bothers some people a lot more than it does me.

Any of those notions help?

[Seb Mathe]

Well, you confirm that optimizing is a diffucult thing for developers...

And I'm affraid that some commercial products implements Singleton pattern with "option 2"...

[Ernest Friedman-Hill]

Originally posted by Seb Mathe:
Well, you confirm that optimizing is a diffucult thing for developers...

And I'm affraid that some commercial products implements Singleton pattern with "option 2"...

This has been well-known for years. There's no excuse for any professional Java developer not knowing about this.

[Mr. C Lamont Gilbert]

Option 2 is totally broken. Optimizing JVMs can set the reference before they finish creating the objects. Some question about if this is legal or not, but be careful. DCL is broken period, its not really a java issue, the theory behind it is flawed.

Never use synchronized methods, they expose the monitor object to the coderanch. Violating encapsulation in the worse way. For a good example see the insides of Thread.join();

[Rudolfoo Schmidt]

Well, what than be the best option for the singleton, considering that option 2 is not appropiate as well as option 1, because it uses a synchronized method?

thx rudolf

[Stan James]

You can give up on lazy instantiation and make an instance up front:

public class Singleton
{
   private Singleton instance = new Singleton();
   private Singleton()
   {
   }
   public Singleton getInstance()
   {
      return instance;
   }
}

[ October 13, 2005: Message edited by: Stan James ]

[Mr. C Lamont Gilbert]

Singleton with lazy initialization

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

The instancee will be created when the class is loaded. Supposedly this works. Makes you wonder though why there is a difference between class loading and instance creating...

[Stan James]

Hmmm, we called exactly the same thing lazy and not lazy. By lazy I meant not created until you ask for it. With this static variable it will be created when the class is loaded, which could be triggered by Class.forName() or calls to other static methods. In real practice, referencing the class and asking for an instance is probably the same line of code so it matters darned little.

BTW: This is the simplest form I can think of for this, but not the only one. You could implement Singleton in several other interesting ways.

[Rudolfoo Schmidt]

Sometimes you hang on the lazy way, because the singleton needs some other things that won't be available until other constructors have be done.

[Stan James]

I can't think of a requirement to defer construction of the single instance until the class has done some other initialization. Or at least one I couldn't make go away. That would force users to do something like:

class.forName("Singleton"); // load & initialize class
// or
Singleton.initialize();
// before
Singleton neo = Singleton.getInstance();

What are the chances one client would forget to do that?
[ October 14, 2005: Message edited by: Stan James ]