Spring是如何保证同一事务获取同一个Connection的？使用Spring的事务同步机制解决：数据库刚插入的记录却查询不到的问题【享学Spring】(上)-阿里云开发者社区

link管理

链接快照平台

输入网页链接，自动生成快照
标签化管理网页链接

前言

关于Spring的事务，它是Spring Framework中极其重要的一块。前面用了大量的篇幅从应用层面、原理层面进行了比较全方位的一个讲解。但是因为它过于重要，所以本文继续做补充内容：Spring事务的同步机制（后面还有Spring事务的监听机制）

Spring事务同步机制？我估摸很多小伙伴从来没听过还有这么一说法，毕竟它在平时开发中你可能很少遇到（如果你没怎么考虑过系统性能和吞吐量的话）。

让我记录本文的源动力是忆起两年前自己在开发、调试过程中遇到这样一个诡异异常：

java.sql.SQLException: Connection has already been closed

但是，它不是必现的 ，重点：它不是必现的。

而一旦出现，任何涉及需要使用数据库连接的接口都有可能报这个错（已经影响正常work了）， 重启也解决不了问题的根本。

关于非必现问题，我曾经表达了一个观点：程序中的“软病（非必现问题）”是相对很难解决的，因为定位难度高，毕竟只要问题一旦定位了，从来不差解决方案

这个异常的字面意思非常简单： 数据库连接池连接被关闭了。

可能大多数人（我当然也不例外）看到此异常都会fuck一句：what？我的连接都是交给Spring去管理了，自己从来不会手动close，怎么回事？ 难道Spring有bug？

敢于质疑“权威”一直以来都是件好事，但是有句话这么说：你对人家还不了解的情况下不要轻易说人家程序有bug。

可能大多数人对于Spring的事务，只知道怎么使用，比如加个注解啥的，但是底层原理并不清楚，因此定位此问题就会变得非常的困难了~

由于我之前有研究过Spring事务的同步机制这块，所以忆起这件事之后就迅速定位了问题所在： 这和Spring事务的同步机制有关，并不是Spring事务的bug。

Spring事务极简介绍

关于Spring事务，我推荐小伙伴看看上面的【相关阅读】，能让你对Spring事务管理有个整体的掌握。但是由于过了有段时间了，此处做个非常简单的介绍：

Spring有声明式事务和编程式事务：

声明式事务 只需要提供@Transactional的注解，然后事务的开启和提交/回滚、资源的清理就都由spring来管控，我们只需要关注业务代码即可；

编程式事务则 需要使用spring提供的模板，如TransactionTemplate，或者直接使用底层的PlatformTransactionManager手动控制提交、回滚。

声明式事务的最大优点就是对代码的 侵入性小 ，只需要在方法上加@Transactional的注解就可以实现事务；

编程式事务的最大优点就是事务的 管控粒度较细 ，可以实现代码块级别的事务。

前提介绍

Spring把JDBC 的 Connection或者Hibernate的Session等访问数据库的链接（会话）都统一称为资源，显然我们知道Connection这种是线程不安全的，同一时刻是不能被多个线程共享的。

简单的说：同一时刻我们每个线程持有的Connection应该是独立的，且都是互不干扰和互不相同的

但是Spring管理的Service、Dao等他们都是无状态的单例Bean，怎么破？ ，如何保证单例Bean里面使用的Connection都能够独立呢？

Spring引入了一个类：事务同步管理类org.springframework.transaction.support.TransactionSynchronizationManager来解决这个问题。它的做法是内部使用了很多的ThreadLocal为不同的事务线程提供了独立的资源副本， 并同时维护这些事务的配置属性和运行状态信息（比如强大的事务嵌套、传播属性和这个强相关）。

这个同步管理器TransactionSynchronizationManager是掌管这一切的大脑，它管理的TransactionSynchronization是开放给调用者一个非常重要的扩展点，下面会有详细介绍~

TransactionSynchronizationManager 将 Dao、Service 类中影响线程安全的所有 “ 状态 ” 都统一抽取到该类中，并用 ThreadLocal 进行封装，这样一来， Dao （基于模板类或资源获取工具类创建的 Dao ）和 Service （采用 Spring 事务管理机制）就不用自己来保存一些事务状态了， 从而就变成了线程安全的单例对象了，优秀~

DataSourceUtils

这里有必要提前介绍Spring提供给我们的这个工具类。

有些场景比如我们使用MyBatis的时候，某些场景下，可能无法使用 Spring 提供的模板类来达到效果 ，而是需要直接操作源生API Connection。

那如何拿到这个链接Connection呢？？？（主意此处打大前提 ：必须保证和当前MaBatis线程使用的是同一个链接，这样才接受本事务控制嘛，否则就脱缰了~）

这个时候DataSourceUtils这个工具类就闪亮登场了，它提供了这个能力：

