本篇文章为你整理了序列号生成并发引发的synchronized、数据库隔离级别、myabits缓存等一些问题记录（）的详细内容，包含有 序列号生成并发引发的synchronized、数据库隔离级别、myabits缓存等一些问题记录，希望能帮助你了解 序列号生成并发引发的synchronized、数据库隔离级别、myabits缓存等一些问题记录。

　　一个序列号产生方法发现有并发问题。

　　修改这个方法中发生了一些错误，而这涉及到了一些的知识点，所以记录下。

　　synchronized方法：如果此方法内包含数据库操作，且外围有事务时，并不能完全锁住。

　　数据库隔离级别

　　RC-不可重复读，也就是在同一个事务中，多次select同一条sql获取的结果可能不同。

　　RR-可重复度，同一个事务中，多次select同一条sql获取的结果相同，除非中间update进行了数据修改。

　　mysql的默认隔离级别是RR，其它的数据库一般默认级别是RC。

　　
mybatis缓存，在有事务的情况下，多次select同一个sql，第二次将不再请求数据库，而是直接从缓存读取。

　　
类似的代码如下，下发的代码在并发时就会出现重复的code：

public Integer getCode(){

　　 CodeRule codeRuleInfo = selectCodeRuleInfo();//1、从数据库获取当前的记录

　　 Integer newCode = codeRuleInfo.getCurrentCode() + 1;//当前code+1

　　 codeRuleInfo.setCode(newCode);//2、赋值最新的

　　 updateCodeRule(codeRuleInfo);//3、更新数据库

　　 return newCode;

　　
由于是单机环境，最开始就想用synchronized解决，但发现getCode本身是在一个事务下的，这样就导致仅仅靠synchronized并不能锁住，原因如下：

1-事务开始 - 2-synchronized开始 - 3-synchronized结束 - 4-事务提交

　　其中3和4之间会又时间差，导致这期间如果有并发进来，还是会出现重复，所以需要改成：

1-synchronized开始 - 2-事务开始 - 3-事务提交 - 4-synchronized结束 

　　
CodeRule codeRuleInfo = selectCodeRuleInfo();

　　 Integer newCode = codeRuleInfo.getCurrentCode() + 1;//当前code+1

　　 codeRuleInfo.setCode(newCode);

　　 updateCodeRule(codeRuleInfo);

　　 return newCode;

　　
当时改的时候脑子抽了，并没有按照上方的改，而是改成这样了：

//原有方法，增加synchronized锁

　　public synchronized Integer getCode(){

　　 CodeRule codeRuleInfo = selectCodeRuleInfo();

　　 Integer newCode = codeRuleInfo.getCurrentCode() + 1;//当前code+1

　　 codeRuleInfo.setCode(newCode);

　　 AAA.updateCodeRule(codeRuleInfo);//只把更新放到了新事务中

　　 return newCode;

　　//另一个类中AAA，开启新事务

　　@Transactional(propagation = Propagation.REQUIRES_NEW)

　　public Integer updateCodeRule(){

　　 //执行sql更新

　　
上述方法就导致一个问题，select方法在主事务中，而update方法在新事务中，部署到线上果然不但没解决，反而非并发仅仅是循环中就全部重复了，原因如下：

　　mysql默认的隔离级别是RR，也就是同一个事务内多次select同一个语句，获取的结果都是一样的，除非两个select之间有update操作才会重新获取最新数据。但我们的update方法放在了新的事务中，导致并没有对select产生影响，所以循环下的getCode就会产生重复数据。

　　
但是诡异的是，我们在部署前有作过简单的测试，测试是正常递增的，找了半天才发现是mybatis缓存的原因：

　　mybatis一级缓存会对多次相同的sql查询进行缓存，第二次就不会再读取数据库了，而是直接从缓存中获取，除非中间进行了数据库的增删改，而新事务中增删改同样不影响缓存清除，听起来和数据库的RR隔离级别很像，但这里有个本质区别，它缓存的是一个对象，如果你对这个对象中的数据进行了修改，那么下次获取的是修改后的数据，而我们代码中每次都有codeRuleInfo.setCode(newCode);来对此对象进行了修改，所以在mybatis缓存的作用下，取出的数据却是正常递增的。

　　
这样就又不对了，照理来说如果按照mybatis缓存，那正式环境也不应该会重复，再进一步的排查，原因如下：

　　我们测试环境中的很简单，就一个select和一个update，但我们正式环境中getCode仅仅是一个主事务中的一个小方法，在循环中getCode后面还有一些其它表的增删改操作，而这些增删改会清空mybatis的缓存。

　　这里我们有一个误区，原以为mybatis缓存也是仅仅只有针对该表的增删改才会清除缓存，但实际上是针对任意表的增删改都会清除缓存，所以我们线上环境是每次都会清缓存从数据库读取，然后就是数据库RR隔离级别导致数据重复，而本地测试则是走缓存，正常增加。

　　
这种涉及到数据库又存在事务的，采用synchronized方法还是有些缺陷的：子事务独立于主事务，如果子事务出问题，则不能整体回滚了。感觉更应该考虑用数据库的悲观锁和乐观锁来解决，或者是参考微服务的一些锁实现。

　　悲观锁实现比较简单点，在并发不高时可以考虑，在select 语句中加上for update，但需要注意的是在RR隔离环境下，如果select没有命中数据，可能会产生间隙锁（很复杂，不同主键、索引、非索引造成的锁类型各不相同，可自行搜索相关资料），此时又insert就可能会造成死锁。解决方法是设置数据库隔离级别为RC，因为RC模式下不会有间隙锁产生，从而不会死锁。

　　mysql数据库设置成RC隔离级别也没什么问题，毕竟Oracle、PostgreSQL等一大众数据库的默认级别就是RC，而阿里云等一些云厂商的RDS数据库隔离级别默认也是RC。

　　以上就是序列号生成并发引发的synchronized、数据库隔离级别、myabits缓存等一些问题记录（）的详细内容，想要了解更多 序列号生成并发引发的synchronized、数据库隔离级别、myabits缓存等一些问题记录的内容，请持续关注盛行IT软件开发工作室。

郑重声明：本文由网友发布，不代表盛行IT的观点，版权归原作者所有，仅为传播更多信息之目的，如有侵权请联系，我们将第一时间修改或删除，多谢。