[ACCEPTED]-Why can an Object member variable not be both final and volatile in Java?-syntax

volatile only has relevance to modifications of 4 the variable itself, not the object it refers 3 to. It makes no sense to have a final volatile field because 2 final fields cannot be modified. Just declare 1 the field final and it should be fine.

It's because of Java Memory Model (JMM).

Essentially, when 17 you declare object field as final you need to 16 initialize it in object's constructor and 15 then final field won't change it's value. And 14 JMM promises that after ctor is finished 13 any thread will see the same (correct) value 12 of final field. So, you won't need to use explicit 11 synchronization, such as synchronize or Lock to allow all 10 threads to see correct value of final field.

When 9 you declare object's field as volatile, field's 8 value can change, but still every read of 7 value from any thread will see latest value 6 written to it.

So, final and volatile achieve same purpose 5 -- visibility of object's field value, but 4 first is specifically used for a variable 3 may only be assigned to once and second 2 is used for a variable that can be changed 1 many times.

References:

• http://docs.oracle.com/javase/specs/jls/se7/html/jls-4.html#jls-4.12.4

• http://docs.oracle.com/javase/specs/jls/se7/html/jls-8.html#jls-8.3.1.4

Because volatile and final are two extreme ends in Java

volatile 3 means the variable is bound to changes

final means 2 the value of the variable will never change 1 whatsoever

volatile is used for variables that their value 7 may change, in certain cases, otherwise 6 there is no need for volatile, and final means that the 5 variable may not change, so there's no need 4 for volatile.

Your concurrency concerns are important, but 3 making the HashMap volatile will not solve the problem, for 2 handling the concurrency issues, you already 1 use ConcurrentHashMap.

volatile modifier guarantees that all reads and 4 writes go straight to main memory, i.e. like 3 the variable access is almost into synchronized block. This 2 is irrelevant for final variable that cannot 1 be changed.

A volatile field gives you guarantees as what happens 4 when you change it. (No an object which 3 it might be a reference to)

A final field cannot 2 be changed (What the fields reference can 1 be changed)

It makes no sense to have both.

Because it doesn't make any sense. Volatile 4 affects object reference value, not the 3 object's fields/etc.

In your situation (you 2 have concurrent map) you should do the field 1 final.

In a multithread environment different threads 19 will read a variable from main memory and 18 add it to the CPU cache. It may result in 17 two different threads making changes on 16 the same variable, while ignoring each others 15 results. enter image description here

We use word volatile to indicate that variable 14 will be saved in main memory and will be 13 read from main memory. Thus whenever a thread 12 want to read/write a variable it will be 11 done from main memory, essentially making 10 a variable safe in multithread environment.

When 9 we use final keyword we indicate that variable 8 will not change. As you can see if a variable 7 is unchangeable, than it doesn't matter 6 if multiple threads will use it. No thread 5 can change the variable, so even if variable 4 is saved to CPU caches at different times, and 3 threads will use this variable at different 2 times than it's still ok, because the variable 1 can only be read.