先查后改导致的并发修改异常,出现了两个相同编号的数据

bug主要情况是：通过调用方法获取编号，而这个编号是递增有序的，并且存在于数据库中，简单理解就是需要用到这种编号(以下称任务编号)，需要从数据库获取出来，在+1最为本次需要的编号，然后在存回数据库中，提供下次使用。直观来看是没得问题的，但是，可能在某次并发的时候出现编号相同,这个lastId,每次生成工单编号会根据lastId生成一个String的编号,然后让这个lastId+1,这样每次生成的编号就不一样,然后问题就是在并发情况下,会生成相同的编号,产生问题的原因就是,我先查数据库的lastId, 然后去修改lastId,从查询到修改中间会有一段时间来执行业务逻辑,并发情况下,两个请求从同一个接口进来,第一个请求查询到的lastId,但是在第一个请求修改lastId之前,第二个请求已经进来了,查询到lastId和第一个请求一样,导致工单编号一样

错误的原代码

经过多次修改后最终无bug的代码(其实还有问题,笔者后面也会提到,请听后文分解)

心路历程,在原代码出现bug后,第一次修复,在语句最后加上了for update 读写锁 ,innodb引擎的特性行锁

这里我原代码我已经找不到了,我就用最后代码来展示,

但是我对这个语句的认识不足,导致bug再现

了for update,但是这个排他锁是不允许修改,但允许查询,相当于当前事务未提交前,其他事务不允许修改该行,但可以查询,所以问题没有解决,可以查询就会查到旧数据

第二次修改

我加上了最终加上了synchronized,得到了上面这张图的代码,synchronized用在非static修饰的方法上,锁对象为this,由于这个类加了@Component是spring单例对象,能保证对象只有一个,因为这个是Service.被spring管理,是单例的,大家用的都是同一个OpsGenerateCodeServiceImpl的getCode方法

我认为,我给查询和修改加上了锁,保证了,只有一个线程获取锁完成了查询和修改的操作后,另一个线程才能获取到锁,去进行查询和修改,相当于一个线程在进行查询和修改期间,另一个线程什么也干不了,因为没拿到锁,我当时以为很秀了,然后bug又重现了,在稍稍思考后,我敏锐地发现的问题

@Transactional的原理是AOP

我给getCode加上这个注解,最后编译的代码其实是
最终的代码其实是  try{
开启事务
执行getCode方法
}final{
提交事务
}

问题就在于我这个synchronized锁住的是getCode方法

最终的代码其实是  try{
开启事务
获取锁
执行getCode方法
释放锁
}final{
提交事务
}

事务在锁的外面

导致一个线程在执行完查询和修改lastId后,释放了锁,在还没有提交事务的情况下,另一个线程获取了锁,查询到的lastId是未修改的lastId

最后一次修改,我做了两个改变

现在锁是在getCode上,而注解是在getLastIdWithLock上

那么就getCode方法的实际是
获取锁

执行getLastIdWithLock方法
释放锁

执行getLastIdWithLock方法实际上等同与

开启事务
执行getLastIdWithLock方法
提交事务

最终效果就是getCode等同于

获取锁

开启事务
执行getLastIdWithLock方法
提交事务
释放锁

这个注解很关键

这个是很重要的,在不加这个属性的情况下,事务是加入的,而加了之后,事务是单独创建的

这个叫做事务的传播属性,默认是加入,

也就是说getCode方法执行的查询和修改,并没有开启一个新的事务,而是加入到原本就有的最上层的add方法的这个事务中,导致还是那个问题,getCode执行结束,锁释放了,但是事务还没有提交,直到add方法结束,才提交的

没加这个注释前,代码是
开始事务
执行add方法
执行getCode方法
执行add方法
提交事务

而加了propagation = Propagation.REQUIRES_NEW,就说明执行到这个方法要开启一个新事务

代码是
开始事务
执行add方法
开启getCode的专属新事务
执行getCode方法
提交getCode的专属新事务
执行add方法
提交事务

这样才能保证事务提交后,锁才释放

你以为故事到这里就结束了吗??????????????????????????

笔者敏锐的感觉到不对劲,事务失效的场景和这个有关系

在同一个类某个方法中调用另一个事务方法,该事务失效

 getCode方法 和 add方法 在一个service中吗?不在

