事务与锁当Transactional遇上synchronized

Posted 一个有梦有戏的人

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了事务与锁当Transactional遇上synchronized相关的知识，希望对你有一定的参考价值。


事务与锁 - Transactional与Synchronize🥰

前言

最近工作中遇到某些七七八八的问题，就是与事务和锁、并发都有着紧密联系相关的问题所在。主要情况是：通过调用方法获取编号，而这个编号是递增有序的，并且存在于数据库中，简单理解就是需要用到这种编号(以下称任务编号)，需要从数据库获取出来，在+1最为本次需要的编号，然后在存回数据库中，提供下次使用。直观来看是没得问题的，但是，可能在某次并发的时候出现编号相同，着属实很令人头疼，在经过领导的指导下是完美的解决了，接下来复盘一下。

问题回放

因为公司项目使用WQL作为持久层，但是我这次使用Mybatis-Plus，效果大差不差。新建springboot项目，基础创建不在赘述。主要创建一张简单的数据表，就一个id和number字段。之后用mp自动生成代码。

问题一

最外层加上Transactional注解，并且在对编码操作的方法也加了Transactional注解，为了防止并发问题，加了锁。此时模拟的问题是：在嵌套事务中，父事务延时提交导致获得到的数据出错。

1、代码与结果复现

直接在控制层中调用，这里会加上Transactional，并且一开始数据库数据为“id”:“1”, “number”:“460”

@GetMapping("/t1")
@Transactional(rollbackFor = Exception.class)
public void getTest1() 
    String n = countNumService.getCount();
    System.out.println(" t1 : " + n);
    try 
        Thread.sleep(6000);
     catch (InterruptedException e) 
        throw new RuntimeException(e);
    


@GetMapping("/t2")
@Transactional(rollbackFor = Exception.class)
public void getTest2() 
    String n = countNumService.getCount();
    System.out.println(" t2 : " + n);
    // 忽略其他的增删操作

对数据库获取操作的方法，加上Transactional与synchronized。

@Override
@Transactional(rollbackFor = Exception.class)
public synchronized String getCount() 
    // 获取
    CountNum countNum = countNumMapper.selectById(1);

    countNum.setNumber(countNum.getNumber() + 1);
    // 修改
    countNumMapper.updateById(countNum);

    return countNum.getNumber().toString();

通过IDEA的插件RestServices(也可以用postman)测试，先请求/t1接口，这里会睡眠6s来模拟事务延时提交，在去请求/t2接口，可以看出得到的数据会是相同的。

2、原因分析

只有两个线程都能形成两个相同的code，仔细分析一下，假设synchronized锁是锁住的，那为什么会出现这样的问题呢？当t1线程访问getCount()方法，此时他拿到synchronized的锁，在进行获取数据并且+1操作后进行update操作，此时synchronized的锁已经被释放了，但是父事务却没有提交，也就是没有写回到数据库中，接下来t2线程过来了，也拿到了这把锁，又从数据库获取了数据，此时获得的是脏数据，最后就会导致出现了相同的code。

3、解决方法

这里是因为事务的先后提交导致，可以使用Transactional注解的配置来解决，使用@Transactional(propagation = Propagation.REQUIRES_NEW)，每次都会启动一个新的事务，是Spring事务传播机制的一种级别，表示当前方法必须在自己的事务中运行，如果当前已经存在一个事务，则会挂起该事务，创建一个新的事务用于执行当前方法。当当前方法执行完成后，新事务被提交，原事务恢复执行。

问题二

此次测试是使用apache-jmeter-5.4.3测试工具来测试20次请求的并发情况（接口每次会创建100次，一共会又20*100次），在以上代码的条件下编写新的接口。

1、问题复现

以下是每次请求都会创建100个线程，getCount()除了使用propagation = Propagation.REQUIRES_NEW，其他不变。

@GetMapping("/t3")
@Transactional(rollbackFor = Exception.class)
public void getTest1() 
    for (int i = 0; i <100 ; i++) 
        new Thread(()->
            String taskCode = countNumService.getCount();
            System.out.println("t1 " + Thread.currentThread().getName() + " code: " + taskCode);
        ).start();

