On 26 February 2013 12:08, Patricia Shanahan <[email protected]> wrote: > On 2/26/2013 3:05 AM, Dan Creswell wrote: > ... > >> Final of course meaning nothing other than "value won't change" - a >> compile/language level guarantee. >> >> It doesn't interact in any meaningful way with the JVM concurrency >> mechanics. i.e. it doesn't have any relationship to a synchronization >> action (or barrier as I prefer). Thus final provides no multi-thread >> guarantee explicitly. What one can say is that once the value becomes >> visible to a set of threads it won't change. > > ... > > How do you view the following JLS section 17.5 Final Field Semantics? > http://docs.oracle.com/javase/specs/jls/se5.0/html/memory.html#66562 > > In particular, that section says "An object is considered to be completely > initialized when its constructor finishes. A thread that can only see a > reference to an object after that object has been completely initialized is > guaranteed to see the correctly initialized values for that object's final > fields."
I think the key phrase is "a thread that can only see a reference to an object". If you were the thread that did the creation, you have a reference and final's must be initialised by end of construction thus you are guaranteed to see the correct values. If you were another thread, the only way you could get that object reference is via some synchronisation barrier/action (which flushes any values sitting in a core cache and makes them visible to all processor cores). At this point you have a valid object reference and all the initialisation done in the constructor has also been made visible to you by the flush. This, to me, is the implicit unwritten element of the above specification. Final just means "at end of construction this field will be initialised and not change". > > Patricia > >
