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个线程跑起来比之前要慢得多，当然我们的数据是正确的：
四、留下疑问
现在我们知道为啥会出现线程安全问题了，也知道如何解决了。在我写文章的时候，我也从中发现一些问题，细心的你不知道注意到了没有。我测试的代码中synchronized是修饰在方法上的，按我的推断：应该是synchronized锁释放后，事务提交前这时间间隔内才会出现线程安全问题(别的线程偷偷跑进去了)。
但从上面测试打印的SQL来看，并不完全是这样：
应该不会出现一连串的查询，而是查询-更新,查询-更新,查询-更新这种情况才对的。
总体来看，我认为思路是没有问题的，但出现上面的结果是我没考虑到的，如果知道为什么会出现这种情况的同学不妨在评论区留言告诉我。
最后
可以发现的是，虽然说Spring事务用起来我们是非常方便的，但如果不了解一些Spring事务的细节，很多时候出现Bug了就百思不得其解。