测试结果就会发现并发下出现了种种问题，会出现相同的code。

2、原因分析

这是由于父子事务嵌套，子事务与锁一起使用，导致了synchronized锁的失效。当我把事务去掉的时候，则就不会出现并发的问题。

问题就是出在事务与synchronized锁的共同使用导致的，如果既要保证并发不出问题，又要保证在异常的时候需要回滚数据，在实际应用中，getCount()内部又其他对数据库的操作，因此需要事务来保证异常的回滚，也就是一定需要父子事务的嵌套，在这种情况下需要怎么做处理？
首先先来了解事务Transactional与锁synchronized一同使用会带来什么问题。

事务Transactional与锁synchronized

事务Transactional与锁synchronized他们是两种不一样的机制，两种机制要是一起使用，可能会出现一些问题。

1、synchronized与Transactional区别

首先，synchronized锁是用来实现线程同步，防止多个线程同时访问共享资源导致的并发问题。而Transactional是Spring框架中用于管理事务的机制，用于保证多个操作的四个特性（原子性、一致性、隔离性和持久性）。

2、可能带来的问题

  1. 事务可能被锁定：如果在一个方法中使用synchronized锁定了某个共享资源，同时该方法又使用了Transactional来管理事务，那么其他线程在访问该方法时可能会被阻塞，因为事务被锁定了。
  2. 死锁问题：如果在多个线程中同时使用synchronized和Transactional，可能会导致死锁问题，因为synchronized锁定的资源可能被多个线程同时访问，而Transactional又会对这些操作进行管理，可能会导致事务的死锁。
  3. 性能问题：如果在一个高并发的系统中同时使用synchronized和Transactional，可能会导致性能问题，因为synchronized会导致线程阻塞，而Transactional又会增加事务的开销，从而影响系统的性能。

3、针对问题二的解决

可以将子事务中的锁移到父事务中，优化一下细粒度，就只对获取任务编码的这条语句进行上锁。

@GetMapping("/t4")
@Transactional(rollbackFor = Exception.class)
public void getTest4() 
    for (int i = 0; i <100 ; i++) 
        new Thread(()->
            synchronized(CountNumController.class) 
                String taskCode = countNumService.getCount();
                System.out.println("t4 " + Thread.currentThread().getName() + " code: " + taskCode);
            
        ).start();

这样就能保证并发不出问题，也能保证将父子事务都存在。

👍创作不易，如有错误请指正，感谢观看！记得点赞哦！👍

MySQL事务处理特性的实现原理

摘要：事务这个词来自于英语中的transactional这个词的翻译，这个词的含义更多的是指 “交易”。在数据库系统或者软件系统中我们通常 称 transactional 为事务

本文分享自华为云社区《【数据库事务与锁机制】- 事务的隔离级别》，原文作者：技术火炬手 。

事务这个词来自于英语中的transactional这个词的翻译，这个词的含义更多的是指 “交易”。在数据库系统或者软件系统中我们通常 称 transactional 为事务。

数据库事务的四个特性 ACID：分别是 原子性、一致性、隔离性、持久性。数据库事务的这四大特性来源于 ISO标准的 ISO/IEC 10026-1:1992/COR 1:1996，它定义了事务需要具备以上四个特性。那么在InnoDB中是如何实现这些特征的呢？下面内容我们讨论 MySQL （下指InnoDB引擎）对事务特性的支持是怎么实现的。

讨论MySQL的事务处理特性的实现原理之前我们需要先了解下MySQL对MVCC的支持，关于MVCC 维基百科有如下解释。

多版本并发控制(Multiversion concurrency control， MCC 或 MVCC)，是数据库管理系统常用的一种并发控制，也用于程序设计语言实现事务内存。MVCC意图解决读写锁造成的多个、长时间的读操作饿死写操作问题。每个事务读到的数据项都是一个历史快照（snapshot)并依赖于实现的隔离级别。写操作不覆盖已有数据项，而是创建一个新的版本，直至所在操作提交时才变为可见。快照隔离使得事物看到它启动时的数据状态

