写点什么

从 Spring 的 AOP 看 Synchronized 锁失效和事务失效的情况

作者:Java你猿哥
  • 2023-04-10
    湖南
  • 本文字数:4559 字

    阅读完需:约 15 分钟

从Spring的AOP看Synchronized锁失效和事务失效的情况

这个锁失效是前年了遇到的一个 bug,在一个方法上加了 Synchronized,为了避免同一时间产生两条相同的单据,但是很明显,它失效了,不然也不会有今天的这篇文章。

出现这个 bug 的是一个老项目,而且这个 bug 很早之前就发现了,前人应该也发现了,对数据进行了所谓的特殊处理,所以一直也就那么运行下去。老项目本着能运行就不要乱动的原则,就没怎么处理了。后面需要对这个模块进行重构,就决定把这个问题解决了。

当时这个问题看了很久,也分析了很久,没有头绪,想着这个 bean 是单例的应该是不存在锁不住的情况。现在想想还是太年轻了。

产生的原因

我们来回顾一下 spring 进行事务处理的逻辑:如果一个方法需要开启声明式事务,会进行代理,在执行的逻辑之前和之后进行增强。

比如 我们需要更新数据库的数据,数据库现在的数据是 0


模拟同时进行 200 次操作

   @GetMapping("test_tran")    public R<Void> testTran() {
ThreadUtil.execute(() -> { for (int i = 0; i < 10; i++) { new Thread(() -> { for (int i1 = 0; i1 < 20; i1++) { testBiz.testProxy(); } }).start(); } });
return R.ok(); } // ========== testBiz ========== // testBiz方法 然后操作的方法加了锁 @Override @Transactional(rollbackFor = Exception.class) public synchronized int testProxy() {
System.out.println(this.hashCode()); // 之前的业务大致流程是 查询数据是否存在 int num = sysConfigMapper.getNum(); // 如果数据存在就直接返回 不存在就新增 // 不太好模拟 这边改成获取数据 在+1好模拟一点 sysConfigMapper.updateNum(num + 1); // 模拟业务耗时 ThreadUtil.safeSleep(20);
return num; } // ========== mapper 方法 ========== @Select("select incr from test_sync where id = 1") int getNum();
@Update("update test_sync set incr = #{i} where id = 1") void updateNum(int i);
复制代码

如果正常的话,一次执行完数据库的数据应该是 200




结果很多种情况。

原因分析

出现这种情况有两种可能,第一是锁失效了,第二就是数据库查询的时候有问题,存在多次查询返回同一条数据的情况。之前项目情况就是查不到插入的数据,再次插入了,所以出现了重复数据。

首先是第一种情况,没有锁住,我们可以通过非线程安全的操作去验证一下。

@GetMapping("test_tran")    public R<Void> testTran() {        // 上面有更新数据库日志 知道啥时候停了 就没加 CountDownLatch        CountDownLatch countDownLatch = new CountDownLatch(200);        ThreadUtil.execute(() -> {            for (int i = 0; i < 10; i++) {                new Thread(() -> {                    for (int i1 = 0; i1 < 20; i1++) {                        try {                            testBiz.testProxy();                        } finally {                            countDownLatch.countDown();                        }                    }                }).start();            }        });
try { countDownLatch.await(); } catch (InterruptedException e) { throw new RuntimeException(e); } return R.ok(); } // 获取当前testBiz实现类中i的值 @GetMapping("getI") public R<Integer> getI() {
int i = testBiz.getI(); System.out.println("i:" + i); return R.ok(i); }
// ========== testBiz ========== private int i = 0;
@Override @Transactional(rollbackFor = Exception.class) public synchronized int testProxy() {
// System.out.println(this.hashCode());// // 之前的业务大致流程是 查询数据是否存在// int num = sysConfigMapper.getNum();// // 如果数据存在就直接返回 不存在就新增// // 不太好模拟 这边改成获取数据 在+1好模拟一点// sysConfigMapper.updateNum(num + 1);// // 模拟业务耗时// ThreadUtil.safeSleep(20); ++i; ThreadUtil.safeSleep(30);
return 0; } @Override public int getI() {
return i; }
复制代码

如果没有锁住,那么每次调用 test_tran 应该是很大可能出现非 200 情况,但是结果是,锁住了


由于 synchronized 是在对象的方法内,锁的是当前对象,打断点也可以看到每次进入的都是同一个对象,所以肯定是锁住的。



这个大家都不陌生吧,我们常用的这个功能来实现一些方法的增强,就好比我们刚才的执行的逻辑都是在 point.proceed()里面,前后的增强并不在锁的范围内,所以肯定是锁定不住的。这也是为什么我们后面有尝试使用 Lock 锁也失效的原因。

