这个问题估计大部分开发都会遇到，大部分人都会遗漏,遇到这样情况，你是否立马能找到问题
源自一个需求，对一个接口进行幂等控制。当时实现思路，创建一个声明注解，标注参数的对象的字段作为幂等标记，使用注解作为切点，进行环绕通知控制对业务方法进行增强，如果幂等字段已经存在，不调用业务方法。
代码实现
定义注解
@Target(ElementType.METHOD)
@Retention(RetentionPolicy.RUNTIME)
@Documented
public @interface Idempotent {
/**
* 唯一标识
* @return
*/
String uniqueKey();
}
定义切面
@Component
@Aspect
@Slf4j
public class IdempotentAspect {
private String keyTemplate = "system:%s.%s:%s";
@Autowired
private RedisDistributedLock distributedLock;
@Pointcut("@annotation(com.xxx.xx.Idempotency)")
public void pointcut() {
}
@Around("pointcut()")
public Object around(ProceedingJoinPoint point) throws Throwable {
String className = point.getTarget().getClass().getName();
MethodSignature joinPointObject = (MethodSignature) point.getSignature();
Method method = joinPointObject.getMethod();
Idempotency annotation = AnnotationUtils.getAnnotation(method, Idempotency.class);
String field = annotation.uniqueKey();
Object[] args = point.getArgs();
String methodName = point.getSignature().getName();
if (ArrayUtils.isEmpty(args))
return point.proceed();
Object targetObject = args[0];
if (isNull(targetObject))
return point.proceed();
PropertyDescriptor propertyDescriptor = BeanUtils.getPropertyDescriptor(targetObject.getClass(), field);
if (isNull(propertyDescriptor)) {
log.warn("找不到对象属性 {}", field);
return point.proceed();
}
Object fieldValue = propertyDescriptor.getReadMethod().invoke(targetObject);
String key = format(keyTemplate,className, methodName, fieldValue.toString());
boolean lock = distributedLock.lock(key);
if (lock) {
//判断fieldValue 在数据库是否存在、并且写入数据库中
boolean canExecute = false;
canExecute = findRecord(fieldValue);
if (canExecute) {
try {
return point.proceed();
} finally {
distributedLock.releaseLock(key);
}
}
}
//略
}
}
上面就是环绕通知详细实现，省略一些具体操作实现，获取注解的uniqueKey到执行方法的参数对象中获取field值，通过方法名+field值进行加锁，并发控制，根据数据库判断控制执行。
很简单就实现对方法进行全局幂等控制，非常自信连自测都没有进行调用，直接提交到测试环境，结果啪啪打脸。在finally 解锁方法中抛出一个异常org.springframework.dao.InvalidDataAccessApiUsageException: Unexpected exception while processing command; nested exception is org.redisson.client.RedisException: Unexpected exception while processing command。这样的结果我是很懵逼的，没道理会在这里出问题的啊。我是不是使用错API，毕竟这个是公司封装的分布式工具，在看了一个其他提交的代码，使用方式并没有任何问题。这个异常是redis执行脚本错误导致，我第一想法是解锁的lua执行出错了，找同事要了类库的源码。
异常分析
分布式锁实现
@Slf4j
@Component
public class RedisDistributedLock {
@Autowired
private RedisTemplate<String, Object> redisTemplate;
private ThreadLocal<String> lockFlag = new ThreadLocal<>();
private static final String LUA_SCRIPT = "if redis.call("get",KEYS[1]) == ARGV[1] " +
"then " +
" return redis.call("del",KEYS[1]) " +
"else " +
" return 0 " +
"end ";
public boolean lock(String key) {
String uuid = UUID.randomUUID().toString();
lockFlag.set(uuid);
boolean result = setRedis(key, 10000L);
return result;
}
private boolean setRedis(final String key, final long expire) {
try {
boolean status = redisTemplate.execute((RedisCallback<Boolean>) connection -> {
byte[] keyByte = redisTemplate.getStringSerializer().serialize(key);
byte[] uuidByte = redisTemplate.getStringSerializer().serialize(lockFlag.get());
boolean result = connection.set(keyByte, uuidByte, Expiration.from(expire, TimeUnit.MILLISECONDS), RedisStringCommands.SetOption.ifAbsent());
return result;
});
return status;
} catch (Exception e) {
log.error("set redisDistributeLock occured an exception", e);
//此处应抛出异常，用来标识redis访问失败的情况
throw e;
}
}
public boolean releaseLock(String key) {
try {
Boolean result = redisTemplate.execute((RedisCallback<Boolean>) connection -> {
byte[] scriptByte = redisTemplate.getStringSerializer().serialize(LUA_SCRIPT);
return connection.eval(scriptByte, ReturnType.BOOLEAN, 1
, redisTemplate.getStringSerializer().serialize(key)
, redisTemplate.getStringSerializer().serialize(lockFlag.get()));
});
return result;
} catch (Exception e) {
log.error("release redisDistributeLock occured an exception", e);
} finally {
lockFlag.remove();
}
return false;
}
这看起来是不是一切都很正常，就像标准答案一样正确，问题到底出来哪里呢。大家先别急着结果，自己想一下，所有的线索已经给出来，可以推断出问题了。
回想起两年前，被一个面试官问到一个问题，分布式要具备那些特性。在平常开发中很少使用分布锁，一点概念都没有。但是我脑子一转想到synchronized、Lock这些JDK锁自备的特性，互斥、可重入、高性能。现在回想下，就漏掉一个高可用答案，其他都没什么问题了。而上面的问题就出现在可重入。它使用ThreadLocal<String> lockFlag来保存当前线程持有锁的标记，问题就出来这里。在切面的方法里，第二次调用lock方法，lockFlag被赋值了两次，会导致第一次赋值被同一个线程第二次加锁覆盖，然后每次解锁是都会删除锁的value，第二次解锁时lockFlag已经被删除了，所以解锁脚本执行失败了，程序才会抛出异常。lockFlag只能保存同一个线程内一次加锁，当出现一个现场多次加锁，有可能每一次加锁都不是同一个锁，这里的设计是满足不了这样的场景的。分布锁锁的可重入，我理解和JDK衍生锁不一样，不一定是同一把锁，一个线程多次调用锁，分布对不同资源进行锁定，这也算是可重入。不知道大家对分布式重入有什么看法，欢迎在评论区说出你的想法，大家一起讨论下。最后的解决方案，使用Stack替代String。
心得
我想当时开发设计这个工具类时，并没有考虑可重入特性，看来八股文背得还不够熟练啊😂。经历这个问题后，可重入是每一个锁必须具备的特性，不然很容易写出死锁的代码。
