文档章节

Synchronized锁在Spring事务管理下,为啥还线程不安全?

Java3y
 Java3y
发布于 02/17 21:07
字数 1482
阅读 6151
收藏 242

前言

只有光头才能变强。

文本已收录至我的GitHub仓库,欢迎Star:https://github.com/ZhongFuCheng3y/3y

大年初二,朋友问了我一个技术的问题(朋友实在是好学,佩服!)

该问题来源知乎(synchronized锁问题):

开启10000个线程,每个线程给员工表的money字段【初始值是0】加1,没有使用悲观锁和乐观锁,但是在业务层方法上加了synchronized关键字,问题是代码执行完毕后数据库中的money 字段不是10000,而是小于10000 问题出在哪里?

Service层代码:

代码

SQL代码(没有加悲观/乐观锁):

SQL代码(没有加悲观/乐观锁)

用1000个线程跑代码:

用1000个线程跑代码:

简单来说:多线程跑一个使用synchronized关键字修饰的方法,方法内操作的是数据库,按正常逻辑应该最终的值是1000,但经过多次测试,结果是低于1000。这是为什么呢?

一、我的思考

既然测试出来的结果是低于1000,那说明这段代码不是线程安全的。不是线程安全的,那问题出现在哪呢?众所周知,synchronized方法能够保证所修饰的代码块、方法保证有序性、原子性、可见性

讲道理,以上的代码跑起来,问题中Service层的increaseMoney()有序的、原子的、可见的,所以断定跟synchronized应该没关系。

(参考我之前写过的synchronize锁笔记:Java锁机制了解一下)

既然Java层面上找不到原因,那分析一下数据库层面的吧(因为方法内操作的是数据库)。在increaseMoney()方法前加了@Transcational注解,说明这个方法是带有事务的。事务能保证同组的SQL要么同时成功,要么同时失败。讲道理,如果没有报错的话,应该每个线程都对money值进行+1。从理论上来说,结果应该是1000的才对。

(参考我之前写过的Spring事务:一文带你看懂Spring事务!)

根据上面的分析,我怀疑是提问者没测试好(hhhh,逃),于是我也跑去测试了一下,发现是以提问者的方式来使用是真的有问题

首先贴一下我的测试代码:


@RestController
public class EmployeeController {

    @Autowired
    private EmployeeService employeeService;

    @RequestMapping("/add")
    public void addEmployee() {
        for (int i = 0; i < 1000; i++) {
            new Thread(() -> employeeService.addEmployee()).start();
        }
    }


}

@Service
public class EmployeeService {

    @Autowired
    private EmployeeRepository employeeRepository;


    @Transactional
    public synchronized void addEmployee() {

        // 查出ID为8的记录,然后每次将年龄增加一
        Employee employee = employeeRepository.getOne(8);
        System.out.println(employee);
        Integer age = employee.getAge();
        employee.setAge(age + 1);

        employeeRepository.save(employee);
    }

}

简单地打印了每次拿到的employee值,并且拿到了SQL执行的顺序,如下(贴出小部分):

SQL执行的顺序

从打印的情况我们可以得出:多线程情况下并没有串行执行addEmployee()方法。这就导致对同一个值做重复的修改,所以最终的数值比1000要少。

二、图解出现的原因

发现并不是同步执行的,于是我就怀疑synchronized关键字和Spring肯定有点冲突。于是根据这两个关键字搜了一下,找到了问题所在。

我们知道Spring事务的底层是Spring AOP,而Spring AOP的底层是动态代理技术。跟大家一起回顾一下动态代理:


    public static void main(String[] args) {

        // 目标对象
        Object target ;

        Proxy.newProxyInstance(ClassLoader.getSystemClassLoader(), Main.class, new InvocationHandler() {
            @Override
            public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {

                // 但凡带有@Transcational注解的方法都会被拦截

                // 1... 开启事务

                method.invoke(target);

                // 2... 提交事务

                return null;
            }
            
        });
    }

(详细请参考我之前写过的动态代理:给女朋友讲解什么是代理模式)

实际上Spring做的处理跟以上的思路是一样的,我们可以看一下TransactionAspectSupport类中invokeWithinTransaction()

Spring事务管理是如何实现的

调用方法开启事务,调用方法提交事务

Spring事务和synchronized锁互斥问题

在多线程环境下,就可能会出现:方法执行完了(synchronized代码块执行完了),事务还没提交,别的线程可以进入被synchronized修饰的方法,再读取的时候,读到的是还没提交事务的数据,这个数据不是最新的,所以就出现了这个问题。

