Concurrent, non-synchronized, lazy initialization: is this correct?

Question

Guys, I would appreciate a sanity check on some code of mine.
I have a class, call it State. Every instance is associated with a key of some type. Each user will know the key it wants to use. It will present that key to State to request the corresponding State instance. They must always receive back that sole instance that corresponds to key. The keys are unknown until runtime, so you must lazy initialize a State instance when first presented with a given key.
If concurrency was not an issue, then State could have lazy initialization code like this:
     /** Contract: never contains null values. */
     private static final Map<Object,State> map = new HashMap<Object,State>();
     public static State get(Object key) {
          State state = map.get(key);
          if (state == null) {
               state = new State();
               map.put(key, state);
          return state;
     private State() {}     // CRITICAL: private to ensure that get is the only place instances createdBut heavy concurrency on get is present in my application. While I could trivially make the above code safe by synchronizing get, that would cause it bottleneck the entire application. Vastly superior would be the use of some sort of concurrent data structure that would only bottleneck during the relatively rare times when new State instances must be created, but would allow fast concurrent retrievals when the State instance has already been created, which is the vast majority of the time.
I think that the unsynchronized code below does the trick:
     /** Contract: never contains null values. */
     private static final ConcurrentMap<Object,State> map = new ConcurrentHashMap<Object,State>();
     public static State get(Object key) {
          State current = map.get(key);
          if (current != null) return current;
          State candidate = new State();
          current = map.putIfAbsent(key, candidate);
          return (current == null) ? candidate : current;
     }Here is how it works: most of the time, just the first two lines
     /** (ignore this) */
     State current = map.get(key);
     if (current != null) return current;will be executed because the mapping will exist. This will be really fast, because ConcurrentHashMap is really fast (its always slower than HashMap, but maybe only 2X slower for the scenario that I will use it in; see [https://www.ibm.com/developerworks/java/library/j-benchmark2/#dsat] ).
If the relevant State instance is not present in map, then we speculatively create it. Because get is unsynchronized, this may/may not be the one actully put on map and returned by the subsequent lines of code because another thread supplying the same key may be concurrently executing the same lines of code. That's why its named candidate.
Next--and this is the real critical step--use ConcurrentMap's atomic putIfAbsent method to ensure that just the first thread to call the method for a given key is the one who suceeds in putting it's candidate in map. We reassign current to the result of putIfAbsent. Its value will be null only if there was no previous mapping for key but this call to putIfAbsent suceeded in putting candidate on map; thus, candidate needs to be returned in this case. But if current is not null, then some other thread with the same key must have been concurrently calling this code and was the thread which suceeded in putting its State on map; thus in this case current will have that other thread's value and so return it (with this thread's candidate being a waste; oh well).
Note that this problem is similar in spirit to the infamous double checked locking idiom. Since that is such a treacherous minefield
[http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html].
I would really appreciate another set of eyes looking over my code.

Answer 1

Hi Bbatman,
Thank you so much for your answer.
Pietblock: I believe that your double checked locking proposal is still wrong.OK, I do believe you.
Did you read the link that I provided in my initial post?
It discusses some known solutions,
the best of which for singletons is a value helper class,
followed by making the reference to your singleton be volatile
(assuming that you are using jdk 1.5+).Yes, I did read that article some time ago, when I first got warned for double checking. I never quite understood the keyword "volatile". Now, when reading it again, I see some light glimmering.
But your proposal has some strange elements.
First, both the singleton field as well as accessor method are always static
--why did you make them instance based in your code?
In order to call them, you already need an instance which defeats the purpose!
Are you sure about that choice?Yes, that is deliberately. The intended use is to define a static instance of SingletonReference in a class that needs to be instantiated as a singleton. That reference is then used to obtain the singleton.
Assuming that leaving out static on those was a typo,
the only innovation in your proposal is the claim that
"Executing an instance method on the new singleton prevents inlining".
Where did you get that idea from?
Its news to me. Instance methods often get inlined, not just static methods.The non static field is not a typo, but intentional. What you call a "innovation", my assumption that I prevented inlining, is exactly what I was not very sure about. I can't imagine how an interpreter or JIT compiler would navigate around that construct, but nevertheless, I am not sure. Your remark suggests that it is unsafe and I will reconsider my code (change it).
The reason why most double checked locking solutions fail,
including I believe yours,
is due to completely unintuitive behavior of optimizing java runtime compilers;
things can happen in different time order than you expect if you do not use some sort of locking.
Specifically, typical double checked locking fails because there is no lock on the singleton,
which means that writes to it can occur in strange order,
which means that your null-check on it may not prevent multiple instances from being created. Yes, you convinced me.
Thank you so much for looking into it
Piet