Spring事务管理高频面试题（真实面试版）

Spring事务管理高频面试题（真实面试版）一、基础认知类（初级必问）1.说说你对Spring事务的理解？什么是声明式事务、编程式事务？参考答案：Spring事务核心是为Java业务操作提供统一的事务管控能力，保证数据库操作的原子性、一致性、隔离性、持久性，规避多数据库操作出现部分成功、部分失败的数据不一致问题。主要分为两种实现方式：1、编程式事务：硬编码方式，手动开启、提交、回滚事务。通过TransactionTemplate或者底层PlatformTransactionManager实现，灵活性高但代码侵入性强，业务代码和事务代码耦合严重，实际项目中极少使用。2、声明式事务：基于AOP实现，无代码侵入，通过@Transactional注解、XML配置即可开启事务。核心是通过动态代理拦截方法，自动完成事务的开启、提交、回滚，是项目主流用法。2.@Transactional注解的生效条件是什么？哪些情况会失效？参考答案：生效核心条件：Spring容器生成的代理对象调用方法、方法为public修饰、当前类被Spring管理。常见失效场景：1、方法不是public修饰，private/protected/default方法事务不生效；2、类内部自调用（this调用本类带事务的方法），绕过了Spring代理，事务失效；3、数据库引擎不支持事务，比如MySQL的MyISAM引擎，必须使用InnoDB；4、异常类型不匹配：默认只捕获RuntimeException和Error，普通CheckedException不会触发回滚；5、方法内部手动try-catch捕获了异常，没有抛出，Spring无法感知异常，不会回滚；6、多线程场景下，事务无法跨线程传递，子线程操作不参与主线程事务。3.Spring事务的四大隔离级别、七种传播机制分别是什么？参考答案：四大隔离级别（解决并发事务问题）：1、DEFAULT：默认级别，跟随数据库隔离级别（MySQL默认可重复读）；2、READ_UNCOMMITTED：读未提交，能读取其他事务未提交数据，会出现脏读、不可重复读、幻读，基本不用；3、READ_COMMITTED：读已提交，只能读取已提交数据，解决脏读，存在不可重复读、幻读；Oracle默认级别；4、REPEATABLE_READ：可重复读，事务内多次读取数据一致，解决脏读、不可重复读，存在幻读；MySQLInnoDB默认级别；5、SERIALIZABLE：串行化，最高级别，事务串行执行，解决所有并发问题，性能极低，几乎不用。七种传播机制（解决事务嵌套问题）：1、REQUIRED（默认）：有事务就加入，无事务新建事务；2、SUPPORTS：有事务就加入，无事务以非事务方式运行；3、MANDATORY：必须在事务内运行，无事务直接报错；4、REQUIRES_NEW：新建独立事务，暂停当前已有事务，互不影响；5、NOT_SUPPORTED：始终以非事务方式运行，存在事务则挂起；6、NEVER：强制非事务环境，检测到事务直接报错；7、NESTED：嵌套事务，依赖父事务，父事务回滚则子事务必须回滚，子事务回滚不影响父事务。二、进阶核心类（中级高频）1.REQUIRED和NESTED的核心区别是什么？工作中怎么选择？参考答案：1、事务层级不同：REQUIRED是合并为同一个事务，NESTED是独立嵌套子事务，基于保存点实现；2、回滚规则不同：REQUIRED嵌套时，任意层级报错，整个事务全部回滚；NESTED子事务异常回滚，父事务可以继续执行、正常提交，父事务异常则所有子事务强制回滚；3、依赖不同：REQUIRED完全共用事务，无独立保存点；NESTED依赖父事务的数据库连接，有独立保存点。使用场景：通用业务用默认REQUIRED；需要局部失败不影响整体流程的嵌套场景，用NESTED。2.@Transactional默认只回滚运行时异常，如何实现所有异常都回滚？参考答案：默认配置下，Spring只会对RuntimeException、Error触发事务回滚，IOException等受检异常不会回滚。解决方案：手动指定回滚异常类型，通过rollbackFor属性配置。示例：@Transactional(rollbackFor=Exception.class)该配置可以捕获所有异常，只要方法抛出异常，就会触发事务回滚，适配绝大多数业务场景。3.事务中为什么不建议做远程调用、文件操作、缓存操作？参考答案：1、事务超时问题：数据库事务会占用连接，远程调用、IO操作耗时不可控，容易导致事务超时、数据库连接耗尽，引发接口阻塞；2、数据一致性问题：缓存、文件、远程服务不受数据库事务管控，事务回滚后，这些外部操作无法同步回滚，出现数据不一致；3、性能问题：长事务会锁定数据库资源，影响数据库并发能力，导致整体接口吞吐量下降。最佳实践：数据库CRUD放在事务内，非DB操作放在事务外。三、实战踩坑类（面试重点）1.说说你遇到过的Spring事务失效的经典案例及解决办法参考答案：案例1：本类自调用导致事务失效场景：A类的a方法（无事务）调用本类b方法（加了@Transactional），b方法事务不生效。原因：this调用是原生对象调用，没有经过SpringAOP代理，事务拦截逻辑不会执行。解决：通过Spring上下文获取当前类的代理对象调用，或者拆分方法到不同类中。案例2：try-catch捕获异常导致不回滚场景：事务方法内部try-catch捕获所有异常，没有上抛，数据库数据正常提交。原因：Spring通过捕获方法抛出的异常判断是否回滚，内部吞掉异常，框架无法感知。解决：catch异常后手动抛出新异常，或者手动调用事务回滚工具类。案例3：非public方法事务失效场景：private方法添加@Transactional，事务无效。原因：SpringAOP动态代理无法拦截非public方法。解决：统一将事务方法定义为public。2.大事务问题怎么解决？如何优化长事务？参考答案：长事务、大事务会造成数据库锁等待、连接超时、死锁、并发性能下降，是线上常见性能问题，优化方案如下：1、拆分事务：将长事务拆分为多个小事务，只将必须原子性的DB操作放入事务，剥离非数据库操作；2、缩小事务范围：事务方法尽量精简，只保留核心CRUD，移除循环、远程调用、复杂计算逻辑；3、调整传播机制：非核心嵌套操作使用REQUIRES_NEW独立事务，避免拖累主事务；4、关闭不必要的事务查询：事务内只做写操作，查询操作放在事务外；5、合理设置事务超时时间，避免无效占用连接。3.多线程下Spring事务会出现什么问题？怎么解决？参考答案：问题：Spring事务基于ThreadLocal存储事务上下文，事务和当前线程绑定，子线程无法继承主线程事务，多线程批量操作无法保证原子性，主线程回滚，子线程数据库操作不会回滚。解决方案：1、简单场景：取消多线程，同步执行，保证事务统一；2、复杂批量场景：拆分批次，单批次单事务，做好失败重试、数据补偿；3、分布式场景：使用分布式事务方案（Seata等），保证跨线程、跨服务数据一致。四、原理源码类（高阶加分）1.Spring声明式事务的底层原理是什么？参考答案：核心基于SpringAOP动态代理实现，整体流程：1、容器启动时，Spring扫描带有@Transactional注解的类和方法，生成对应的代理对象；2、调用事务方法时，进入AOP拦截器TransactionInterceptor；3、拦截器先获取事务属性（隔离级别、传播机制、回滚规则）；4、根据传播机制判断是否新建事务、加入已有事务或挂起事务；5、执行目标业务方法；6、方法正常执行，自动提交事务；方法抛出指定异常，自动回滚事务；7、释放数据库连接、清除ThreadLocal事务上下文。2.Spring事务和数据库事务的关系？参考答案：Spring事务是框架层的事务管控封装，本质是对底层JDBC事务的增强，不替代数据库事务。1、底层依赖：Spring事务最终还是调用JDBC的commit、rollback方法，依赖数据库InnoDB引擎的事务、锁机制；2、能力增强：Spring提供了事务传播、隔离级别统一配置、声明式管控、嵌套事务等JDBC不具备的能力；3、管控范围：Spring负责事务的调度、拦截、回滚规则，数据库负责真正的事务执行、数据落地。3