[concurrency-interest] How seriously should we take broken doublechecked idiom

David Holmes dholmes at dltech.com.au
Mon May 2 21:44:01 EDT 2005


It may be that in this particular case no harm may befall the users of your
singletons. But why take the chance and promote a generally unsafe
programming practice? Who is going to take responsibility for saying "this
will be fine in our case" ?

Double-checked locking *does* work in Java 5.0 if the field is volatile.

But in your case why are you bothering with double-checked locking anyway?
Your classes are statess singletons so just use a normal static
initialization pattern:

  class Service {
    private static final Service theInstance = new Service();

    public static Service instance() { return theInstance; }


There are no synchronization issues here at all - class loading and
initialization takes care of it. Plus class-initialization only occurs on
active use, and presumably the only active use of your class is to get the
singleton and use it. Hence there should not be any issue about over-eager
construction of the singletons. (There's a holder pattern for cases where
the "main " class is used in different ways and you need to avoid
unnecessary construction of the singleton.)

David Holmes
> -----Original Message-----
> From: concurrency-interest-bounces at cs.oswego.edu
> [mailto:concurrency-interest-bounces at cs.oswego.edu]On Behalf Of Unmesh
> joshi
> Sent: Tuesday, 3 May 2005 11:00 AM
> To: concurrency-interest at altair.cs.oswego.edu
> Subject: [concurrency-interest] How seriously should we take broken
> doublechecked idiom
> hi,
> Double checked idiom is not guaranteed to work in Java. How
> seriously should
> we take it? In my current project, there are lot of stateless service
> classes, which are designed to be singletons. My tech lead says,
> "We have to
> use double checked idiom, even if it is not guaranteed to work.
> It will work
> most of the times and not many concurrent users are going to access the
> system".
> What I understand as broken with the idiom is.
> 1. Our of order writes can write reference to the singleton
> instance field
> before calling constructor.
> 2. "Constructor" in java does following.
>     1. It sets up object layout with TypeIno pointer.
>     2. Sets up HashCode field in object layout.
>     3. Sets up Lock related structures in object.
>     4. Sets up and Initializes instance fields (which can be
> ignored in my
> case, as objects are stateless)
> Constructor not being called, means none of the above takes place. If any
> other thread thinks object as constructed and tries to call any method on
> the object can show unpredictable behaviour.
> Is my understanding right?
> Thanks,
> Unmesh
> _________________________________________________________________
> Bought a New Cellphone?
> http://adfarm.mediaplex.com/ad/ck/4686-26272-10936-265?ck=Register
>  Sell your
> old one for a Great Price in eBay!
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at altair.cs.oswego.edu
> http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest

More information about the Concurrency-interest mailing list