事务未提交,别的线程读取到旧数据

三、解决问题

从上面我们可以发现,问题所在是因为@Transcational注解和synchronized一起使用了,加锁的范围没有包括到整个事务。所以我们可以这样做:

新建一个名叫SynchronizedService类,让其去调用addEmployee()方法,整个代码如下:


@RestController
public class EmployeeController {

    @Autowired
    private SynchronizedService synchronizedService ;

    @RequestMapping("/add")
    public void addEmployee() {
        for (int i = 0; i < 1000; i++) {
            new Thread(() -> synchronizedService.synchronizedAddEmployee()).start();
        }
    }
}

// 新建的Service类
@Service
public class SynchronizedService {

    @Autowired
    private EmployeeService employeeService ;
	
    // 同步
    public synchronized void synchronizedAddEmployee() {
        employeeService.addEmployee();

    }
}

@Service
public class EmployeeService {

    @Autowired
    private EmployeeRepository employeeRepository;

    
    @Transactional
    public void addEmployee() {

        // 查出ID为8的记录,然后每次将年龄增加一
        Employee employee = employeeRepository.getOne(8);
        System.out.println(Thread.currentThread().getName() + employee);
        Integer age = employee.getAge();
        employee.setAge(age + 1);

        employeeRepository.save(employee);

    }
}

我们将synchronized锁的范围包含到整个Spring事务上,这就不会出现线程安全的问题了。在测试的时候,我们可以发现1000个线程跑起来比之前要慢得多,当然我们的数据是正确的:

正确的数据

最后

可以发现的是,虽然说Spring事务用起来我们是非常方便的,但如果不了解一些Spring事务的细节,很多时候出现Bug了就百思不得其解。还是得继续加油努力呀~~~

乐于输出干货的Java技术公众号:Java3y。公众号内有200多篇原创技术文章、海量视频资源、精美脑图,不妨来关注一下!

帅的人都关注了

觉得我的文章写得不错,不妨点一下

© 著作权归作者所有

共有 人打赏支持
Java3y
粉丝 378
博文 195
码字总数 607878
作品 0
广州
程序员
私信 提问
加载中

评论(43)

Java3y
Java3y

引用来自“TYi”的评论

我有以下一些疑问:
第一 spring 的 service 和 dao 虽然也是单例,一旦使用@Transation, spring 就会使用 ThreadLocal 来控制线程安全没有必要自己又开一个多线程来进行多个连接更新啊。
第二 Synchronized 是用来确保线程中的变量安全,并不是确保数据库隔离级别安全啊。

基于以上两点,不太清楚你这个测试真实目的是什么呢?
文章的开头也说了,这是朋友发我的一个问题。我只是去看一下为啥会出现这样的情况。
TYi
TYi
我有以下一些疑问:
第一 spring 的 service 和 dao 虽然也是单例,一旦使用@Transation, spring 就会使用 ThreadLocal 来控制线程安全没有必要自己又开一个多线程来进行多个连接更新啊。
第二 Synchronized 是用来确保线程中的变量安全,并不是确保数据库隔离级别安全啊。

基于以上两点,不太清楚你这个测试真实目的是什么呢?
MZHS
MZHS

引用来自“哈库纳”的评论

一个是事务隔离机制没搞明白,另一个是aop实现原理没领会到精髓。
同志仍需努力呀。

引用来自“MZHS”的评论

嗯,其实问题的根本原因是commit操作并不在synchronized中包含,想当然的以为service层的方法执行完就已经commit了,殊不知commit是在底层封装着呢,synchronized只是同步了method.invoke(target);

引用来自“爱吃窝窝头”的评论

那我想请教个问题:如果说在楼主说的第一个种的情况下,@Transactional 注解的方法下面上面没有加上synchronized 关键字,则是不是依然会出现最后 数值小于1000的情况?
是的,会出现一个线程已经把更新到6了,另一个线程的查询结果还是5,这时候+1update还是6,就会少1个+操作,这时候就会出现999,如果这种操作多了,就会出现998,997。。。
爱吃窝窝头
爱吃窝窝头

引用来自“哈库纳”的评论

一个是事务隔离机制没搞明白,另一个是aop实现原理没领会到精髓。
同志仍需努力呀。

引用来自“MZHS”的评论

