Stephan van Hulst wrote:No, because you can't get the SoftReference instance without performing index.get(key). This should be done inside the synchronized block, otherwise you can get a condition where the same SoftReference is retrieved by two different threads, and then one thread associates a new SoftReference with the given key, which is not reflected in the other thread.
I think you are right, but I thought slightly different. If both get the SoftReference instance and following one of them call the synchronize using it, (for this point we know it is just a single thread at time) then it would call the
index.get(key) again and check if it is null or any other constraint. This way, when the second thread could access the synchronization block (which means the first thread already done his job) it would do the same, which would avoid get any dirt reference from the previous execution.
I think this is a kind of workaround solution to avoid the caller of the API have so much influence in the concurrency state.