从头到尾说一次 Spring 事务管理（器）

@Transactional

public void methodA(){

jdbcTemplate.batchUpdate(updateSql, params);

methodB();

}

// 传播行为配置为 - 方式2，不使用当前事务，独立一个新事务

@Transactional(propagation = Propagation.REQUIRES_NEW)

public void methodB(){

jdbcTemplate.batchUpdate(updateSql, params);

}

就是这么简单，获取 Connection/多方法共享 Connection/多方法共享+独享 Connection/提交/释放连接之类的操作，完全不需要我们操心，Spring 都替我们做好了。

怎么回滚？

在注解版的事务管理中，默认的的回滚策略是：抛出异常就回滚。这个默认策略挺好，连回滚都帮我们解决了，再也不用手动回滚。 ​

但是如果在嵌套事务中，子方法独立新事务呢？这个时候哪怕抛出异常，也只能回滚子事务，不能直接影响前一个事务

可如果这个抛出的异常不是 sql 导致的，比如校验不通过或者其他的异常，此时应该将当前的事务回滚吗？ ​

这个还真不一定，谁说抛异常就要回滚，异常也不回滚行不行？ ​

当然可以！抛异常和回滚事务本来就是两个问题，可以连在一起，也可以分开处理

// 传播行为配置为 - 方式2，不使用当前事务，独立一个新事务

// 指定 Exception 也不会滚

@Transactional(propagation = Propagation.REQUIRES_NEW, noRollbackFor = Exception.class)

public void methodB(){

jdbcTemplate.batchUpdate(updateSql, params);

}

每个事务/连接使用不同配置

除了传播和回滚之外，还可以给每个事务/连接使用不同的配置，比如不同的隔离级别：

@Transactional

public void methodA(){

jdbcTemplate.batchUpdate(updateSql, params);

methodB();

}

// 传播行为配置为 - 方式2，不使用当前事务，独立一个新事务

// 这个事务/连接中使用 RC 隔离级别，而不是默认的 RR

@Transactional(propagation = Propagation.REQUIRES_NEW, isolation = Isolation.READ_UNCOMMITTED)

public void methodB(){

jdbcTemplate.batchUpdate(updateSql, params);

}

除了隔离级别之外，其他的 JDBC Connection 配置当然也是支持的，比如 readOnly。这样一来，虽然我们不用显示的获取 connection/session，但还是可以给嵌套中的每一个事务配置不同的参数，非常灵活。

功能总结

好了，现在已经了解了 Spring 事务管理的所有核心功能，来总结一下这些核心功能点：

1. 连接/资源管理 - 无需手动获取资源、共享资源、释放资源

2. 嵌套事务的支持 - 支持嵌套事务中使用不同的资源策略、回滚策略

3. 每个事务/连接使用不同的配置

事务管理器（TransactionManager）模型

---

其实仔细想想，事务管理的核心操作只有两个：提交和回滚。前面所谓的传播、嵌套、回滚之类的，都是基于这两个操作。 ​

所以 Spring 将事务管理的核心功能抽象为一个事务管理器（Transaction Manager），基于这个事务管理器核心，可以实现多种事务管理的方式。 ​

这个核心的事务管理器只有三个功能接口：

1. 获取事务资源，资源可以是任意的，比如jdbc connection/hibernate mybatis session之类，然后绑定并存储

2. 提交事务 - 提交指定的事务资源

3. 回滚事务 - 回滚指定的事务资源

interface PlatformTransactionManager{

// 获取事务资源，资源可以是任意的，比如jdbc connection/hibernate mybatis session之类

TransactionStatus getTransaction(TransactionDefinition definition)

throws TransactionException;

// 提交事务

void commit(TransactionStatus status) throws TransactionException;

// 回滚事务

void rollback(TransactionStatus status) throws TransactionException;

}

事务定义 - TransactionDefinition

还记得上面的 @Transactional 注解吗，里面定义了传播行为、隔离级别、回滚策略、只读之类的属性，这个就是一次事务操作的定义。 ​

在获取事务资源时，需要根据这个事务的定义来进行不同的配置：

1. 比如配置了使用新事务，那么在获取事务资源时就需要创建一个新的，而不是已有的

2. 比如配置了隔离级别，那么在首次创建资源（Connection）时，就需要给 Connection 设置 propagation

3. 比如配置了只读属性，那么在首次创建资源（Connection）时，就需要给 Connection 设置 readOnly

为什么要单独用一个 TransactionDefinition 来存储事务定义，直接用注解的属性不行吗？ ​

当然可以，但注解的事务管理只是 Spring 提供的自动挡，还有适合老司机的手动挡事务管理（后面会介绍）；手动挡可用不了注解，所以单独建一个事务定义的模型，这样就可以实现通用。

