这个问题预计大部分开发都会遇到，大部分人都会脱漏,遇到这样状况，你是否立马能找到问题
源自一个需要，对一个接口进行幂等管制。过后实现思路，创立一个申明注解，标注参数的对象的字段作为幂等标记，应用注解作为切点，进行盘绕告诉管制对业务办法进行加强，如果幂等字段曾经存在，不调用业务办法。
代码实现
定义注解
@Target(ElementType.METHOD)@Retention(RetentionPolicy.RUNTIME)@Documentedpublic @interface Idempotent { /** * 惟一标识 * @return */ String uniqueKey();}定义切面
@Component@Aspect@Slf4jpublic 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@Componentpublic class RedisDistributedLock {@Autowiredprivate 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。
心得
我想过后开发设计这个工具类时，并没有思考可重入个性，看来八股文背得还不够纯熟啊。经验这个问题后，可重入是每一个锁必须具备的个性，不然很容易写出死锁的代码。