当前位置: 首页 > 知识库问答 >
问题:

Ehcache 2.9.0中的Ehcache死锁

龚德本
2023-03-14

我们有应用程序使用EHCache2.9.0。最近,我们每周观察到一次与ehcache Get/Put操作相关的死锁,一旦清除缓存,问题就消失了。

我们在缓存get操作期间观察RandomAccessFile上的锁,在put操作期间观察ReentrantReadWriteLock上的锁。

请ehcache专家就可能出现的问题提出见解?

“http938”#25950守护进程prio=5 os_prio=0 tid=0x0000000002614000 nid=0x5A64在条件[0x00007FCD36965000]java.lang.thread.state:waiting(parking)在sun.misc.unsafe.park(本机方法)-在java.util.concurrent.locks.locks.locks.locksupport.park(edsynchronizer.java:836)在java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireShared(AbstractQueuedSynchronizer.java:967)在java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireShared(AbstractQueuedSynchronizer.java:1283)在java.util.concurrent.clocks.ReentrantReadWriteLock$readLock.lock 248)在net.sf.ehcache.store.cacheStore$1.evicat(cacheStore.java:99)在net.sf.ehcache.store.cacheStore$1.在net.sf.ehcache.store.cachingtier.onheapcachingtier$1.在net.sf.ehcache.store.cachingtier.onheapcachingtier.java:86)在net.sf.ehcache.store.cachingtier.countbasedbackend$1.在net.sf.ehcache.store.countbasedbackend$1.在removeandnotify(concurrenthashmap.java:2647)在net.sf.ehcache.store.cachingtier.countbasedbackend.remove(countbasedbackend.java:115)在net.sf.ehcache.store.cachingtier.onheapcachingtier.remove(onheapcachingtier.java:206)在net.sf.ehcache.store.cachestore.java:134)在net.sf.ehcache.java:134)在net.sf.ehcache.cache.put(在net.sf.ehcache.cache.put(cache.java:1491)在org.springframework.cache.ehcache.cache.put(ehcacheCache.java:82)在org.springframework.cache.interceptor.abstractCacheInvoker.doput(abstractCacheInvoker.java:82)在org.springframework.cache.interceptor.cacheaspectsupport.apply(cacheaspectsupport.java:651)在org.springframework.cache.interceptor.cacheaspectsupport.execute(cacheaspectsupport.java:358)在org.springframework.cache.interceptor.cacheaspectsupport.execute(cacheaspectsupport.java:299)在invocation.java:179)在org.springframework.aop.framework.cglibaopproxy$DynamicAdvisedInterceptor.Intercept(cglibaopProxy.java:653)

“http927”#25855守护进程prio=5 os_prio=0 tid=0x00007fce685c9000 nid=0x4fb6等待监视器条目[0x00007fcd359e8000]java.lang.thread.state:在net.sf.ehcache.store.disk.diskStorageFactory.read(diskStorageFactory.read)(diskStorageFactory.java:362)上被阻止(在对象监视器上)-在net.sf.ehcache.store.diskStorageFactory.readeve上等待锁定java:864)在net.sf.ehcache.store.disk.segment.decode(segment.java:171)在net.sf.ehcache.store.disk.segment.remove(segment.java:644)在net.sf.ehcache.store.disk.disk.segment.remove(diskstore.java:625)在net.sf.ehcache.store.cachestore.remove(diskstore.java:236)在2162)在net.sf.ehcache.cache.get(cache.java:1739)在org.springframework.cache.ehcache.cache.get(ehcacheCache.java:65)在org.springframework.cache.interceptor.abstractCacheInvoker.doget(abstractCacheInvoker.java:68)在org.springframework.cache.interceptor.cacheaspectsupport.findincaches(cacheaspectsupport.java:461)在org.springframework.cache.interceptor.cacheaspectsupport.findcacheditem(cacheaspectsupport.java:432)在org.springframework.cache.interceptor.cacheaspectsupport.java:432)在在org.springframework.aop.framework.reflectiveMethodInvocation.proce(reflectiveMethodInvocation.java:179)在org.springframework.aop.framework.cglibaopproxy$DynamicAdvisedInterceptor.Intercept(cglibaopProxy.java:653)

线程HTTP762在java.io.randomaccessfile.readwill(randomaccessfile.java:416)的0x00000005CBDFB538上拥有监视器锁--在org.springframework.cache.ehcache.ehcacheCache.put(EhcacheCache.java:82)上锁定[0x00000005CBDFB538](一个java.io.randomaccessfile)

共有1个答案

皇甫高阳
2023-03-14

我可能遗漏了一些东西,但在您显示的线程转储中没有看到任何死锁。只有两个线程在等待不同的事情,但不持有另一个线程。

第一次尝试必须在PUT上逐出一个值。

第二个线程通知一个条目已过期,并且正在从磁盘存储中删除。

 类似资料:
  • Ehcache集群 共有RMI,JGroups,JMS三个方案。JMS太过复杂,直接掠过。JGroups方案的配置比较复杂,如果不熟悉JGroups的同学可能用不好,而且是非核心包。所以简简单单就用ehcache-core自带的RMI了。 例子见showcase里的ehcache-hibernate-rmi.xml, 配置很简单,先把Factory配起来,简单的multicast自动发现: <ca

  • EhCache 是一个纯Java的进程内缓存框架,具有快速、精干等特点,是Hibernate中默认的CacheProvider。 下图是 Ehcache 在应用程序中的位置: 主要的特性有: 1. 快速. 2. 简单. 3. 多种缓存策略 4. 缓存数据有两级:内存和磁盘,因此无需担心容量问题 5. 缓存数据会在虚拟机重启的过程中写入磁盘 6. 可以通过RMI、可插入API等方式进行分布式缓存 7

  • 问题内容: 我是休眠的新手,已经开始使用C3P0作为休眠的连接池管理器,因为没有它,在与MySQL服务器没有联系8个小时之后,我遇到了超时问题。 切换到C3P0后,我最近遇到了死锁,我不确定它是如何发生的。我虽然显示了所有堆栈跟踪和配置。 这是配置日志 这是我设置的属性 这是被锁定的线程之一的线程转储。 由于我对此并不陌生,因此无法从日志和转储中识别问题。我还注意到C3P0创建了很多线程。 问题答

  • 问题内容: 我正在使用hibernate的spring项目,并希望使用ehcache实现二级缓存。我看到了许多解决方法: 引入了注释 一个旨在成为继任者的工具集。 可以很好地集成到hibernate自身中,以使用例如注释进行缓存。 使用代理。基于注释的配置很快变得有限或复杂(例如,注释嵌套的多个级别) 就我个人而言,我认为还不够彻底,因此我可能宁愿考虑使用更积极的方法。尽管这似乎是最完整的实现(例

  • ehcache-jcache 是 ehcache 对 JCache 标准 API (JSR107) 的实现。

  • Ehcache现在已经有了一个Cache Server,它以两种形式出现:适合大多数Web容器的WAR以及独立的服务器。Cache Server有两种类型的API:面向资源的RESTful以及SOAP。这两种API都支持任何编程语言。