public abstract class DataSourceUtils {
    public static Connection getConnection(DataSource dataSource) throws CannotGetJdbcConnectionException { ... }
    // 把definition和connection进行一些准备工作~
    public static Integer prepareConnectionForTransaction(Connection con, @Nullable TransactionDefinition definition) throws SQLException { ...}
    // Reset the given Connection after a transaction,
    // con.setTransactionIsolation(previousIsolationLevel);和con.setReadOnly(false);等等
    public static void resetConnectionAfterTransaction(Connection con, @Nullable Integer previousIsolationLevel) { ... }
    // 该JDBC Connection 是否是当前事务内的链接~
    public static boolean isConnectionTransactional(Connection con, @Nullable DataSource dataSource) { ... }
    // Statement 给他设置超时时间  不传timeout表示不超时





    
    public static void applyTransactionTimeout(Statement stmt, @Nullable DataSource dataSource) throws SQLException { ... }
    public static void applyTimeout(Statement stmt, @Nullable DataSource dataSource, int timeout) throws SQLException { ... }
    // 此处可能是归还给连接池，也有可能是close~（和连接池参数有关）
    public static void releaseConnection(@Nullable Connection con, @Nullable DataSource dataSource) { ... }
    public static void doReleaseConnection(@Nullable Connection con, @Nullable DataSource dataSource) throws SQLException { ... }
    // 这个是真close
    public static void doCloseConnection(Connection con, @Nullable DataSource dataSource) throws SQLException { ... }
    // 如果链接是代理，会拿到最底层的connection
    public static Connection getTargetConnection(Connection con) { ... }

getConnection()这个方法就是从TransactionSynchronizationManager里拿到一个现成的Connection（若没有现成的会用DataSource创建一个链接然后放进去~~~），所以这个工具类还是蛮好用的。

其实Spring不仅为JDBC提供了这个工具类，还为Hibernate、JPA、JDO等都提供了类似的工具类。

org.springframework.orm.hibernate.SessionFactoryUtils.getSession()

org.springframework.orm.jpa.EntityManagerFactoryUtils.getTransactionalEntityManager()

org.springframework.orm.jdo.PersistenceManagerFactoryUtils.getPersistenceManager()

问题场景一模拟

为了更好解释和说明，此处我模拟出这样的一个场景。

// 此处生路而关于DataSource、PlatformTransactionManager事务管理器等的配置
@Slf4j
@Service
public class HelloServiceImpl implements HelloService {
    @Autowired
    private JdbcTemplate jdbcTemplate;
    @Transactional
    @Override
    public Object hello(Integer id) {
        // 向数据库插入一条记录
        String sql = "insert into user (id,name,age) values (" + id + ",'fsx',21)";
        jdbcTemplate.update(sql);
        // 做其余的事情  可能抛出异常
        System.out.println(1 / 0);
        return "service hello";

如上Demo，这样子的因为有事务，所以最终这个插入都是不会成功的。(这个应该不用解释了吧，初级工程师应该必备的“技能”~)

    @Transactional
    @Override
    public Object hello(Integer id) {
        // 向数据库插入一条记录
        String sql = "insert into user (id,name,age) values (" + id + ",'fsx',21)";
        jdbcTemplate.update(sql);
        // 根据id去查询获取 总数（若查询到了肯定是count=1）
        String query = "select count(1) from user where id = " + id;
        Integer count = jdbcTemplate.queryForObject(query, Integer.class);
        log.info(count.toString());
        return "service hello";

稍微改造一下，按照上面这么写，我相信想都不用想。count永远是返回1的~~这应该也是我们面向过程编程时候的经典案例： 前面insert一条记录，下面是可以立马去查询出来的

下面我把它改造如下：

    @Transactional
    @Override
    public Object hello(Integer id) {
        // 向数据库插入一条记录
        String sql = "insert into user (id,name,age) values (" + id + ",'fsx',21)";
        jdbcTemplate.update(sql);
        // 生产环境一般会把些操作交给线程池，此处我只是模拟一下效果而已~
        new Thread(() -> {
            String query = "select count(1) from user where id = " + id;
            Integer count = jdbcTemplate.queryForObject(query, Integer.class);
            log.info(count.toString());
        }).start();
        // 把问题放大
        try {
            TimeUnit.SECONDS.sleep(2);





    
        } catch (InterruptedException e) {
            e.printStackTrace();
        return "service hello";

经过这番改造，这样我们的count的值 永远是0（是不是不符合预期了？） 。

小技巧：此处为了演示我使用sleep方式把问题放大了，否则可能有时候好使、有时候不好使把问题放大是debug调试的一个基本技巧~

这个现象就是一个 非常严重 的问题，它可能会出现：刚插入的数据竟然查不到的诡异现象，这个在我们现阶段平时工作中也会 较为频繁的遇到 ，若对这块不了解，它会对的业务逻辑、对mysql binlog的顺序有依赖的相关逻辑全都将会受到影响

解决方案

在互联网环境编程中，我们经常为了提高吞吐量、程序性能，会使用到异步的方式进行优化、消峰等等。因此连接池、线程池被得到了大量的应用。我们知道异步的提供的好处不言而喻，能够尽最大可能的提升硬件的利用率和能力 ，但它带来的缺点只有一个：提升系统的复杂性， 很多时候需要深入的了解它才能运用自如，毕竟任何方案都是一把双刃剑，没有完美的~

比如一个业务处理中，发短信、发微信通知、记录操作日志等等这些非主干需求，我们一般都希望交给线程池去处理而不要干扰主要业务流程，所以我觉得现在多线程方式处理任务的概率已经越来越高了~

既然如此，我觉得出现上面我模拟的这种现象的可能性还是蛮高的，所以希望小伙伴们能引起重视一些。

定位到问题的原因是解决问题的关键 ，这里我先给出直接的解决方案，再做理论分析。

我们的诉求是：我们的异步线程的执行时，必须确保记录已经持久化到数据库了才ok。因此可以这么来做，一招制敌：

@Slf4j
@Service
public class HelloServiceImpl implements HelloService {
    @Autowired
    private JdbcTemplate jdbcTemplate;
    @Transactional
    @Override
    public Object hello(Integer id) {
        // 向数据库插入一条记录
        String sql = "insert into user (id,name,age) values (" + id + ",'fsx',21)";
        jdbcTemplate.update(sql);
        TransactionSynchronizationManager.registerSynchronization(new TransactionSynchronizationAdapter() {
            // 在事务提交之后执行的代码块（方法）  此处使用TransactionSynchronizationAdapter，其实在Spring5后直接使用接口也很方便了~
            @Override
            public void afterCommit() {
                new Thread(() -> {
                    String query = "select count(1) from user where id = " + id;
                    Integer count = jdbcTemplate.queryForObject(query, Integer.class);
                    log.info(count.toString());
                }).start();
        // 把问题放大
        try {
            TimeUnit.SECONDS.sleep(2);
        } catch (InterruptedException e) {
            e.printStackTrace();
        return "service hello";

我们使用TransactionSynchronizationManager注册一个TransactionSynchronization然后在afterCommit里执行我们的后续代码，这样就能100%确保我们的后续逻辑是在当前事务被commit后才执行的，完美的问题解决

它还有个方法afterCompletion()有类似的效果，至于它和afterCommit()有什么区别，我觉得稍微有点技术敏感性的小伙伴都能知晓的~

面试官：Spring@Transactional注解在什么情况下事务不生效？

这篇笔记来学习一下使用Spring框架的时候，@Transactional注解标注的方法在什么情况下事务不会生效。我们可以写一个demo项目，引入以下依赖

这些Spring事务传播性类型，你有必要了解下

在Spring框架中，事务传播性是一个重要概念，决定了事务在方法间的传播和交互方式。了解不同的事务传播特性可以帮助我们设计可靠、灵活的系统。

这些让Spring事务失效的操作千万别犯！

在Spring框架中，事务是一种关键机制，用于确保数据库操作的一致性和完整性。然而，有时候事务可能会失效，导致意外的结果或数据不一致。下面是一些可能导致Spring事务失效的常见场景，以及相应的代码示例和解释。

踩坑：以为是Redis缓存没想到却是Spring事务!

最近碰到了一个Bug，折腾了我好几天。并且这个Bug不是必现的，出现的概率比较低。一开始我以为是旧数据的问题，就让测试重新生成了一下数据，重新测试。由于后面几轮测试均未出现，我也就没太在意。

2.JWT令牌全称:JSON Web Token (https:/ljwt.io/) 定义了一种简洁的、自包含的格式，用于在通信双方以json数据格式安全的传输信息。由于数字签名的存在，这些信息是可靠的。第一部分:Header(头），记录令牌类型、签名算法等。例如: {“alg”:“HS256” ,“type” :“JWT”} 第二部分: Payload(有效载荷），携带一些自定义信息、默认信息等。例如:{“id”.“1” ,“username”:“Tom”} 第三部分: Signature(签名)，防止Token被篡改、确保安全性。将header、 payload，并加入指定秘钥

Spring Boot2.x-10 基于Spring Boot 2.1.2 + Mybatis 2.0.0实现多数据源，支持事务

(万字总结)spring事务失效的12种场景, 实在太坑了

为了保障操作的原子性, 避免数据不一样的情况,我们一般都会用到spring事务.但spring事务失效的12种场景, 实在太坑了

前言

​

Spring事务极简介绍

前提介绍

问题场景一模拟