From the book Java concurrency in practice :
To publish an object safely, both the reference to the object and the object\'s state must be made visibl
There is no difference in what the effects of publishing volatile
vs final
, except that final
can only be set once in the constructor, and thus what you read should never change.
I believe a properly constructed object is indeed what you refer to, an object whose this
reference did not escape its constructor and has been published in a safe manner to the thread that it is used in.
What are the the differences between bullet points 2 and 3 ?
volatile
basically means that any writes to that field will be visible from other threads. So when you declare a field as volatile: private volatile SomeType field;
, you are guaranteed that if the constructor writes to that field: field = new SomeType();
, this assignment will be visible by other threads that subsequently try to read field
.final
has quite similar semantics: you have the guarantee that if you have a final field: private final SomeType field;
the write to that field (either in the declaration or in the constructor): field = new SomeType();
won't be reodered and will be visible by other threads if the object is properly published (i.e. no escape of this
for example).Obviously, the main different is that if the field is final, you can only assign it once.
What does he mean by final field of a properly constructed object in point 3 ?
If, for example, you let this
escape from the constructor, the guarantee provided by the final semantics is gone: an observing thread might see the field with its default value (null for an Object). If the object is properly constructed this can't happen.
Contrived example:
class SomeClass{
private final SomeType field;
SomeClass() {
new Thread(new Runnable() {
public void run() {
SomeType copy = field; //copy could be null
copy.doSomething(); //could throw NullPointerException
}
}).start();
field = new SomeType();
}
}