final fields and thread-safety
Should it be all fields, including super-fields, of a purposely immutable java class 'final' in order to be thread-safe or开发者_开发技巧 is it enough to have no modifier methods?
Suppose I have a POJO with non-final fields where all fields are type of some immutable class. This POJO has getters-setters, and a constructor which sets some initial value. If I extend this POJO with knocking out modifier methods, thus making it immutable, will extension class be thread-safe?
In order to use an effectively immutable object without final
fields in a thread safe manner you need to use one of safe publication idioms when making the object available to other threads after initialization, otherwise these threads can see the object in partially initialized state (from Java Concurrency in Practice):
- Initializing an object reference from a static initializer;
- Storing a reference to it into a volatile field or AtomicReference;
- Storing a reference to it into a final field of a properly constructed object; or
- Storing a reference to it into a field that is properly guarded by a lock.
Declaring fields of your immutable object as final
releases this restriction (i.e. it guarantees that if other threads see a reference to the object, they also see its final
fields in fully initialized state). However, in general case it doesn't guarantee that other threads can see a reference to the object as soon as it was published, so you may still need to use safe publication to ensure it.
Note that if your object implements an interface, you can use an approach used by Collections.unmodifiableList()
, etc:
class ImmutableFooWrapper implements IFoo {
private final IFoo delegate; // final provides safe publication automatically
public ImmutableFooWrapper(IFoo delegate) {
this.delegate = delegate;
}
...
}
public IFoo immutableFoo(IFoo foo) {
return new ImmutableFooWrapper(foo);
}
Yes, it will be immutable and consequently thread-safe but only as long as the fields are private.
精彩评论