笔者指的是getCode方法和getLastIdWithLock方法在同一个类中,会导致如果你在getCode中直接调用getLastIdWithLock,这个getLastIdWithLock是没有事务aop的

从最终编译完成的代码来看

就是这个getCode在编译完成之后,最终会变成这样子吗????
获取锁
开启事务
执行getLastIdWithLock
关闭事务
放弃锁

实际上最终编译的代码是

它最终变成了
获取锁
执行getLastIdWithLock
放弃锁

涨知识的点来了,可能有些难以理解,但是以下语句可能不好理解,可以直接跳过看,笔者最后会有总结的话

动态代理,会生成一个OpsGenerateCodeServiceImpl代理对象,会为getLastIdWithLock这个方法,申明一个代理方法,假设叫做getLastIdWithLockWithProxy

别的类,调OpsGenerateCodeServiceImpl.getLastIdWithLock,其实是调OpsGenerateCodeServiceImpl代理对象.getLastIdWithLockWithProxy

但是OpsGenerateCodeServiceImpl本身去调自己的方法的时候,它调的是不经过aop增强的那个真实的getLastIdWithLock方法

解决方法有两种

1.在OpsGenerateCodeServiceImpl中注入自己的代理对象或者通过AopContext.currentProxy获取当前代理对象,当前前提是你要在sprping启动类上开启@EnableAspectJAutoProxy(exposeProxy = true)暴露代理类,否则平时是不允许访问这些代理类的

2.把getCode和getLastId放到不同的类中,笔者采用了这个方法,新建了一个加上@Component注解的类,把getCode方法已过去,然后把OpsGenerateCodeServiceImpl注入到这个类中,新类的getCode方法中调用OpsGenerateCodeServiceImpl.getLastId方法

那么我将用最简单的方式告诉大家如何理解同一个类中,一个方法A(不管是否被事务注解)调用另一个事务注解的方法B,事务失效

很简单,假如A方法,有一千行,其中第五百行的时候,它调用了B方法,难道aop在编译的时候,它会聪明地发现B方法是个被事务注解了的方法,于是它很聪明在第499行加上开启事务的代码,在501行加上提交事务的代码??

aop做的事情非常简单,它就看你方法A有没有事务注解,有的话就在外面套上一个开启和提交事务,方法B上面有注解,就外面套上一层代码,它不会去检查A方法中执行了B方法,B方法是事务的,所以它在A方法中,在执行到B的时候,给它套上一层,不会!!!这样效率太低,它只关心方法本身上面有没有注解,而不会去扫描方法A内部的代码,否则如果代码很长,很复杂,它要处理很久

以下任一一点不满足都会导致bug再次重现

1.先查后改这个方法的事务注解,需要用propagation = Propagation.REQUIRES_NEW

2.syncnize关键词和事务注解不能在同一个方法上,会导致syncnize没有起到你想要的效果

3.不能在同一个类中一个方法调用另一个事务方法,这会导致该事务完全失效

有一点非常值得大家警惕,就是先查后改,很多场景几乎百分百极大可能造成并发修改异常,哪怕你是上一行执行查询,下一行执行修改语句!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

比方说mysql有个用户表,有两个人,一个人先拿用户id查到用户,修改了它的密码,另一个人拿用户id查询用户,修改了账号,它们查询几乎同时,所以查到的数据一样,然后修改的时候修改密码先执行了,然后才执行另一个人的修改账号,最终结果是,账号被修改了,密码没修改,因为第二个人拿到的密码是原先的密码,它在执行修改账号的时候,顺便的就把密码也修改到原先的密码了,当然这是mybatisplus的updateById经常会发生的事情

当然笔者在考虑这个编号重复的时候,肯定有想到那个经典的解决方案,redis分布式锁,笔者使用了synchronized去锁,其实也可以用redis的setNx方法设置锁,但是又会引发一系列的锁过期(方法没执行完,锁失效了,另一个接口进来了),锁续期(引入redisson,用它的sexNx会自动创建一个守护线程不断刷新锁的失效时间),太麻烦了,懒得搞,我这个synchronized能用就行,也没啥流量,不担心速度慢,如果你用户很多,我建议还是用redis,因为synchronized是个重量锁,总归要慢一些,但其实也还行