google / guava

Google core libraries for Java

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

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:

synchronized (this) {
if (computedReference == UNSET) {
computedReference = valueReference;
notifyAll();

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.