Spring事务管理下synchronized锁失效问题怎么解决

这篇文章主要介绍“Spring事务管理下synchronized锁失效问题怎么解决”的相关知识，小编通过实际案例向大家展示操作过程，操作方法简单快捷，实用性强，希望这篇“Spring事务管理下synchronized锁失效问题怎么解决”文章能帮助大家解决问题。最近看到一个技术技术问题：synchronized锁问题？开启10000个线程，每个线程给员工表的money字段【初始值是0】加1，没有使用悲观锁和乐观锁，但是在业务层方法上加了synchronized关键字，问题是代码执行完毕后数据库中的money 字段不是10000，而是小于10000 问题出在哪里？Service层代码：SQL代码(没有加悲观/乐观锁)：用1000个线程跑代码：简单来说：多线程跑一个使用synchronized关键字修饰的方法，方法内操作的是数据库，按正常逻辑应该最终的值是1000，但经过多免费云主机域名次测试，结果是低于1000。这是为什么呢？既然测试出来的结果是低于1000，那说明这段代码不是线程安全的。不是线程安全的，那问题出现在哪呢？众所周知，synchronized方法能够保证所修饰的代码块、方法保证有序性、原子性、可见性。讲道理，以上的代码跑起来，问题中Service层的increaseMoney()是有序的、原子的、可见的，所以断定跟synchronized应该没关系。既然Java层面上找不到原因，那分析一下数据库层面的吧(因为方法内操作的是数据库)。在increaseMoney()方法前加了@Transcational注解，说明这个方法是带有事务的。事务能保证同组的SQL要么同时成功，要么同时失败。讲道理，如果没有报错的话，应该每个线程都对money值进行+1。从理论上来说，结果应该是1000的才对。根据上面的分析，我怀疑是提问者没测试好(hhhh，逃)，于是我也跑去测试了一下，发现是以提问者的方式来使用是真的有问题。首先贴一下我的测试代码：简单地打印了每次拿到的employee值，并且拿到了SQL执行的顺序，如下(贴出小部分)：如下(贴出小部分)：从打印的情况我们可以得出：多线程情况下并没有串行执行addEmployee()方法。这就导致对同一个值做重复的修改，所以最终的数值比1000要少。发现并不是同步执行的，于是我就怀疑synchronized关键字和Spring肯定有点冲突。于是根据这两个关键字搜了一下，找到了问题所在。我们知道Spring事务的底层是Spring AOP，而Spring AOP的底层是动态代理技术。跟大家一起回顾一下动态代理：实际上Spring做的处理跟以上的思路是一样的，我们可以看一下TransactionAspectSupport类中invokeWithinTransaction()：调用方法前开启事务，调用方法后提交事务在多线程环境下，就可能会出现：方法执行完了(synchronized代码块执行完了)，事务还没提交，别的线程可以进入被synchronized修饰的方法，再读取的时候，读到的是还没提交事务的数据，这个数据不是最新的，所以就出现了这个问题。从上面我们可以发现，问题所在是因为@Transcational注解和synchronized一起使用了，加锁的范围没有包括到整个事务。所以我们可以这样做：新建一个名叫SynchronizedService类，让其去调用addEmployee()方法，整个代码如下：我们将synchronized锁的范围包含到整个Spring事务上，这就不会出现线程安全的问题了。在测试的时候，我们可以发现1000个线程跑起来比之前要慢得多，当然我们的数据是正确的：抛开上面事务造成的synchronized失效问题，synchronized本身是悲观锁，代价偏高，像数据库数据修改的线程安全问题，可以使用乐观锁，在表中添加version字段，每次修改时预期值与数据库值比较，失败的话一定次数自旋尝试修改，修改成功的话version+1。关于“Spring事务管理下synchronized锁失效问题怎么解决”的内容就介绍到这里了，感谢大家的阅读。如果想了解更多行业相关的知识，可以关注百云主机行业资讯频道，小编每天都会为大家更新不同的知识点。

相关推荐: 微信小程序中es6-promise.js封装请求与处理异步进程的方法

这篇文章主要介绍“微信小程序中es6-promise.js封装请求与处理异步进程的方法”的相关知识，小编通过实际案例向大家展示操作过程，操作方法简单快捷，实用性强，希望这篇“微信小程序中es6-promise.js封装请求与处理异步进程的方法”文章能帮助大家解…