嗯,其实问题的根本原因是commit操作并不在synchronized中包含,想当然的以为service层的方法执行完就已经commit了,殊不知commit是在底层封装着呢,synchronized只是同步了method.invoke(target);
那我想请教个问题:如果说在楼主说的第一个种的情况下,@Transactional 注解的方法下面上面没有加上synchronized 关键字,则是不是依然会出现最后 数值小于1000的情况?
13123123
13123123
高并发会存在这种问题
小蚂蚁飞呀飞
学习了,之前还真没留意过这个问题
小鱼儿1234
小鱼儿1234
分析的很好,学到了
阳仔11
阳仔11
学到了
越过山丘so
越过山丘so
感谢楼主分享,借平台在此向大家推荐一个学习交流圈:854601507,群里有总结系统的架构技术体系,大家可以进群下载资料,群里有阿里大牛,也有一线互联网的资深HR.
MZHS
MZHS

引用来自“哈库纳”的评论

一个是事务隔离机制没搞明白,另一个是aop实现原理没领会到精髓。
同志仍需努力呀。
嗯,其实问题的根本原因是commit操作并不在synchronized中包含,想当然的以为service层的方法执行完就已经commit了,殊不知commit是在底层封装着呢,synchronized只是同步了method.invoke(target);
Java高级程序员面试大纲——错过了金三,你还要错过银四吗

跳槽时时刻刻都在发生,但是我建议大家跳槽之前,先想清楚为什么要跳槽。切不可跟风,看到同事一个个都走了,自己也盲目的开始面试起来(期间也没有准备充分),到底是因为技术原因(影响自己...

Java高级架构
2018/04/27
0
0
Java开发面试题大汇总,年薪30万的面试题你能答出多少?

最近有很多朋友在问,年后打算跳槽,这两个月该怎么准备,针对这些问题,我总结了一套年薪30万左右Java开发面试题,虽然还落了一下没写,但是我感觉完全掌握这些,年薪30万是没有问题的,下面...

Java高级架构进阶
2018/01/08
0
0
Java程序员面试大纲—错过了金三银四,你还要错过2018吗?

跳槽时时刻刻都在发生,但是我建议大家跳槽之前,先想清楚为什么要跳槽。切不可跟风,看到同事一个个都走了,自己也盲目的开始面试起来(期间也没有准备充分),到底是因为技术原因(影响自己...

java高级架构牛人
2018/04/27
0
0
Java开发:错过金三银四 你还要错过金九银十吗?面试大纲总结

前言: 一年之计在于春 金三银四已过,2018也已经年过一半多,作为一个开发人员,你是否面上了自己理想的公司,薪资达到心中理想的高度? 面试:如果不准备充分的面试,完全是浪费时间,更是...

Java大蜗牛
2018/08/16
0
0
美团猫眼团队面试题:Maven+OSGi+Spring+Zookeeper+Dubb

版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/t4i2b10X4c22nF6A/article/details/84327220 交叉一面 concurrent包下面用过哪些? countdownlatch功能实现 ...

JAVA高级架构v
2018/11/21
0
0

没有更多内容

加载失败,请刷新页面

加载更多

欧拉公式

欧拉公式表达式 欧拉公式的几何意 cosθ + j sinθ 是个复数,实数部分也就是实部为 cosθ ,虚数部分也就是虚部为 j sinθ ,对应复平面单位圆上的一个点。 根据欧拉公式和这个点可以用 复指...

sharelocked
56分钟前
2
0
burpsuite无法抓取https数据包

1.将浏览器和burpsuite的代理都设置好 2.在浏览器地址栏输入: http://burp 3.下载下面的证书,并将证书导入浏览器 cacert.der

Frost729
今天
2
0
JeeSite4.x 消息管理、消息推送、消息提醒

实现统一的消息推送接口,包含PC消息、短信消息、邮件消息、微信消息等,无需让所有开发者了解消息是怎么发送出去的,只需了解消息发送接口即可。 所有推送消息均通过 MsgPushUtils 工具类发...

ThinkGem
今天
7
0
OpenML

https://www.openml.org/search?type=data

shengjuntu
今天
2
0
java强引用,软引用,弱引用和虚引用

先来简要说一下这四种引用的特性: 强引用:如果一个对象具有强引用,那垃圾回收器绝不会回收它 软引用:如果一个对象只具有软引用,则内存空间足够,垃圾回收器就不会回收它 弱引用:在垃圾...

woshixin
今天
1
0

没有更多内容

加载失败,请刷新页面

加载更多

返回顶部
顶部