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

terro 发布于2019-08-16 15:10 / 1259人阅读

摘要：不是线程安全的，那问题出现在哪呢众所周知，方法能够保证所修饰的代码块方法保证有序性原子性可见性。讲道理，如果没有报错的话，应该每个线程都对值进行。

前言

只有光头才能变强。

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

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

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

https://www.zhihu.com/question/277812143

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

Service层代码：

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

用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执行的顺序，如下(贴出小部分)：

从打印的情况我们可以得出：多线程情况下并没有串行执行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()：

调用方法前开启事务，调用方法后提交事务

在多线程环境下，就可能会出现：方法执行完了(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多篇原创技术文章、海量视频资源、精美脑图，不妨来关注一下！

觉得我的文章写得不错，不妨点一下赞！

GPU云服务器云服务器多线程synchronized linux 下安全证书管理面试spring事务 mybatis 事务 spring

文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。

转载请注明本文地址：https://www.ucloud.cn/yun/73312.html

单例模式你会几种写法？

摘要：使用静态类体现的是基于对象，而使用单例设计模式体现的是面向对象。二编写单例模式的代码编写单例模式的代码其实很简单，就分了三步将构造函数私有化在类的内部创建实例提供获取唯一实例的方法饿汉式根据上面的步骤，我们就可以轻松完成创建单例对象了。前言只有光头才能变强回顾前面：给女朋友讲解什么是代理模式包装模式就是这么简单啦本来打算没那么快更新的，这阵子在刷Spring的书籍。在看...

solocoder 2019-08-15 17:43 评论0 收藏0
假如我是面试官，我会这样虐你

摘要：又是金三银四的时候，我希望这份面试题能够祝你一臂之力自我和项目相关自我介绍你觉得自己的优点是你觉得自己有啥缺点你有哪些你为什么要离开上家公司你上家公司在，我们公司在，离这么远为什么要选择我们这里上家公司的同事和领导是怎么评价你的介绍下你的上又是金三银四的时候，我希望这份面试题能够祝你一臂之力！自我和项目相关 1、自我介绍 2、你觉得自己的优点是？你觉得自己有啥缺点？ 3、你有哪些 ...

Benedict Evans 2019-08-16 15:35 评论0 收藏0
Javag工程师成神之路（2019正式版）

摘要：结构型模式适配器模式桥接模式装饰模式组合模式外观模式享元模式代理模式。行为型模式模版方法模式命令模式迭代器模式观察者模式中介者模式备忘录模式解释器模式模式状态模式策略模式职责链模式责任链模式访问者模式。主要版本更新时间备注 v1.0 2015-08-01 首次发布 v1.1 2018-03-12 增加新技术知识、完善知识体系 v2.0 2019-02-19 结构...

Olivia 2019-08-16 15:14 评论0 收藏0
不可不说的Java“锁”事

摘要：本文旨在对锁相关源码本文中的源码来自使用场景进行举例，为读者介绍主流锁的知识点，以及不同的锁的适用场景。中，关键字和的实现类都是悲观锁。自适应意味着自旋的时间次数不再固定，而是由前一次在同一个锁上的自旋时间及锁的拥有者的状态来决定。前言 Java提供了种类丰富的锁，每种锁因其特性的不同，在适当的场景下能够展现出非常高的效率。本文旨在对锁相关源码（本文中的源码来自JDK 8）、使用场景...

galaxy_robot 2019-08-16 13:43 评论0 收藏0
Java开发大厂面试整理

摘要：用户态不能干扰内核态所以指令就有两种特权指令和非特权指令不同的状态对应不同的指令。非特权指令所有程序均可直接使用。用户态常态目态执行非特权指令。这是我今年从三月份开始，主要的大厂面试经过，有些企业面试的还没来得及整理，可能有些没有带答案就发出来了，还请各位先思考如果是你怎么回答面试官？这篇文章会持续更新，请各位持续关注，希望对你有所帮助！面试清单平安产险飞猪上汽大通浩鲸科...

Scorpion 2019-08-16 17:18 评论0 收藏0