Làm thế nào tôi có thể làm việc xung quanh bế tắc EhCache rõ ràng này?

Question

Sử dụng ehCache 2.4.4, dường như tôi đã gặp phải bế tắc trên đối tượng Phân đoạn ehCache. Từ đăng nhập khác, tôi biết rằng 'chờ thread', 1694 cuối cùng chạy bất cứ điều gì 9 giờ trước khi ngăn xếp dấu vết này đã được tạo ra. Trong khi đó, 1696 đã đi và thực hiện rất nhiều công việc khác, vì vậy khóa này chắc chắn đang được tổ chức một cách điên rồ.

Tôi khá tự tin rằng tôi không trực tiếp khóa trực tiếp bất kỳ trường hợp Phân đoạn nào, vì vậy tôi cho rằng đây là một số loại vấn đề bên trong thư viện. Bất kỳ ý tưởng?

"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

Chỉ ra rằng các cuộc gọi như Cache.acquireWriteLockOnKey kết thúc được một khóa trên Segment nội bộ, vì vậy bế tắc rõ ràng này được gây ra bởi một cuộc gọi .unlock mà không phải là trong một khối finally.

Nhận xét biên tập: Điều này cũng ngụ ý rằng bạn có thể tranh giành khóa hai khóa khác nhau vừa xảy ra trong cùng một Phân đoạn, điều này thật không may.