IllegalMonitorStateException
OsmondGao opened this issue · comments
java.lang.IllegalMonitorStateException
at java.lang.Object.notifyAll(Native Method)
at com.google.common.collect.ComputingConcurrentHashMap$ComputingValueReference.setValueReference(ComputingConcurrenthashMap.java:370)
at com.google.common.collect.ComputingConcurrentHashMap$ComputingValueReference.compute(ComputingConcurrentHashMap.java:362)
at com.google.common.collect.ComputingConcurrentHashMap$ComputingSegment.compute(ComputingConcurrentHashMap.iava:182)
at com.google.common.collect.ComputingConcurrentHashMap$ComputingSegment.getOrCompute(ComputingConcurrentHashMap.java:151)
at com.google.common.collect.ComputingConcurrentHashMap.getOrCompute(ComputingConcurrentHashMap.java:67)
at com.google.common.collect.MapMaker$ComputingMapAdapter.get(MapMaker.java:885)
at com.xx.xx.xx.LoadStatsTracker$LoadThroughput.getStat(LoadStatsTracker.java:54)
/***********************************************************************************************************/
This Exception is raised on guava:18.0,and I searched all Issues but not found this problem.
Can you fix this problem or has the latest version fixed this problem?
Guava 18.0 was released in 2014, and I'm pretty sure com.google.common.collect.MapMaker$ComputingMapAdapter
hasn't existed for a long time, so definitely try upgrading to the latest version you can. At time of writing, the latest version is 31.1-jre (or 31.1-android if you're on Android or Java 7).
I don't recall any bugs like that one. I do know that our team occasionally hears of a mystery IllegalMonitorStateException
in some piece of code that doesn't look like it could possibly trigger the problem. I don't see how this piece of code could trigger the problem, either, as notifyAll
is being called inside a synchronized
block:
guava/guava/src/com/google/common/collect/ComputingConcurrentHashMap.java
Lines 367 to 370 in 798803f
Maybe there's something deeper wrong, like a memory problem or a bad piece of native code.
Taking what @jbduncan said a step further, I would recommend using Caffeine instead of a computing map, as discussed in our docs for CacheBuilder
. It has a significantly different implementation than ours, so it would make you even less likely to encounter such a problem. Plus, you may be able to switch to Caffeine without having to worry about changing any old Guava APIs you use (since Guava 18.0 is old enough that we were still removing non-@Beta
APIs back then). But I do encourage you to upgrade Guava, anyway :)
I would guess this is a VM edge case like the ones JEP-270 tries to mitigate and it is up to the application to avoid. That type of case (which still happen rarely) and the Linux lost wake-up bug were frustrating to track down from vague reports of deadlocks that made no sense from the code. You have to look for any other signals in the logs, e.g. stack overflow errors due to recursive calls. Upgrading or switching libraries may help by changing the code paths that triggered this or hopefully rejecting problematic usages, but as a lower-level problem then library authors won't be able to help as long as their code is correct according to the spec.