On Tue, Jun 10, 2008 at 4:37 AM, Bruno Harbulot <
[EMAIL PROTECTED]> wrote:
> Thank you for all these details. I was a bit confused, because in "Java
> Concurrency in Practice", you don't seem very fond of the double-check idiom
> (even when volatile is used).
Yeah ... sorry about the confusion. *Java Concurrency in Practice* says that
you should use the lazy initialization class holder idiom for static fields
(as does *Effective Java, 2nd edition*), but we didn't directly address lazy
initialization of instance fields, saying only that double-check is "an
idiom whose utility has largely passed." That might have been true at the
time, but we didn't get the trend right.
Bottom line: follow Josh's advice, but remember that it starts with "Under
most circumstances, normal initialization is preferable to lazy
initialization."
By any chance, do you have any benchmarking results that would indicate when
> using lazy initialization and double-check idioms performs better?
No, and I don't see a clear way to construct general benchmarks for this,
because each potential application of lazy initialization is different.
Ideally, new code should be written with normal instance field
initialization (or with synchronized accessor used to break initialization
circularities), and then, if one suspects that there's a performance problem
for a particular field, trying the double-check idiom *on that one
field*and measuring the difference.
I'm not sure whether this particular patch (Response.getChallengeRequests
> [1], not the one I had submitted which didn't have synchronization at all...
> very bad, sorry) benefits much from lazy initialization or could have used a
> non-volatile challengeRequests field GuardedBy("this").
Lazy initialization is only likely to be a win for objects that are big and
expensive to create.
In general, for a framework like Restlet that supports a wide variety of
uses, particularly a core class like Response, it's hard to say *ab
initio*whether normal initialization will become a performance issue,
so a
framework designer can be forgiven for pre-emptively using double-check in
some cases. :-)
However, an empty CopyOnWriteArrayList is neither big (a lock object and a
0-length array) nor expensive to construct -- it seems like a perfect
candidate for a normally-initialized final field. It would simplify the
code, which is always a nice thing.
> (I'd also be interested in the benchmarking applications so that we can try
> them on our machines, if possible.)
The most useful comparisons you can make will be the one I described above,
where you change from normal initialization to double-check on a single
field and measure the difference when running in your own
application-specific benchmark.
--tim
