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

前言

只有光头才能变强。

文本已收录至我的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肯定有点冲突。于是根据这两个关键字搜了一下，找到了问题所在。

（编辑：ASP站长网）