Double-Checked Locking about pegasus-java-client HOT 2 CLOSED

Double-Checked Locking may not work is right, which usually may because the new Table actually isn't atomic operation and the step of construct may be re-order under compiler optimization, so that the table != null but may not be complete object(for example, it's field may have not be inited base user setting). So volatile can forbid the re-order and is used for resolving the case widely.

If my understand is right, and then:

• Firstly, volatile can't be allowed to be used as local variable, so I think the solution isn‘t appropriate if the code was wrong.
• Secondly, table is local variable, every thread will create own copy variable, and put the ConcurrentHashMap after the table is complete inited, So it shouldn't happen the case: put one incomplete table object into ConcurrentHashMap and obtain by another thread.

So the code shoud be right and no need fix as above explain. However, if you have other reason or case which may result in unexpected result, welcome to continue discuss.

from pegasus-java-client.

I think it is not necessary to declare volatile for local variables.

from pegasus-java-client.