事务状态 - TransactionStatus

那既然嵌套事务下，每个子方法的事务可能不同，所以还得有一个子方法事务的状态 - TransactionStatus，用来存储当前事务的一些数据和状态，比如事务资源（Connection）、回滚状态等。

获取事务资源

事务管理器的第一步，就是根据事务定义来获取/创建资源了，这一步最麻烦的是要区分传播行为，不同传播行为下的逻辑不太一样。 ​

“默认的传播行为下，使用当前事务”，怎么算有当前事务呢？ ​

把事务资源存起来嘛，只要已经存在那就是有当前事务，直接获取已存储的事务资源就行。文中开头的例子也演示了，如果想让多个方法无感的使用同一个事务，可以用 ThreadLocal 存储起来，简单粗暴。 ​

Spring 也是这么做的，不过它实现的更复杂一些，抽象了一层事务资源同步管理器 - TransactionSynchronizationManager（本文后面会简称 TxSyncMgr），在这个同步管理器里使用 ThreadLocal 存储了事务资源（本文为了方便理解，尽可能的不贴非关键源码）。 ​

剩下的就是根据不同传播行为，执行不同的策略了，分类之后只有 3 个条件分支：

1. 当前有事务 - 根据不同传播行为处理不同

2. 当前没事务，但需要开启新事务

3. 彻底不用事务 - 这个很少用

public final TransactionStatus getTransaction(TransactionDefinition definition) {

//创建事务资源 - 比如 Connection

Object transaction = doGetTransaction();

if (isExistingTransaction(transaction)) {

// 处理当前已有事务的场景

return handleExistingTransaction(def, transaction, debugEnabled);

}else if (def.getPropagationBehavior() == TransactionDefinition.PROPAGATION_REQUIRED ||

def.getPropagationBehavior() == TransactionDefinition.PROPAGATION_REQUIRES_NEW ||

def.getPropagationBehavior() == TransactionDefinition.PROPAGATION_NESTED){

// 开启新事务

return startTransaction(def, transaction, debugEnabled, suspendedResources);

}else {

// 彻底不用事务

}

// …

}

先介绍一下分支 2 - 当前没事务，但需要开启新事务，这个逻辑相对简单一些。只需要新建事务资源，然后绑定到 ThreadLocal 即可：

