A lot of the lazy initializations seem to be basic Collections. I don't
know of many cases where there is a truly expensive object that is lazy
initialized.
In my use cases, Request and Response objects do not have long lifecycles so
carrying around a final, empty Collection here and there might be worth it
in relation to possible concurrency issues
On Sat, Apr 5, 2008 at 12:23 PM, Tim Peierls <[EMAIL PROTECTED]> wrote:
> On Sat, Apr 5, 2008 at 5:07 AM, Jerome Louvel <[EMAIL PROTECTED]> wrote:
>
> > Thanks for the suggestion about the safe double-check idiom, very cool.
> > As
> > Request/Response have many optional property and as those are very
> > frequently created objects, I think we should ready try to keep lazy
> > initialization in place.
>
>
> OK. At some point it would be great to do some profiling with and without
> lazy init to see what effect the extra object creation has.
>
> Uh-oh, that probably sounded like volunteering ... maybe I better retract
> that comment! :-)
>
>
>
> > However, I don't see cases where the Request/Response objects (and
> > dependent
> > objects) would be access by multiple threads *at the same time*, only by
> > different threads at different times if we do async handling or async
> > NIO
> > writing.
> >
> > Could that assumption save us some additional synchronization work?
> >
>
> No. As long as there is a window in which one thread can observe the field
> with a null value before another thread initializes the field, there is a
> bug. It might be highly unlikely to cause trouble in practice, but that just
> makes the bug harder to detect when it finally does trigger.
>
> The complexity of the double-check lazy init idiom is daunting (to me,
> anyway), but you're not obliged to use volatiles. Simple synchronization
> works, too:
>
> @GuardedBy("this") private FieldType field;
>
> public synchronized FieldType getField() {
> if (field == null)
> field = initialFieldValue();
> return field;
> }
>
> @GuardedBy("this") means that *all* access to the field is performed in a
> synchronized (this) {} block (or a synchronized method). This might be
> slightly slower than using volatile on some platform/hardware combinations,
> but it's the *only* way to go if you have a class invariant that involves
> multiple non-final fields. As I said, I haven't looked hard to see if that
> is the case with Request, Response, etc.
>
> --tim
>
