此自定义Keyed Lock键锁实现是否安全有效？

我需要一种支持Keyed Lock的机制，允许任意线程针对指定key加锁或解锁（不用Guava Striped）。因为需求相对宽松，找到的示例都比自己写的实现复杂，不确定下述实现是否存在安全隐患。为避免误解锁他人持有的锁（不想限制为同一线程操作），我用UUID标识锁持有者。

import java.util.UUID;
import java.util.concurrent.ConcurrentHashMap;

public class KeyedLock {
    private ConcurrentHashMap<String, UUID> locks;

    public KeyedLock(){
        locks = new ConcurrentHashMap<>();
    }

    public UUID tryLock(String key){
        UUID uuid = UUID.randomUUID();
        UUID res = locks.putIfAbsent(key, uuid);
        // 修正原代码逻辑错误：putIfAbsent返回key的旧值，不存在则返回null
        if(res != null){
            return null;
        }
        return uuid;
    }

    public boolean unlock(String key, UUID uuid){
        return locks.remove(key, uuid);
    }
}

核心问题分析 #

• 语法与逻辑错误
  原代码tryLock方法中的if(res)会直接编译失败，Java不允许将对象直接作为布尔值判断。正确逻辑是：putIfAbsent返回key对应的旧值，当旧值不为null时，说明已有线程持有该锁，应返回null表示获取失败；反之返回当前UUID表示获取成功。

• 无锁阻塞语义
  这个实现本质是用ConcurrentHashMap做key的"占位标记"，并非传统意义上的锁：当线程A持有某key的锁时，线程B调用tryLock会直接返回null（获取失败），不会阻塞等待A释放锁。仅适用于"尝试获取，失败即放弃"的场景，无法满足需要等待锁释放的业务需求。

• 内存泄漏风险
  若持有锁的线程因异常崩溃、或忘记调用unlock，该key对应的UUID会永久留在ConcurrentHashMap中，无法被清理，长期运行会导致内存泄漏。

• 安全的逻辑部分
  unlock方法使用ConcurrentHashMap.remove(key, uuid)原子操作，只有持有对应UUID的调用才能移除key，有效避免了误解锁他人持有的锁，这部分逻辑是线程安全的，符合需求。

适用场景与改进建议 #

• 适用场景：如果业务仅需要非阻塞式尝试获取锁，且能严格保证所有获取锁成功的线程最终都会调用unlock，修正逻辑错误后的实现是线程安全的。
• 改进方向：
  • 若需要阻塞等待锁：可将ConcurrentHashMap的value替换为ReentrantLock，同时记录锁持有者的UUID，既能实现阻塞等待，又能允许任意线程用正确UUID解锁。
  • 解决内存泄漏：可添加锁超时清理机制，定时移除长时间未被访问的key；或结合WeakHashMap（需配合同步机制保证线程安全）。

内容的提问来源于stack exchange，提问作者ables54