⭐⭐⭐ Spring Boot 项目实战 ⭐⭐⭐ Spring Cloud 项目实战
《Dubbo 实现原理与源码解析 —— 精品合集》 《Netty 实现原理与源码解析 —— 精品合集》
《Spring 实现原理与源码解析 —— 精品合集》 《MyBatis 实现原理与源码解析 —— 精品合集》
《Spring MVC 实现原理与源码解析 —— 精品合集》 《数据库实体设计合集》
《Spring Boot 实现原理与源码解析 —— 精品合集》 《Java 面试题 + Java 学习指南》

摘要: 原创出处 juejin.cn/post/7213636024112234551 「是奉壹呀」欢迎转载,保留摘要,谢谢!


🙂🙂🙂关注微信公众号:【芋道源码】有福利:

  1. RocketMQ / MyCAT / Sharding-JDBC 所有源码分析文章列表
  2. RocketMQ / MyCAT / Sharding-JDBC 中文注释源码 GitHub 地址
  3. 您对于源码的疑问每条留言都将得到认真回复。甚至不知道如何读源码也可以请教噢。
  4. 新的源码解析文章实时收到通知。每周更新一篇左右。
  5. 认真的源码交流微信群。

工作当中经常会遇到既需要开启事务管理,同时也需要同步保证线程安全的场景。

比如一个方法

@Transactional
public synchronized void test(){
//
}

不知道大家有没有这样写过?

这样写会有问题吗?

众所周知,spring使用动态代理加AOP实现事务管理。那么上面的方法实际上需要简化成3个步骤:

void begin();

@Transactional
public synchronized void test(){
//
}

void commit();
// void rollback();

先看事务本身,这里简化为test()一个方法,从而忽略事务的传播来看,它是不受synchronized 影响的。因为它能正常commit或rollback不受其它线程影响。

再看同步这一块,这里很明显就有点问题了。synchronized 至少无法作用于事务开启提交这一步骤。假设一个线程先在此方法做了update,在return之后commit之前,另一个线程进入了此方法,进行了select,除非事务隔离级别为读未提交(READ_UNCOMMITTED)(话说回来谁会在生产环境用这种隔离级别呢),不然第二个线程读到的是未修改的值。

而这肯定并未与使用synchronized 的初衷相符。

口说无凭,show you me code。

@Transactional
public synchronized void test(){
log.info("表哥,我进来了哦!");
// select
Person person = personDao.selectByPrimaryKey("1");
log.info("person.name = " + person.getName());
// update
person.setName("你是谁?你根本不是我表哥!");
int result = personDao.updateByPrimaryKeySelective(person);
log.info("result = " + result);
}

然后在TransactionAspectSupport.commitTransactionAfterReturning()加个断点。

再模拟两个请求执行,在断点处观察第2次请求与第1次请求select到的值是不是一致。一致说明synchronized 在这里没有达到预期目的。

注意断点时选thread不要选all,不然第2个线程进不来。

通过执行结果,可以看到第2个线程执行的时候访问到了还是原值张三,并在update时等待锁超时。

通过什么方法可以让 synchronized 达到预期效果呢?

手动开启事务?pass。

事务传播级别?无关。

事务隔离级别?

读未提交 不实用。还是试试效果。

加上隔离级别

看看效果

能满足要求,但是谁会在生产环境使用读未提交级别?

依次往上,读已提交,经测试不满足,可重复读,mysql默认级别,一开始就是,不满足。

SERIALIZABLE

这倒是走向了另一个极端,通过测试可以看到,由于在SERIALIZABLE隔离级别下,会给表加个锁,因此在第2个线程执行到Select的时候就会一直等待到锁超时。

在这一个固定的测试场景曲线满足了业务要求,但是它还是进入了test方法,因此不满足synchronized的要求。

而且这种隔离级别和读未提交一样属于两个极端,它会极大的抑制并发数,在生产环境中也极少使用,在这里属于既不实用也不好用。

for update

给select查询语句手动上锁。

测试结果就不截图了,这种是比SERIALIZABLE要实用一些,它只加行锁,其它的话类似,并不能完全达到synchronized的要求。

是否使用看场景。

给test方法加一层调用方法

把transcational和synchronized分开,作用在两个方法。比如synchronized在上层方法。

千万别写成这样,这样事务不生效了。

最好也别写到最顶层如controller层,这样感觉把通道门口就给堵死了的感觉。只是加个中间层。

这样,表哥有了第1次的经验过后,表妹在第2次来的时候就被小区安保直接给拦住啦,在表哥完全跑路之前没有撬锁的机会了。

另外,一定是synchronized在调用层,transcational在被调用层。不能弄反了,弄反了就和之前没区别了。

总结

当 transcational 遇上 synchronized,不要搞在一起,会出事。如果要用最好是分开。

文章目录
  1. 1. 通过什么方法可以让 synchronized 达到预期效果呢?
    1. 1.0.1. 手动开启事务?pass。
    2. 1.0.2. 事务传播级别?无关。
    3. 1.0.3. 事务隔离级别?
    4. 1.0.4. for update
    5. 1.0.5. 给test方法加一层调用方法
  • 2. 总结