Robin

问题1和问题2:获取锁的成功或者失败需要通知到业务层，所以在业务代码里需要判断并根据是否成功获取锁执行不同操作，可以参考下example。 问题3：是的，这是个问题，原来打算别的进程超过一定时长未获取到锁当做expire失败重新expire 但是这样也有问题；下一步打考虑加上zookeeper的分布式锁，看看能不能解决这个问题。

对，所以要求第一个入参是LockDetail，执行完加锁会把锁结果传递到业务层（通过lockdetail的success字段），业务代码必须执行并且根据加锁是否成功做不同处理。 通过aop抛异常的方式太过粗暴，而且不一定适合所有场景，aop抛的异常调用方如何接收到也是个问题。

@jannal Good job! 简单看了下redis那块的，有个问题 加锁代码： if (redisStringTemplate.opsForValue().setIfAbsent(key, currenLockKey)) { redisStringTemplate.expire(key, expire, TimeUnit.MILLISECONDS); 和清除未设置expire的代码： Long expire = redisStringTemplate.getExpire(key, TimeUnit.MILLISECONDS); if (expire == null || expire

@jannal 提供个思路： 对于未设置expire的，不是删除而是设置expire时间，有副作用但是不大。

@jannal 竞态条件依旧存在，每个实例都有个线程在做一下操作：a. 获取没有expire的key，b.查询value的时间，c.if (value < current) delete。线程1:1a, 1b, 1c，线程2：2a, 2b. 2c；如果操作顺序是1a --> 1b --> 2a --> 2b --> 2c-->线程x获取key -->1c，有线程x在2c和1c直接获取了key值，结果就不正确了。

> > is it possible this is system language related > > Very possible actually. The log messages could have been in another language which meant that detection via keywords...