将Java读锁升级为写锁，用于Map中的缓存

发布于 2024-10-15 20:26:48 字数 1040 浏览 2 评论 0原文

我在下面的代码中遇到了死锁情况：

private static final ReadWriteLock opClassesLock = new ReentrantReadWriteLock();
private static final Map<Class<?>, ServiceClass> opClasses = new WeakHashMap<Class<?>, ServiceClass>();
public static ServiceClass get(Class<?> myClass) {
    opClassesLock.readLock().lock();
    try {
        ServiceClass op = opClasses.get(myClass);
        if (op == null) {
            opClassesLock.writeLock().lock(); // deadlock here
            try {
                op = new ServiceClass(myClass);
                opClasses.put(myClass, op);
            } finally {
                opClassesLock.writeLock().unlock();
            }
        }
        return op;
    } finally {
        opClassesLock.readLock().unlock();
    }
}

如果我检查了 ReentrantReadWriteLock 的文档，我就可以预测到这一点：

可重入还允许降级从写锁到读锁，通过获取写锁，然后读锁，然后释放写锁锁。 但是，从读取升级锁不是写锁可能。

除了使用单个锁而不是读/写锁（不允许并发读取）之外，还有其他方法可以解决此类问题吗？

原文

I have a deadlock situation in the code below:

private static final ReadWriteLock opClassesLock = new ReentrantReadWriteLock();
private static final Map<Class<?>, ServiceClass> opClasses = new WeakHashMap<Class<?>, ServiceClass>();
public static ServiceClass get(Class<?> myClass) {
    opClassesLock.readLock().lock();
    try {
        ServiceClass op = opClasses.get(myClass);
        if (op == null) {
            opClassesLock.writeLock().lock(); // deadlock here
            try {
                op = new ServiceClass(myClass);
                opClasses.put(myClass, op);
            } finally {
                opClassesLock.writeLock().unlock();
            }
        }
        return op;
    } finally {
        opClassesLock.readLock().unlock();
    }
}

Had I checked the documentation for ReentrantReadWriteLock, I could have predicted this:

Reentrancy also allows downgrading
from the write lock to a read lock, by
acquiring the write lock, then the
read lock and then releasing the write
lock. However, upgrading from a read
lock to the write lock is not
possible.

Besides just using a single lock instead of a read/write-lock (which won't allow concurrent reads), is there any other way to solve this kind of problem?

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

风筝有风，海豚有海 2024-10-22 20:26:48

使用经过充分测试的解决方案，例如

new MapMaker().weakKeys().makeMap();

Guava 中的解决方案。您甚至可以做类似的事情

new MapMaker().weakKeys()
.concurrencyLevel(16)
.expireAfterAccess(5, TimeUnit.MINUTES) 
.maximumSize(1000)
.makeComputingMap(new Function<Class<?>, ServiceClass>() {
    @Override
    public ServiceClass apply(Class<?> myClass) {
        return new ServiceClass(myClass);
    }
});

来解决您的整个问题，并提供很多调整缓存的可能性。

死锁的原因是在两个线程都持有读锁的情况下获取写锁。与降级锁不同，升级可能会阻塞。您需要先释放读锁。

当您获得写锁时，您应该测试另一个线程是否尚未完成该工作。

Use a well-tested solution like

new MapMaker().weakKeys().makeMap();

from Guava. You can even do things like

new MapMaker().weakKeys()
.concurrencyLevel(16)
.expireAfterAccess(5, TimeUnit.MINUTES) 
.maximumSize(1000)
.makeComputingMap(new Function<Class<?>, ServiceClass>() {
    @Override
    public ServiceClass apply(Class<?> myClass) {
        return new ServiceClass(myClass);
    }
});

which should solve your whole problem and offers a lot of possibilities to tune the caching.

The reason for the deadlock is acquiring the write lock while both thread are holding the read lock. Unlike downgrading the lock, upgrading may block. You'd need to release the read lock first.

When you get the write lock, you should test if another thread didn't do the work yet.

回复收藏 0 原文