JDK 8: ConcurrentHashMap.compute seems occasionally to be allowing multiple calls to remapping function - java-8

Question

I'm working on a highly concurrent application that uses an object cache based on a ConcurrentHashMap. My understanding of ConcurrentHashMap is that calls to the "compute" family of methods guarantee atomicity with respect to the remapping function. However, I've found what appears to be anomalous behavior: occasionally, the remapping function is called more than once.
The following snippet in my code shows how this can happen and what I have to do to work around it:
private ConcurrentMap<Integer, Object> cachedObjects
= new ConcurrentHashMap<>(100000);
private ReadWriteLock externalLock = new ReentrantReadWriteLock();
private Lock visibilityLock = externalLock.readLock();
...
public void update(...) {
...
Reference<Integer> lockCount = new Reference<>(0);
try {
newStats = cachedObjects.compute(objectId, (key, currentStats) -> {
...
visibilityLock.lock();
lockCount.set(lockCount.get() + 1);
return updateFunction.apply(objectId, currentStats);
});
} finally {
int count = lockCount.get();
if (count > 1) {
logger.debug("NOTE! visibilityLock acquired {} times!", count);
}
while (count-- > 0) {
// if locked, then unlock. The unlock is outside the compute to
// ensure the lock is released only after the modification is
// visible to an iterator created from the active objects hashmap.
visibilityLock.unlock();
}
}
...
}
Once in a great while, visibilityLock.lock() will be called more than once within the try block. The code in the finally block logs this and I do see the log message when this happens. My remapping function is mostly idempotent so, with the exception visibilityLock.lock(), it's harmless to have it called more than once. When it is, the finally block handles it by unlocking multiple times as needed.
visibilityLock is a read lock obtained from a ReentrantReadWriteLock. The point of this other lock is to ensure that another data structure outside this one cannot see the changes being made by the updateFunction until after compute returns.
Before we get side-tracked on non-issues, I'm already aware that the default implementation of ConcurrentMap.compute indicates that the remapping function can be called multiple times. However, the override (and corresponding documentation) in ConcurrentHashMap provides a guarantee of atomicity and the implementation shows this to be true (afaict).
Has anyone else run into this issue? Is it a JDK bug, or am I just doing something wrong?
I'm using:
$ java -version
openjdk version "1.8.0_181"
OpenJDK Runtime Environment (build 1.8.0_181-b13)
OpenJDK 64-Bit Server VM (build 25.181-b13, mixed mode)

Answer 1

Eyeballing the JDK code:
https://github.com/bpupadhyaya/openjdk-8/blob/master/jdk/src/share/classes/java/util/concurrent/ConcurrentHashMap.java
It's apparrent that compute will not call the remappingFunction twice. That leaves three possibilities:
You don't have a ConcurrentHashMap, but something else. Check the concrete type at runtime and dump it to the log file.
You are calling compute twice. Is there any flow control in the function which may not be doing what you expect? You've removed most of the function so it's impossible for me to say.
You are calling compute once, but your remappingFunction is locking twice. Is there any flow control in the lambda which might not be doing what you think? Again, you have removed most of the function so there is nothing I can do to help.
To debug, check the lock count, at the point of locking, and if it is nonzero, dump the stack to the logfile.