Regarding Singleton design pattern

[Raj chiru]

Hi Friends,

public class Singleton {

private static Singleton singletonObject = new Singleton();

private Singleton {

}
 
public static   Singleton getSingletonObject() {

return singletonObject;
}

}

public class Singleton {

private static volatile Singleton singletonObject;

private Singleton{

}

public static Singleton getSingletonObject()  {
 
if (singletonObject == null) {
 
synchronized(Singleton.class) {
 
if (singletonObject == null){

singletonObject = new Singleton();

}

}

}

return singletonObject;

Has anybody else here read the above two ways of singleton design and if so, what are your thoughts Regarding two designs?

[Campbell Ritchie]

Too difficult a question for "beginning". Moving thread.

[David Newton]

Both implementations are broken. See a previous, horrendous thread on singleton:

http://www.coderanch.com/t/473794/Beginning-Java/java/Static-vs-Single-Pattern

[marten kay]

Dear Raj

I had a quick read of the Static-vs-Single-Pattern thread and agree that it is pretty horrendous.

To borrow from the religious tone of that thread, my 'bible' is Joshua Bloch's Effective Java (2nd Ed). On page 17 Joshua details three ways of creating a singleton,

final field

static factory, and

use an enum with one element (form 1.5 only)

I recall the Head First Patterns book also has an example in it that deals with the double locking.

Anyway, while only a beginner, I am using a couple of Singletons. I can't see an alternative for maintaining system state across the application.

Marten

[David Newton]

I think Simpletons are necessary sometimes--the trick is to actually do them right (surprisingly difficult), and make sure that references to them are injected, not hard-coded. Double-locking is pretty broken: not as bad as it was pre-1.5, but still broken (see the IBM link provided by Janeice and my followups).

I never manage Simpletons myself; I let Spring do it. I think enums are the best post-1.5 way of implementing non-Spring-esque singletons, although I'm not convinced that's really an intended enum usecase :/

[swapnl patil]

   1. public class Singleton {  
   2.   
   3. private static volatile Singleton singletonObject;  
   4.   
   5. private Singleton{  
   6.   
   7. }  
   8.   
   9. public static Singleton getSingletonObject()  {  
  10.    
  11. if (singletonObject == null) {  
  12.    
  13. synchronized(Singleton.class) {  
  14.    
  15. if (singletonObject == null){  
  16.   
  17. singletonObject = new Singleton();  
  18.   
  19. }  
  20.   
  21. }  
  22.   
  23. }  
  24.   
  25. return singletonObject;  

According to me Second approach is right implementation of singleton pattern . Please Go through Head first Singleton pattern book.

[Raj chiru]

Hi Friends,
Thanks For Your Replies.

But, we have any drawbacks with eagerly created instance(First code)?

[David Newton]

Yes, it's not thread-safe.

[Raj chiru]

Hi David,
Thanks For Your Reply,

But with eagerly created instance, the JVM create the unique instance of the singleton when the class is loaded.
The JVM guarantees that the instance will be created before any thread access the static singletonObject variable.
so,it is thread-safe,Right?

[Marilyn de Queiroz]

I think the first is more thread safe than the second.

[Raj chiru]

Hi Marilyn,
Thanks For Your Reply.
But i think most of the people implementing the sinleton with Lazy instance creation,why?

[David Newton]

Because at one point people thought double-locking worked (and it's less-broken in Java 1.5+, but still broken). Again, see the previous, horrendous singleton thread and read the references Janeice and I provided.

[Raj chiru]

Hi David,
Thanks For Your Reply.

David Newton wrote:Because at one point people thought double-locking worked (and it's less-broken in Java 1.5+, but still broken). Again, see the previous, horrendous singleton thread and read the references Janeice and I provided.

can we solve the "double-checked locking" with ThreadLocal class?

[Rob Spoor]

With ThreadLocal you do not have one singleton instance but one instance per thread.

[Raj chiru]

Hi Rob,
Thanks For Your Reply,
I have one more doubt,what happens when singleton class implements serializable interface?

[Rob Spoor]

Unless you implement readResolve you will be able to make a clone of the object. With readResolve you can prevent this:

private Object readResolve()
{
    return getInstance();
}