数据库事务的隔离级别

为了实现事务的隔离性，ISO 标准组织对事务锁需要实现的隔离级别有四种定义，下面我们先对四种事务隔离的级别简单阐述一下。

READ UNCOMMITTED 读未提交

RU(READ UNCOMMITTED) 被称为读未提交，有些资料称之为浏览稳定（browse access）但是正确的翻译应该是未提交读。RU是最低标准的隔离，未提交读的意思就是在事务并发的情况下，可以容许一个事务在没有提交修改的的情况下被另外一个事务读取到这个修改，这就就会产生脏读的情况。下面这个表格是各个事务隔离级别对于脏读、幻读、可重复读的抑制情况,事实上RU不但会产生脏读的情况而且其他两种读的情况都会发生。

首先我们有必要澄清一下以上三种数据读问题的概念，对于数据库事务来说我们简单的认识是一系列的数据库操作在一个事务中，这个事务要不全部成功要不全部失败，但是要知道数据库在实际使用的过程中不是串行的，它是并发的，串行场景下我们事先事务就非常简单了，就是一个一个操作嘛，大家排队执行。但是在并发事务的场景下就会出现对同一个数据的竞争问题，简单的理解就是你也要读写这个数据，我也要读写这个数据，那么大家多个事务操作一个数据的时候怎么保证数据的一致和完整？这个时候就会出现数据的脏读、幻读、重复读问题。

脏读

当一个事务允许读取另外一个事务修改但未提交的数据时，就可能发生脏读（dirty reads）

脏读是指多个事务同时读写一个数据，当事务1中修改和读取数据A时，事务2对数据A做了修改，然后这个修改反映到了事务A中。

我们试想有这样的场景，假如两个事务都在操作金额表中的同一条记录，事务A需要获得到当前金额值然后给他做加3的操作（用于买黄瓜）,原来这个金额的值是5,但是此时事务B将这条数据的金额修改成了8，然后这个修改被事务A拿到然后在8的基础上加了3等于11。但是万万没想到在A事务做完这个操作以后B事务回滚了（反悔了，香蕉的钱没给）。这个时候A事务完成以后账户的金额莫名其妙的变成了11，但是事实上应该是8。这也就是脏读的情况。

不可重复读

在一次事务中，当一行数据获取两遍得到不同的结果表示发生了不可重复读（non-repeatable reads）

在理解不可重复读之前先理解什么是可重复读，可重复读的意思就是在一个事务中对同一个数据的多次读取其结果应该是相同的（在这个事务中没有修改它的值）。那么反过来的意思就是在一个事务中对一个数据的多次读取的值是不一样的，什么情况下会出现不可重复读呢？

还是上面的例子，假如事务A在做加3操作之前先读取了原来的值也就是5，然后继续其他操作，这个时候事务B对这条记录进行了加3的操作然后提交了，当事务A再次读这个值的时候发现当前值变成了8，这个时候前后两次的值完全不一样，这也就是不可重复读。

不可重复读是针对单个事务来说的，也就是在一个事务中是否可以对一条数据做重复的读取，如果不能，那么也就意味着不满足可重复读的要求。

不可重复读和脏读非常类似，但是两者是有区别的脏读是指事务2没有提交这个修改就被事务1获取到了修改后的值，而不可重复读是指提交了修改以后产生了不一致的情况。

幻读

在事务执行过程中，当两个完全相同的查询语句执行得到不同的结果集。这种现象称为幻读（phantom read）

幻读实际上是不可重读的一种场景，比如在事务1中，第一次按照某个条件读取到了3条数据，但是此时事务2在这个表中添加了一条满足此条件的数据，在事务1第二次读的时候发现多了一条数据（反过来就是少了一条数据）,这时候对于事务1来说就有点莫名其妙了，貌似产生了幻觉（发多货了），所以称之为幻读。

