8

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?

Jason Aller
  • 3,541
  • 28
  • 38
  • 38
pcjuzer
  • 2,724
  • 4
  • 25
  • 34
  • 2
    What do you mean by *knocking out modifier methods* modifier methods? Throwing an exception from all setters? This would violate [Liskov substitution principle](http://en.wikipedia.org/wiki/Liskov_substitution_principle). But yes, this class **would** be thread-safe. – Tomasz Nurkiewicz Aug 22 '11 at 08:44
  • Yes, throwing a runtime exception or overriding them with an empty body maybe with some logging. I know it's violating LSP. – pcjuzer Aug 22 '11 at 08:51

2 Answers2

16

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);
}
axtavt
  • 239,438
  • 41
  • 511
  • 482
  • Thanks for your detailed answer. I was thinking about the same solution with using delegate but then I always returned to the solution with extension, because I guess 'super' reference is also final. What do I miss? – pcjuzer Aug 22 '11 at 11:50
  • @pcjuzer: `super` has nothing to do with concurrency, so that in the case of extension you would need safe publication anyway. – axtavt Aug 22 '11 at 13:02
  • So, that means if you are declaring a field final then if it is being updated by one thread then other thread will not see it and if it sees then it will see in updated state? – AKS Aug 30 '13 at 19:11
-4

Yes, it will be immutable and consequently thread-safe but only as long as the fields are private.

Suraj Chandran
  • 24,433
  • 12
  • 63
  • 94