使用双重检查成语重置延迟加载的字段

Question

Consider the "double-check idiom for lazy initialization of instance fields":

 // Item 71 in Effective Java copied from this interview with Bloch . \nprivate volatile FieldType field; \nFieldType getField() { \n    FieldType result = field; \n    if (result == null) { // First check (no locking) \n        synchronized(this) { \n            result = field; \n            if (result == null) // Second check (with locking) \n                field = result = computeFieldValue(); \n        } \n    } \n     return result; \n}  

I want to be able to reset the field in a safe way (force it to load again from the database, in my case). I assume that we could do this by having a reset method:

\nvoid reset() { \n   field = null; \n}  

Is this the standard way of doing resetting the field? Is it safe? Any pitfalls? I'm asking because Bloch gave the following warning about double-checked lazy-loading: "The idiom is very fast but also complicated and delicate, so don't be tempted to modify it in any way. Just copy and paste -- normally not a good idea, but appropriate here."

Thanks in advance, Playa from the Himalayas.

Answer 1

Yes, this is thread safe.

The synchronized block is to prevent multiple threads from unnecessarily calling computeFieldValue() . Since field is volatile, the accesses in reset and getField are all well-ordered.

If the first check is non-null, getField is done; result is returned.

Otherwise, a lock is acquired, excluding any other thread that might set the field to non-null, but permitting any thread to set field to null. If any thread does set field to null, nothing should have changed; that's the condition that got the thread into the synchronized block. If another thread had already acquired the lock after the current thread's check, and set the field to a non-null value, the second check will detect that.

Answer 2

I think this should be safe, but only because you're storing the field in a local variable. After this is done, there's no way for the local variable reference to magically change to null, even if another thread is resetting field's value half-way through.

Answer 3

I think reset() method isn't correct. If you read Item 71, you'll find:

This code may appear a bit convoluted. In particular, the need for the local variable result may be unclear. What this variable does is to ensure that field is once in the common case where it's already initialized.

Lazy initialization does't suppose that might changed. If field will be set to null between these operators:

FieldType result = field;
if (result == null) { // First check (no locking)

getField() provide incorrect result.

Answer 4

It seems like this will work as long as the reset method is the reset() method listed above. However, if the reset() method instantiates a new Object (like below), couldn't you end up potentially returning something different than you intended?

void reset() {
    field = new FieldType();
}

Answer 5

I guess it depends on exactly what you mean by thread-safe.

You could end up with a situation where a first instance is used after a second. That may be okay, or it may not.