Java 我如何解决这个明显的EhCache死锁？

使用ehCache 2.4.4，我似乎陷入了ehCache段对象的死锁。从其他日志记录中，我知道“等待线程”1694在生成堆栈跟踪之前的9个小时内运行过任何东西。与此同时，1696已经完成了许多其他工作，所以这把锁肯定是被错误地锁着了

我非常确信我没有直接锁定任何段实例，所以我假设这是库内部的某种问题。有什么想法吗

"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   

---

事实证明，像Cache.acquireWriteLockOnKey这样的调用最终会在内部段上获得一个锁，因此这种明显的死锁是由不在finally块中的.unlock调用引起的

---

社论评论：这也意味着，如果您试图锁定恰好位于同一段中的两个不同的密钥，可能会引起争议，这是非常不幸的。

结果表明，这个问题是无效的。我将此文档（）解释为表明显式锁不使用基于段的锁定，但事实证明并非如此。这个死锁是由我的代码引起的，有一个锁释放不在finally（）块中。如果你已经解决了问题，为什么不回答你自己的问题，这样它就不会出现在未回答的问题中？如果真的是这样，你可以将这篇文章标记为答案。只需单击答案左侧投票计数器下方的大复选标记符号，即可表示问题已被回答：）