Java 有类似于 Redis 锁的，只在本应用的锁吗？

guava cache

都是本地了 为何不直接用 JDK 自带的 Lock 或者 synchronized

@sulinwork 你肯定没看懂我说什么。。。

可以尝试用 Semaphore 信号量和 DelayQueue 延迟队列自己封装一个

本地锁一般没必要加超时时间，使用完就释放了，没使用完一直持久就好了，所以没怎么见到过你这种需求。

redis 之所以有超时，是分布式带来的不确定性。

1L 说的应该是对的 记得是用过

本地缓存？

redis 加过期时间是因为 在分布式环境加锁风险太大 redis 给出兜底的方案， 单应用加锁随便玩好吗

Map<String, Lock>
超时感觉没必要，都写 finally 里了
redis 超时是怕客户端抽了不释放锁，单机环境没有这个问题

自旋锁

查了下 当时用的
caffeine 可以 expire
@haython

如果你想要锁值的 参考这个文章

caffeine > guava cache
caffeine 是基于 guava cache 开发的，可以构建过期策略，如超时，设置容量大小等方式

你是想用缓存，还是要线程加锁，还是要利用定时自动解锁做业务逻辑。如果是线程加锁的话，用 await 、wait 、notify 这些线程通信机制来解锁会更有效，实在不行，你还可以用 sleep 。如果是另外两个场景，用 Redis ，比自己搞，更简单还更可靠。

synchronized(name.intern())
单应用不需要过期时间

@nekoneko 还是你这个让人想不到。。。

#16 楼的方案挺好

或许也可以使用 ConcurrentHashMap 结合 ReentrantLock 实现.

```
Map<String, ReentrantLock> lockMap = new ConcurrentHashMap<>();
ReentrantLock lock = lockMap.getOrDefault("key-name", new ReentrantLock());
lock.tryLock(1, TimeUnit.SECONDS);
```

会不会有什么问题? 坐等大佬指出

纠正一下 #19

```
Map<String, ReentrantLock> lockMap = new ConcurrentHashMap<>();
ReentrantLock lock = lockMap.computeIfAbsent("key-name", l -> new ReentrantLock());
lock.tryLock(1, TimeUnit.SECONDS);
```

@ZeawinL 时间参数是最大等待锁的时间，不是最大持有时间啊

2l 是对的。

@ZeawinL 锁什么时候释放，Map 什么时候清除这个 key
姑且按
lockMap.remove("key-name");
lock.unlock();
这种来处理
当第一个线程 remove 操作之前，有第二个线程来获取锁，获取的还是老的 ReentrantLock ，在 tryLock 阶段，第一个线程 remove 操作了，第三个线程来获取锁，肯定是新的 ReentrantLock

@potatowish 理解错了，感谢指正

用字符串变量作为锁的名称没有太难吧，用 ConcurrentHashMap 映射一下，或者直接用 intern ，获取常量池引用。

我觉得重点应该是如何实现锁的过期机制，有没有必要可先放一边。

所以，OP 最后使用了什么方法？

@NULL2020
synchronized (name.tostring().intern()) {
..
}

一是因为我的业务可以确定不会有太多字符串，二是可能还没等到常量池太大，就又重新部署一次了