[concurrency-interest] How seriously should we take broken double
brian at quiotix.com
Mon May 2 23:30:03 EDT 2005
> Double checked idiom is not guaranteed to work in Java. How seriously
> should we take it?
Your program is broken. Is that serious?
> 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".
Oh my god. Are you serious?
If this is really the totality of his thoughts on the subject, then your
tech lead really ought to be fired. This is wrong on more than three
levels, but I'll restrict myself to the three I'm sure about:
- Error: lazy initialization is necessary. This is very often false.
While it _may_ be true in your case, his questionable logic in the
other two points casts considerable doubt on this.
- Error: double checked locking is the only way to achieve lazy
initialization. Dead wrong. The "Initialization On Demand Holder
Idiom" (see Jeremy's response, or Effective Java #48.) This idiom beats
DCL on all fronts -- simplicity, performance, and correctness.
- Error: It is good enough for a production program to work "most of
the time" or "as long as there are not too many users."
I might go so far as to say that if your quote is accurate, I would be
disinclined to believe anything this person says.
Your characterization of the problem is correct -- basically, a thread
can observe an object to be incompletely constructed, which could cause
any number of problems -- null pointer exception or similar exception
being the best possible outcome (because at least then you would find
out you had a problem.)
As Jeremy points out, DCL instances can be "fixed" by making the
instance field volatile, _IF_ you are on JDK 5.0 or later.
More information about the Concurrency-interest