If a field is accessed only on a fraction of the instances of a class and it is costly to initialize the field, then lazy ini-
tialization may be worthwhile.
Under most circumstances, normal initialization is preferable to lazy initialization
If you use lazy initialization to break an initialization circularity, use a
synchronized accessor, as it is the simplest, clearest alternative:
// Lazy initialization of instance field - synchronized accessor
private FieldType field;
synchronized FieldType getField() {
if (field == null)
field = computeFieldValue();
return field;
}
If you need to use lazy initialization for performance on a static field, use
the lazy initialization holder class idiom
private static class FieldHolder {
static final FieldType field = computeFieldValue();
}
static FieldType getField() { return FieldHolder.field; }
A modern VM will synchronize field access only to initialize the class
Once the class is initialized, the VM will patch the code so that subsequent access
to the field does not involve any testing or synchronization.
If you need to use lazy initialization for performance on an instance field,
use the double-check idiom
Because there is no locking if the field is already initialized, it
is critical that the field be declared volatile
private volatile FieldType field;
FieldType getField() {
FieldType result = field;
if (result == null) { // First check (no locking)
synchronized(this) {
result = field;
if (result == null) // Second check (with locking)
field = result = computeFieldValue();
}
}
return result;
}
Prior to release 1.5, the double-check idiom did not work reliably because the
semantics of the volatile modifier were not strong enough to support it
[Pugh01]. The memory model introduced in release 1.5 fixed this problem
//像下面这样写会有问题,can cause repeated initialization!
private volatile FieldType field;
private FieldType getField() {
FieldType result = field;
if (result == null)
field = result = computeFieldValue();
return result;
}
--------------------
In summary, you should initialize most fields normally, not lazily. If you must
initialize a field lazily in order to achieve your performance goals, or to break a
harmful initialization circularity, then use the appropriate lazy initialization tech-
nique. For instance fields, it is the double-check idiom; for static fields, the lazy
initialization holder class idiom. For instance fields that can tolerate repeated ini-
tialization, you may also consider the single-check idiom