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

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

Service层代码：

[code]  @Transactional
public synchronized void insert(Integer id){
Employee employee=new Employee();
log.info(employee.getMoney()+"==========");
final Integer oldMoney=employee.getMoney();
log.info("oldMoney:{}",oldMoney);
employee.setMoney(oldMoney+1);
syn.updateEmp(employee);
}

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

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

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

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

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

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

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

[code]在这里当然使用单元测试进行测试更方便一些，下面我为大家粘贴出使用单元测试启动项目进行测试的代码
@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);
}
}

使用单元测试的代码示例： 

[code]/**
* Created on 2019/3/20.
* Title: Simple
* Description:
* Copyright: Copyright(c) 2018
* Company:
*
* @author wy
*/
@RunWith(SpringRunner.class)
@SpringBootTest
public class DrivingRecordDOTest {

@Autowired
private EmployeeService employeeService;

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

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

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

二、图解出现的原因

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

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

[code]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()：

[code] protected Object invokeWithinTransaction(Method method, Class<?> targetClass, final TransactionAspectSupport.InvocationCallback invocation) throws Throwable {
final TransactionAttribute txAttr = this.getTransactionAttributeSource().getTransactionAttribute(method, targetClass);
final PlatformTransactionManager tm = this.determineTransactionManager(txAttr);
final String joinpointIdentification = this.methodIdentification(method, targetClass, txAttr);
if (txAttr != null && tm instanceof CallbackPreferringPlatformTransactionManager) {
try {
Object result = ((CallbackPreferringPlatformTransactionManager)tm).execute(txAttr, new TransactionCallback<Object>() {
public Object doInTransaction(TransactionStatus status) {
TransactionAspectSupport.TransactionInfo txInfo = TransactionAspectSupport.this.prepareTransactionInfo(tm, txAttr, joinpointIdentification, status);

TransactionAspectSupport.ThrowableHolder var4;
try {
Object var3 = invocation.proceedWithInvocation();
return var3;
} catch (Throwable var8) {
if (txAttr.rollbackOn(var8)) {
if (var8 instanceof RuntimeException) {
throw (RuntimeException)var8;
}

throw new TransactionAspectSupport.ThrowableHolderException(var8);
}

var4 = new TransactionAspectSupport.ThrowableHolder(var8);
} finally {
TransactionAspectSupport.this.cleanupTransactionInfo(txInfo);
}

return var4;
}
});
if (result instanceof TransactionAspectSupport.ThrowableHolder) {
throw ((TransactionAspectSupport.ThrowableHolder)result).getThrowable();
} else {
return result;
}
} catch (TransactionAspectSupport.ThrowableHolderException var14) {
throw var14.getCause();
}
} else {
//开启事务
TransactionAspectSupport.TransactionInfo txInfo = this.createTransactionIfNecessary(tm, txAttr, joinpointIdentification);
Object retVal = null;

try {
//调用原对象的方法
retVal = invocation.proceedWithInvocation();
} catch (Throwable var15) {
//如果出现异常进行回滚
this.completeTransactionAfterThrowing(txInfo, var15);
throw var15;
} finally {
//释放资源
this.cleanupTransactionInfo(txInfo);
}
//提交事务
this.commitTransactionAfterReturning(txInfo);
return retVal;
}
}

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

三、解决问题

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

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

[code]// 新建的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了就百思不得其解。

最后说一句：事务是保证数据一致性。加锁是保证按顺序执行