この明らかなEhCacheデッドロックを回避するにはどうすればよいですか？

Question

ehCache 2.4.4を使用すると、ehCache Segmentオブジェクトのデッドロックになっているようです。他のロギングから、私はこのスタックトレースが生成される前に1694が最後に何かを実行したことを知っています。その間に、1696は行ってしまい、他の多くの作業を行ったため、このロックは誤って保持されています。

Segmentインスタンスを直接ロックしているわけではないと確信していますので、これはライブラリの内部で何らかの問題が発生していると思われます。何か案は？

"Model Executor - 1696" Id=1696 in TIMED_WAITING on lock=java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject@92eb1ed 
at sun.misc.Unsafe.park(Native Method) 
at java.util.concurrent.locks.LockSupport.parkNanos(Unknown Source) 
at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(Unknown Source) 
at java.util.concurrent.PriorityBlockingQueue.poll(Unknown Source) 
at com.rtrms.application.modeling.local.BlockingTaskList.takeTask(BlockingTaskList.java:20) 
at com.rtrms.application.modeling.local.ModelExecutor.executeNextTask(ModelExecutor.java:71) 
at com.rtrms.application.modeling.local.ModelExecutor.run(ModelExecutor.java:46) 

Locked synchronizers: count = 1 
    - java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync@4a3d767f 

"Model Executor - 1694" Id=1694 in WAITING on lock=java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync@4a3d767f 
owned by Model Executor - 1696 Id=1696 
at sun.misc.Unsafe.park(Native Method) 
at java.util.concurrent.locks.LockSupport.park(Unknown Source) 
at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(Unknown Source) 
at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireShared(Unknown Source) 
at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireShared(Unknown Source) 
at java.util.concurrent.locks.ReentrantReadWriteLock$ReadLock.lock(Unknown Source) 
at net.sf.ehcache.store.compound.Segment.unretrievedGet(Segment.java:248) 
at net.sf.ehcache.store.compound.CompoundStore.unretrievedGet(CompoundStore.java:191) 
at net.sf.ehcache.store.compound.impl.DiskPersistentStore.containsKeyInMemory(DiskPersistentStore.java:72) 
at net.sf.ehcache.Cache.searchInStoreWithStats(Cache.java:1884) 
at net.sf.ehcache.Cache.get(Cache.java:1549) 
at com.rtrms.amoeba.cache.DistributedModeledSecurities.get(DistributedModeledSecurities.java:57) 
at com.rtrms.amoeba.modeling.AssertPersistedModeledSecurities.get(AssertPersistedModeledSecurities.java:44) 
at com.rtrms.application.modeling.tasks.ExpandableModelingTask.getNextUnexecutedTask(ExpandableModelingTask.java:35) 
at com.rtrms.application.modeling.local.BlockingTaskList.takeTask(BlockingTaskList.java:36) 
at com.rtrms.application.modeling.local.ModelExecutor.executeNextTask(ModelExecutor.java:71) 
at com.rtrms.application.modeling.local.ModelExecutor.run(ModelExecutor.java:46) 

Locked synchronizers: count = 0 

Answer 1

はCache.acquireWriteLockOnKeyなどの呼び出しが内部セグメントのロックを取得してしまうことが判明したので、この見かけ上のデッドロックはfinallyブロックではありませんでした.unlock呼び出しによって引き起こされました。

編集者のコメント：これは、同じセグメントにあった2つの異なるキーをロックしようとする競合を招く可能性があることを意味します。これはかなり不幸です。