请问这段 Java 代码能保证线程安全吗

[0xcaffebabe]

代码的意图是针对每个 lockKey 同一时刻只能有一个线程处理

private final Map<String, Object> lockMap = new ConcurrentHashMap<>(32);
...
synchronized (lockMap.computeIfAbsent(lockKey, key -> new Object())) {
	try {
    	...
    } catch(Exception e) {
    	...
    } finaly {
    	lockMap.remove(lockKey);
    }
}

[moshiyeap100]

1. 如果是微服务，多服务的情况下不可以。

[wolfie]

不能

A 执行完 remove key => B 执行中 => C computeIfAbsent 拿 new Object()；

[moshiyeap100]

如果不是微服务，直接 synchronized(key.intern()){}，虽然常量池可能会越来越大。

[ipwx]

这问题很大。因为你 lockMap 本身没有锁，所以你在拿到 lock 对象前的操作都有问题。

你这需求很早有人就做过了。比如 https://yanbin.blog/google-guava-striped-key-based-fine-grain-locks/

[slomo]

em.... 直接在 computeIfAbsent 的第二个参数, 也就是 Function 里做处理, 最后返回 null, 是不是也可行

[ipwx]

简单来说就是不需要每个 key 一个锁。给一个固定大小的锁池，把 key 哈希映射到锁池里面。这样既能一定程度上分散锁，又不用动态创建新的锁，锁的总数也是确定的。

[momocraft]

如果不 remove 就能用吧, computeIfAbsent 保证一个 lockKey 最多只会创建一次 lock object

[ipwx]

@momocraft 虽然你说得对，但是 key 一多就内存爆炸了。

还是固定大小的锁池比较合理。

[0xcaffebabe]

学习到了，Guava 的 Striped ，感谢各位

[dqzcwxb]

[xiang0818]

@moshiyeap100 这个和微服务有啥关系，这是单机 map

[imaple]

没问题啊

[rqxiao]

remove 为什么会线程不安全啊

[hsymlg]

这代码为什么会有线程安全问题啊🤔

[zhulixin]

remove 代表锁被移除了，此时 sync 中的 obj 还没有解锁。这时候其他线程 get 同样的 key ，就拿到了新锁。即同一个 Key 产生了多把锁。

[7911364440]

@zhulixin 如果把 remove 放在 synchronized 外面应该就没问题了吧


```java
private final Map<String, Object> lockMap = new ConcurrentHashMap<>(32);
...
try {
synchronized (lockMap.computeIfAbsent(lockKey, key -> new Object())) {
...
}
} catch(Exception e) {
...
} finaly {
lockMap.remove(lockKey);
}

```

[cubecube]

@dqzcwxb 一般情况下不要用 intern ，有严重的性能问题，也没啥收益。现在 GC 都有 String Deduplication 了

[ainyyy]

@7911364440 还是一样的问题吧,第一次锁释放 remove 前,第二个 key 获取到锁进入执行,执行过程中被释放,还是会生成新的锁对象

[clownpiece]

if (lockMap.computeIfAbsent(lockKey, k -> new AtomicBoolean()).compareAndSet(false, true)) {
try {
// ...
} finally {
lockMap.remove(lockKey);
}
}

[leonshaw]

从 map 里拿到对象到加锁中间有窗口，无法保证加锁时对象还在 map 里。