private TransactionStatus startTransaction(TransactionDefinition definition, Object transaction,

boolean debugEnabled, SuspendedResourcesHolder suspendedResources) {

// 创建事务

DefaultTransactionStatus status = newTransactionStatus(

definition, transaction, true, newSynchronization, debugEnabled, suspendedResources);

// 开启事务（beginTx或者setAutoCommit之类的操作）

// 然后将事务资源绑定到事务资源管理器 TransactionSynchronizationManager

doBegin(transaction, definition);

现在回到分支 1 - 当前有事务 - 根据不同传播行为处理不同，这个就稍微有点麻烦了。因为有子方法独立事务的需求，可是 TransactionSynchronizationManager 却只能存一个事务资源。

挂起（Suspend）和恢复（Resume）

Spring 采用了一种**挂起（Suspend） - 恢复（Resume）**的设计来解决这个嵌套资源处理的问题。当子方法需要独立事务时，就将当前事务挂起，从 TxSyncMgr 中移除当前事务资源，创建新事务的状态时，将挂起的事务资源保存至新的事务状态 TransactionStatus 中；在子方法结束时，只需要再从子方法的事务状态中，再次拿出挂起的事务资源，重新绑定至 TxSyncMgr 即可完成恢复的操作。 ​

整个挂起 - 恢复的流程，如下图所示： ​

注意：挂起操作是在获取事务资源这一步做的，而恢复的操作是在子方法结束时（提交或者回滚）中进行的。 ​

这样一来，每个 TransactionStatus 都会保存挂起的前置事务资源，如果方法调用链很长，每次都是新事务的话，那这个 TransactionStatus 看起来就会像一个链表：

提交事务

获取资源、操作完毕后来到了提交事务这一步，这个提交操作比较简单，只有两步：

1. 当前是新事务才提交

2. 处理挂起资源

怎么知道是新事务？ ​

每经过一次事务嵌套，都会创建一个新的 TransactionStatus，这个事务状态里会记录当前是否是新事务。如果多个子方法都使用一个事务资源，那么除了第一个创建事务资源的 TransactionStatus 之外，其他都不是新事务。 ​

如下图所示，A -> B -> C 时，由于 BC 都使用当前事务，那么虽然 ABC 所使用的事务资源是一样的，但是只有 A 的 TransactionStatus 是新事务，BC 并不是；那么在 BC 提交事务时，就不会真正的调用提交，只有回到 A 执行 commit 操作时，才会真正的调用提交操作。

这里再解释下，为什么新事务才需要提交，而已经有事务却什么都不用做：

因为对于新事务来说，这里的提交操作已经是事务完成了；而对于非新事务的场景，前置事务（即当前事务）还没有执行完，可能后面还有其他数据库操作，所以这个提交的操作得让当前事务创建方去做，这里并不能提交。

回滚事务

除了提交，还有回滚呢，回滚事务的逻辑和提交事务类似：

1. 如果是新事务才回滚，原因上面已经介绍过了

2. 如果不是新事务则只设置回滚标记

3. 处理挂起资源

注意：事务管理器是不包含回滚策略这个东西的，回滚策略是 AOP 版的事务管理增强的功能，但这个功能并不属于核心的事务管理器

自动挡与手动挡

---

Spring 的事务管理功能都是围绕着上面这个事务管理器运行的，提供了三种管理事务的方式，分别是：

1. XML AOP 的事务管理 - 比较古老现在用的不多

2. 注解版本的事务管理 - @Transactional

3. TransactionTemplate - 手动挡的事务管理，也称编程式事务管理

自动挡

XML/@Transactional 两种基于 AOP 的注解管理，其入口类是 TransactionInterceptor，是一个 AOP 的 Interceptor，负责调用事务管理器来实现事务管理。 ​

因为核心功能都在事务管理器里实现，所以这个 AOP Interceptor 很简单，只是调用一下事务管理器，核心（伪）代码如下：

public Object invoke(MethodInvocation invocation) throws Throwable {

// 获取事务资源

Object transaction = transactionManager.getTransaction(txAttr);

Object retVal;

try {

// 执行业务代码

retVal = invocation.proceedWithInvocation();

// 提交事务

transactionManager.commit(txStatus);

} catch (Throwable ex){

// 先判断异常回滚策略，然后调用事务管理器的 rollback

rollbackOn(ex, txStatus);

}

}

并且 AOP 这种自动挡的事务管理还增加了一个回滚策略的玩法，这个是手动挡 TransactionTemplate 所没有的，但这个功能并不在事务管理器中，只是 AOP 版事务的一个增强。

手动挡

TransactionTemplate 这个是手动挡的事务管理，虽然没有注解的方便，但是好在灵活，异常/回滚啥的都可以自己控制。 ​

所以这个实现更简单，连异常回滚策略都没有，特殊的回滚方式还要自己设置（默认是任何异常都会回滚），核心（伪）代码如下：

public T execute(TransactionCallback action) throws TransactionException {

// 获取事务资源

TransactionStatus status = this.transactionManager.getTransaction(this);

T result;

try {

// 执行 callback 业务代码

result = action.doInTransaction(status);
自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数Java工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则几千的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年Java开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Java开发知识点，真正体系化！

由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！

如果你觉得这些内容对你有帮助，可以扫码获取！！（备注Java获取）

Kafka实战笔记

关于这份笔记，为了不影响大家的阅读体验，我只能在文章中展示部分的章节内容和核心截图

• Kafka入门
• 为什么选择Kafka
• Karka的安装、管理和配置

• Kafka的集群
• 第一个Kafka程序
• 

afka的生产者

• Kafka的消费者
• 深入理解Kafka
• 可靠的数据传递

• Spring和Kalka的整合
• Sprinboot和Kafka的整合
• Kafka实战之削峰填谷
• 数据管道和流式处理(了解即可)

• Kafka实战之削峰填谷

《一线大厂Java面试题解析+核心总结学习笔记+最新讲解视频+实战项目源码》，点击传送门即可获取！
第一个Kafka程序

• [外链图片转存中…(img-MhqOSOn5-1711881481501)]

afka的生产者

[外链图片转存中…(img-FixLX8OR-1711881481502)]

• Kafka的消费者
• 深入理解Kafka
• 可靠的数据传递

[外链图片转存中…(img-Ueqi4E2c-1711881481502)]

[外链图片转存中…(img-3YD0mZbu-1711881481503)]

• Spring和Kalka的整合
• Sprinboot和Kafka的整合
• Kafka实战之削峰填谷
• 数据管道和流式处理(了解即可)

[外链图片转存中…(img-hEzwHVMA-1711881481503)]

• Kafka实战之削峰填谷

[外链图片转存中…(img-UgangVqs-1711881481505)]

《一线大厂Java面试题解析+核心总结学习笔记+最新讲解视频+实战项目源码》，点击传送门即可获取！