2011-11-07 46 views
6

使用ehCache 2.4.4,我似乎進入了ehCache Segment對象的死鎖。從其他日誌記錄中,我知道'等待線程',1694最後在該堆棧跟蹤生成之前9小時運行了任何東西。與此同時,1696年已經做了很多其他的工作,所以這個鎖定肯定會被忽略。我該如何解決這個明顯的EhCache死鎖?

我很自信,我並不直接鎖定任何Segment實例,所以我認爲這是圖書館內部的某種問題。有任何想法嗎?

"Model Executor - 1696" Id=1696 in TIMED_WAITING on lock=java.u[email protected]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 
    - [email protected]3d767f 

"Model Executor - 1694" Id=1694 in WAITING on loc[email protected]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 
+0

原來,這個問題是無效的。我已經將此文檔(http://ehcache.org/documentation/user-guide/jta#performance)解釋爲指示顯式鎖不使用基於段的鎖定,但事實並非如此。這個死鎖是由我的代碼引起的,有一個鎖定版本不在finally()塊中。 – sharakan

+3

如果你已經知道了,爲什麼你不回答自己的問題,所以它不會出現在未解答的問題中? – xmoex

回答

1

原來,像Cache.acquireWriteLockOnKey呼叫最終獲得對內部段的鎖,所以這種明顯的僵局用.unlock呼叫,這不是在最後一個塊引起的。

編輯點評:它也意味着你可以爭取試圖鎖定恰好在同一段中的兩個不同的鍵,這是非常不幸的。

+1

如果確實如此,您可以將此帖標記爲答案。只需點擊答案左側的投票計數器下方的大複選標記符號 - 以這種方式表明問題已得到回答:) –