ReentrantReadWriteLock卡在解锁上

如何解决ReentrantReadWriteLock卡在解锁上

我有一个用于获取和释放文件锁的类。我使用的customKey类只是一个带有ID字符串（ID为文件）的reentrantreadwritelock。出于某种原因，这仅在某些情况下有效，并且在大多数情况下，它会挂在所有事物的解锁上-我的调试器跟踪它一直在使用，然后卡住。

我在做什么错？如果线程崩溃并没有释放它的锁，我会得到的，但是这里一个线程尝试调用解锁，并且不再继续。

这是锁定方法：

override fun acquire(lockId: String?,ownerId: String?,sequence: Long): Boolean
{
    if (lockId != null)
    {
        lockedList.find { customlock -> customlock.Id == lockId }.apply {
            if (this != null) //lock already exists for this ID
            {
                println("Locking file $lockId Existing lock")
                this.writeLock().lock()
                println("Locked file $lockId")
            } else //lock does not exist
            {
                val newLock = Customlock(lockId)
                lockedList.add(newLock)
                println("Locking file $lockId")
                newLock.writeLock().lock()
                println("Locked file $lockId")
            }
        }
        return true
    } else
    {
        throw InvalidParameterException("ERROR: lockId or ownerId is null!")
    }
}

这是释放方法：

override fun release(lockId: String?,ownerId: String?)
    {
        if (lockId != null)
        {
            lockedList.find { customlock -> customlock.Id == lockId }.apply {
                if (this != null)
                {
                    println("Unlocking file $lockId")
                    this.writeLock().unlock()
                    if (this.isWriteLocked)
                    {
                        throw Exception("ERROR: Unlocking Failed!")
                    }
                } else
                {
                    throw Exception("ERROR: Lock not found!")
                }
            }
        }
    }

请不要理会架构，这是由作业决定的。另外，请忽略ownerId和序列变量。

编辑：我尝试只使用一个锁，虽然效率不高，但是确实起作用了，所以@gidds可能在起作用，但是ConcurrentHashMap和ConcurrentLinkedQueue（用List替换更简单）都不能解决问题。 / p>

EDIT2：这是我使用ConcurrentHashMap的新类。它仍然无法正常工作，有人可以指出我的混乱之处吗？谢谢

class LockServer(port: Int) : LockConnector,remoteexception()
{
private val lockedList = ConcurrentHashMap<String,Customlock>()
private var registry: Registry = LocateRegistry.createRegistry(port)

init
{
    registry.bind(ServiceNames.LockService.toString(),UnicastRemoteObject.exportObject(this,port))
}

/**
 * Method acquire() should block the multiple calls from the clients for each specific lockId string.
 * It means when one client acquires the lock "A" and the "A" is not locked by any other clients,* the method should record the lock and return true. If the "A" is already locked by any other client,* the method is blocked and continues only after the lock "A" is released.
 * (Note: Return value false is not used in this basic implementation.
 * Parameters ownerId and sequence are also not used in this basic implementation.)
 */
override fun acquire(lockId: String?,sequence: Long): Boolean
{
    if (lockId != null)
    {
        lockedList.computeIfPresent(lockId){id,value ->
            println("Locking file $id Existing lock")
            value.writeLock().lock()
            println("Locked file $id")
            return@computeIfPresent value
        }
        lockedList.computeIfAbsent(lockId){
            val newLock = Customlock(it)
            println("Locking file $lockId")
            newLock.writeLock().lock()
            println("Locked file $lockId")
            return@computeIfAbsent newLock
        }
        return true
    } else
    {
        throw InvalidParameterException("ERROR: lockId or ownerId is null!")
    }
}

/**
 * Method release() should release the lock and unblock all waiting acquire() calls for the same lock.
 * (Note: Parameter ownerId is not used in this basic implementation.)
 */
override fun release(lockId: String?,ownerId: String?)
{
    if (lockId != null)
    {
        lockedList.computeIfPresent(lockId){ id,value ->
            println("Unlocking file $id")
            value.writeLock().unlock()
            println("Unlocked file $id")
            return@computeIfPresent value
        }
    }
}

/**
 * Method stop() unbinds the current server object from the RMI registry and unexports it.
 */
override fun stop()
{
    registry.unbind(ServiceNames.LockService.toString())
}

}

EDIT3： 获取的新实现：

lockedList.compute(lockId){id,value ->
            if (value == null)
            {
                println("Locking file $id")
                val newLock = Customlock(id)
                newLock.writeLock().lock()
                println("Locked file $id")
                return@compute newLock
            }
            println("Locking file $id Existing lock")
            value.writeLock().lock()
            println("Locked file $id")
            return@compute value
        }

并发布：

println("Unlocking $lockId")
        lockedList[lockId]!!.writeLock().unlock()
        println("Unlocked $lockId")

仍然失败

解决方法

这可能不是您的问题，但是在添加新锁时代码具有竞争条件：如果两个线程尝试锁定同一个（新）文件，则它们都可以为其创建锁。这两个锁都将添加到列表中，但之后只会找到第一个。 （这假定该列表本身是线程安全的；否则，其中一个添加项可能会失败，永久循环或使该列表处于不一致状态，然后崩溃。）

您可以通过一些同步来解决此问题。但是更好的方法可能是将锁存储在ConcurrentHashMap（在锁ID中键入）而不是列表中，并使用原子操作（如computeIfAbsent()）安全地创建新锁。 （这也将提高渐近性能，因为它将避免每次扫描列表。）

此外，就样式而言，在锁上使用apply()看起来有些尴尬。 （它通常用于自定义新创建的对象。）我认为let()会更习惯于此。您只需要将this更改为it即可。当然，也可以使用老式的临时变量。

,

这可能不是LockServer类的问题，但是正在使用它的人：

线程1：

Membership.ValidateUser(model.UserName,model.Password)

thread2：

acquire("file1")
acquire("file2")
release("file2")
release("file1")

碰巧执行顺序如下：

acquire("file2")
acquire("file1")
release("file1")
release("file2")

UPD。

考虑对现有锁使用thread1.acquire("file1") thread2.acquire("file2") thread1.acquire("file2") //locked by thread2,waiting thread2.acquire("file1") //locked by thread1... BOOM,deadlock! （可能有些超时）而不是简单的tryLock()：

lock()