Hello,
Tim Peierls wrote:
On Wed, Jun 4, 2008 at 9:00 AM, Bruno Harbulot
<[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
Josh Bloch has a nice presentation of the tradeoffs in Effective Java,
2nd edition, Item 71. I'll try to summarize briefly.
First, and most important, don't use lazy initialization unless you need
to.
The main reasons you might need to are: performance (when initializing
an instance is very expensive and the need for initialization is
relatively rare among instances) and to break initialization circularities.
[...]
This last one is somewhat delicate because it involves reasoning about
the memory effects of volatile reads and writes -- don't deviate from
the pattern above. But it can be significantly faster than the
synchronized accessor on modern multiprocessor architectures, and it is
highly unlikely to be worse.
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).
By any chance, do you have any benchmarking results that would indicate
when using lazy initialization and double-check idioms performs better?
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").
(I'd also be interested in the benchmarking applications so that we can
try them on our machines, if possible.)
Best wishes,
Bruno.
[1]
http://restlet.tigris.org/source/browse/restlet/trunk/modules/org.restlet/src/org/restlet/data/Response.java?rev=3256&r1=3144&r2=3256