所以针对未提交读这种隔离级别，这三种读问题都有可能产生，所以它是级别最低的事务隔离。

READ COMMITTED 读提交

RC(READ COMMITTED) 读提交是指在提交以后可以读，有些资料称之为提交读（国内翻译也是醉了）。提交读主要针对的场景是UPDATE语句，就是针对更新只有提交了以后才能读，试想一下在上面介绍脏读的时候，如果事务2在修改完金额以后提交了这个值而不是回滚，那么久没有脏读的情况。

这也就是为什么提交读只能解决脏读的问题而不能解决其他两种读的问题。因为很显然就算事务2提交了这次修改，那么对于事务1来说前后两次的读取都是不一致的（不可重复读），当然幻读的场景更是存在了，因为幻读本来就是不可重复读的特殊场景。

REPEATABLE READS 可重复读

RR(REPEATABLE READS)可重复读是仅次于SERIALIZABLE（串行化）的一种事务隔离级别，通常可重复读是通过锁实现的，它避免不了幻读的产生。在InnoDB中默认采用RR这种事务隔离级别，但是和其他数据库不同的是InnoDB在在RR的事务隔离级别下采用了NKL的锁算法（Next-Key Lock），避免了幻读的产生。这与其他数据库不同，所以在InnoDB中RR的事务隔离级别达到了串行化的事务隔离标准。

NKL是指锁定一个范围和数据本身，而不是只单单锁定数据本身，这样能够避免幻读的产生，官方文档

SERIALIZABLE 可串行化

是最高级别的事务隔离，按照定义是指所有事务都按照串行化进行执行，也就是没有并发事务的产生，这样就避免了所有读问题，但是这对于数据库来说是不可能的，因为任何一个数据库都不能忍受这种情况，所以大多数人认为采用这种事务隔离级别会对性能产生非常大的影响，但是有些论文通过实验得出串行化并不会对性能产生太大的影响。

关于串行化是不是对性能产生影响，这取决于数据库对这种事务隔离级别的实现，不能完全说串行就一定慢，反正我是不知道是不是真的对性能影响很大。

MySQL数据库事务隔离级别查询和修改

查询事务隔离级别

在MySQL中我们可以通过以下方式查询数据库采用的事务隔离级别

show variables like '%tx_isolation%';
 
# 查询回话的事务隔离级别
SELECT @@session.tx_isolation;
#查看全局的隔离级别
SELECT @@global.tx_isolation;

修改事务隔离级别

MySQL 提供了 SET TRANSACTION 语句，该语句可以改变单个会话或全局的事务隔离级别。语法格式如下：

SET [SESSION | GLOBAL] TRANSACTION ISOLATION LEVEL {READ UNCOMMITTED | READ COMMITTED | REPEATABLE READ | SERIALIZABLE}

其中，SESSION 和 GLOBAL 关键字用来指定修改的事务隔离级别的范围

  • SESSION：表示修改的事务隔离级别将应用于当前 session（当前 cmd 窗口）内的所有事务；
  • GLOBAL：表示修改的事务隔离级别将应用于所有 session（全局）中的所有事务，且当前已经存在的 session 不受影响；

如果省略 SESSION 和 GLOBAL，表示修改的事务隔离级别将应用于当前 session 内的下一个还未开始的事务。

任何用户都能改变会话的事务隔离级别，但是只有拥有 SUPER 权限的用户才能改变全局的事务隔离级别

JDBC 修改当前连接的隔离级别

connection.setTransactionIsolation(Connection.TRANSACTION_READ_UNCOMMITTED);

 

点击关注，第一时间了解华为云新鲜技术~

以上是关于事务与锁当Transactional遇上synchronized的主要内容，如果未能解决你的问题，请参考以下文章

MySQL事务处理特性的实现原理

MySQL事务处理特性的实现原理

面试突击86：SpringBoot 事务不回滚？怎么解决？

Oracle事务与锁

事务4-事务与锁

数据库事务与锁