• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Regarding Singleton design pattern

 
Raj chiru
Ranch Hand
Posts: 142
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Friends,








Has anybody else here read the above two ways of singleton design and if so, what are your thoughts Regarding two designs?
 
Campbell Ritchie
Sheriff
Pie
Posts: 49380
62
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Too difficult a question for "beginning". Moving thread.
 
David Newton
Author
Rancher
Posts: 12617
IntelliJ IDE Ruby
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 184
Java jQuery Postgres Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
    Author
    Rancher
    Posts: 12617
    IntelliJ IDE Ruby
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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
    Ranch Hand
    Posts: 80
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator


    According to me Second approach is right implementation of singleton pattern . Please Go through Head first Singleton pattern book.
     
    Raj chiru
    Ranch Hand
    Posts: 142
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Hi Friends,
    Thanks For Your Replies.

    But, we have any drawbacks with eagerly created instance(First code)?
     
    David Newton
    Author
    Rancher
    Posts: 12617
    IntelliJ IDE Ruby
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Yes, it's not thread-safe.
     
    Raj chiru
    Ranch Hand
    Posts: 142
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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
    Sheriff
    Posts: 9065
    12
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    I think the first is more thread safe than the second.
     
    Raj chiru
    Ranch Hand
    Posts: 142
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Hi Marilyn,
    Thanks For Your Reply.
    But i think most of the people implementing the sinleton with Lazy instance creation,why?

     
    David Newton
    Author
    Rancher
    Posts: 12617
    IntelliJ IDE Ruby
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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
    Ranch Hand
    Posts: 142
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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
    Sheriff
    Pie
    Posts: 20546
    57
    Chrome Eclipse IDE Java Windows
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    With ThreadLocal you do not have one singleton instance but one instance per thread.
     
    Raj chiru
    Ranch Hand
    Posts: 142
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Hi Rob,
    Thanks For Your Reply,
    I have one more doubt,what happens when singleton class implements serializable interface?
     
    Rob Spoor
    Sheriff
    Pie
    Posts: 20546
    57
    Chrome Eclipse IDE Java Windows
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Unless you implement readResolve you will be able to make a clone of the object. With readResolve you can prevent this:
     
    • Post Reply
    • Bookmark Topic Watch Topic
    • New Topic