@Around("pointCut()")    public Object around(ProceedingJoinPoint point) throws Throwable {
try { // 执行方法前做点什么 return point.proceed(); } catch (Throwable t) { // 遇到异常做点什么 } finally { // 执行结束做点什么 } }
复制代码

解决方法后面也很简单,在调用事务方法之前上锁,再去调用该方法即可。

@GetMapping("test_tran")    public R<Void> testTran() {        // 上面有更新数据库日志 知道停 就没加 CountDownLatch        CountDownLatch countDownLatch = new CountDownLatch(200);        ThreadUtil.execute(() -> {            for (int i = 0; i < 10; i++) {                new Thread(() -> {                    for (int i1 = 0; i1 < 20; i1++) {                        try {                            // 我们把调用开事务方法改成调用其他同步方法 其他同步方法再去调用原先的 testProxy()                            // testBiz.testProxy();                            testBiz.test();                        } finally {                            countDownLatch.countDown();                        }                    }                }).start();            }        });
try { countDownLatch.await(); } catch (InterruptedException e) { throw new RuntimeException(e); } return R.ok(); } // ========== testBiz ========== // testBiz 添加一个test同步方法 通过test去调用 testProxy @Override public synchronized int test() {
TestBiz o = (TestBiz)AopContext.currentProxy(); return o.testProxy(); }
@Override @Transactional(rollbackFor = Exception.class) public int testProxy() {
System.out.println(this.hashCode()); // 之前的业务大致流程是 查询数据是否存在 int num = sysConfigMapper.getNum(); // 如果数据存在就直接返回 不存在就新增 // 不太好模拟 这边改成获取数据 在+1好模拟一点 sysConfigMapper.updateNum(num + 1); // 模拟业务耗时 ThreadUtil.safeSleep(20);
return 0; }
复制代码

第一次调用 test_tran


第二次调用 test_tran


第三次调用 test_tran


可以看到锁住了,数据也正常了,到这里其实就可以结束了,已经很好的解决了之前的问题。但是大家发现了吗,test 中使用了 TestBiz o = (TestBiz)AopContext.currentProxy(); ,调用使用的是 o.testProxy()而不是 this.testProxy()。那么为什么需要多这一步呢?使用 this 去调用有什么问题?

测试

我们再测试一下使用 this 去调用 testProxy(),稍微改造一下

@Override    public synchronized int test() {
// TestBiz o = (TestBiz)AopContext.currentProxy(); return this.testProxy(); }
@Override @Transactional(rollbackFor = Exception.class) public int testProxy() {
System.out.println(this.hashCode()); // 之前的业务大致流程是 查询数据是否存在 int num = sysConfigMapper.getNum(); // 如果数据存在就直接返回 不存在就新增 // 不太好模拟 这边改成获取数据 在+1好模拟一点 sysConfigMapper.updateNum(num + 1); // 模拟业务耗时 ThreadUtil.safeSleep(20); if (true) { throw new RuntimeException("test"); }
return 0; }
复制代码

现在我们数据库的数据是 600


方法调用后应该还是 600,因为全部数据都抛出了异常,但是结果却是 610


我们回顾一下 controller 的方法

ThreadUtil.execute(() -> {            for (int i = 0; i < 10; i++) {                new Thread(() -> {                    for (int i1 = 0; i1 < 20; i1++) {                        try {                            // 我们把调用开事务方法改成调用其他同步方法 其他同步方法再去调用原先的 testProxy()                            // testBiz.testProxy();                            testBiz.test();                        } finally {                            countDownLatch.countDown();                        }                    }                }).start();            }        });
复制代码

开了 10 个线程,每个线程循环 20 次,正常调用一次数据库增加 200 没错,这边改成抛出异常,只执行 10 次,数据库也更新了 10 次,但是我们明明使用了 @Transactional(rollbackFor = Exception.class)为什么数据还是更新了,没有回滚,spring 事务管理出问题了吗???

我们再把 test()的调用改成 AopContext.currentProxy()获取的对象去调用。


调用一次后数据没有变成 620,还是 610,说明事务生效了。

这也会引出另一个问题,事务失效,spring 的事务是通过 AOP 去代理的,通过 this 去调用是不会走代理的,这个时候即使我们 testProxy 使用了 @Transactional(rollbackFor = Exception.class, propagation = Propagation.NEVER)也是不会报错的,因为不会进行增强逻辑,我们可以通过打断点来验证一下。可以看到 this 是 13179


o 是 13181 并且可以看到经过了 cglib 进行代理,也就是进行了代理增强,因此事务正常生效


而不使用代理是真实对象,是不具备事务相关功能的。除了通过 AopContext.currentProxy()我们也可以在当前类(TestBizImpl)再注入一遍,通过注入对象去调用,

@Autowired    private TestBiz testBiz;    @Override    public synchronized int test() {
return testBiz.testProxy(); }
复制代码


同样的效果,事务生效了,至此,我们可以愉快的在一个类里根据不同的传播行为进行逻辑的处理了。

用户头像

Java你猿哥

关注

一只在编程路上渐行渐远的程序猿 2023-03-09 加入

关注我,了解更多Java、架构、Spring等知识

评论

发布
暂无评论
从Spring的AOP看Synchronized锁失效和事务失效的情况_spring_Java你猿哥_InfoQ写作社区