【高并发基础】Spring 事务传播级别及造成死锁的隐患分析

前言

本项目聚焦高并发的基础知识，至底向上得研究：

• 单机事务模型（Mysql事务）
• 单机事务模型（Spring事务传播 ） <===== 本文坐标
• 单机高并发 （多线程 -> 缓存）
• 集群 ( 集群 -> 分布式 -> 微服务 -> 服务治理)
• 读密集（数据仓库、搜索引擎）
• 写密集（TODO）
  

项目介绍

github 仓库 (分支 master / isolation / propagation / multithreading)

理念：

• 使用Spring Boot 和基于Groovy的测试框架Spock编写测试用例。
• 证实并发隐患后(脏读、更新丢失、不可重复读、幻读等)，用官方文档加以说明解释，并沉淀用例。
• 不合理的解决方案造成死锁，沉淀用例
• 较合理的解决方案，沉淀用例

分支组成

• Spock 与 Spring Boot 集成 master 分支
• Mysql-Innodb 的事务隔离及常用锁 isolation 分支
• Spring 事务传播行为 propagation 分支 <===== 本文坐标
• Java JUC 多线程编程（Doing）multithreading 分支
• 升级项目为MySQL集群（Todo）

Spring 官方介绍的事务传播行为

事务传播行为官网描述
用于区分声明式事务catch到异常由框架回滚，本文的“回滚”用到编程式事务的API TransactionAspectSupport.currentTransactionStatus().setRollbackOnly() 支持主动回滚。编程式事务官网描述
讨论的模型是 调用方（外层） -> 被调用方（内层）

• 传播行为是发生在两个事务之间，即外层内层都声明了事务保护，只是传播行为可能存在不同。
• 重点关心被调用方的行为即可。只有内层被调用才能让传播行为生效。
• 忽略掉一种讨论：内层抛Exception不catch被外层捕获，内外层的代码都会回滚

required

默认传播行为, 确保当前方法一定处于事务保护中

• 如果调用方不存在事务，则新创建一个事务（只保护自己的代码）
• 如果调用发存在事务，则加入到调用方的事务，即扩大了调用方事务的范围
• 回滚处理
  • 外层无事务
    • 内层回滚, 只回滚内层代码
  • 外层有事务
    • 内层回滚 抛出UnexpectedRollbackException

    因为内层加入到外层事务中，形成一个大事务，TransactionAspectSupport.currentTransactionStatus().setRollbackOnly() 会把外层的代码一并提交，内层代码执行完毕，外层代码继续执行。由于声明式事务，外层代码执行结束，会触发一次提交，但是这次提交的事务已经被内层提交了，所以抛异常。

    • 外层回滚，内外都回滚

requires_new

用于减少事务的粒度，如果不是关键的业务逻辑或是运行出错的逻辑，可以用requires_new 声明与调用方事务隔离。

• 无论调用方是否存在事务，自己都会新增一个事务给自己执行
• 外层无事务
  • 内层回滚同required
• 外层有事务
  • 内层回滚，只回滚内层代码，后续不会出现required 的异常
  • 外层回滚，只回滚外层代码

nested

只适用于JDBC。介于required 和 nested 之间，内层事务处于一个“寄生”的状态，他的附加价值是可以减少死锁隐患，后文会提到。

• 外层无事务
  • 内层同required
• 外层有事务
  • 内层同 requires_new

requires_new 造成的死锁分析

1. 外层事务A对记录record加了写锁
2. 外层事务调用了 requires_new 声明的内层事务B
3. 内层事务B也对record申请加锁请求

由于事务A和事务B属于不同事务，A未提交并持有record的写锁不释放，
事务B一直等待A释放，事务A又等待事务B提交自己才能提交。所以互相等待，造成锁等待超时。

nested 取代 requires_new 减少死锁隐患

nested 声明的内层事务被外层调用，视为“寄生”在外层的事务中。也就不存在事务竞争资源。
同时 nested 支持独立回滚，是由底层JDBC的savepoint 支持，API例子：

		transactionTemplate.execute(new TransactionCallbackWithoutResult() {
              protected void doInTransactionWithoutResult(TransactionStatus status) {
                    status.createSavepoint();
                    status.rollbackToSavepoint();
              }
       }
1
2
3
4
5
6