Java Spring “事务” 面试清单（含超通俗生活案例与深度理解）

一、请解释 Spring 事务的本质是什么？

核心回答

Spring 事务本身不具备“创造事务能力”的属性，其本质是依托数据库的事务支持实现的。数据库提供了事务的开启、提交、回滚等底层核心操作能力，Spring 只是封装了一套统一的事务管理接口，让开发者无需直接操作数据库底层命令，就能更便捷地调用事务功能。简单来说，数据库是“事务的动力源”，Spring 是“事务的操作面板”——没有动力源，再精致的面板也无法驱动事务运行。

通俗易懂的例子

可以把这个过程类比成“社区生鲜配送”：

• 数据库就像“生鲜超市的仓储系统”——它有存放生鲜的冷链设备（对应事务的“持久化能力”）、记录库存的系统（对应事务的“数据一致性保障”），能真正实现“接收供货商的货（事务开启）、暂存待配送（事务执行）、不合格品退回（事务回滚）”；

• Spring 就像“社区配送平台”——它不直接管生鲜的仓储和退换，而是提供一个“订单管理界面”（统一事务接口），帮你记录“要订的生鲜种类、配送地址”（事务配置），再把订单需求传给超市仓储系统，最后通知你“生鲜已送达”或“订单已取消”（事务结果）。
如果超市没有仓储系统（数据库不支持事务），配送平台就算接了你的订单，也没法拿到生鲜给你配送——这就是 Spring 事务完全依赖数据库的核心逻辑。

二、Spring 支持哪两种事务管理方式？它们的区别和特点是什么？

核心回答

Spring 支持编程式事务管理和声明式事务管理两种方式，核心区别在于“是否需要开发者手动编写事务控制逻辑”，两者的适用场景和操作复杂度差异极大。

1. 编程式事务管理

• 核心逻辑：通过 TransactionTemplate 工具类，在业务代码中显式编写事务的全流程控制——从“开启事务”“执行业务逻辑”到“判断结果并提交/回滚事务”，每一步都需要手动编码控制，相当于“全程自主操作事务”。

• 通俗易懂的例子：就像“自己在家做一顿火锅”——你得亲自去菜市场选火锅底料、牛羊肉卷、蔬菜（事务开启前的准备工作），回家后清洗食材、烧水煮底料（执行业务逻辑）；如果煮的时候发现底料过期了（业务出错），就得把所有食材倒掉，重新去买新的（事务回滚）；如果一切顺利（业务成功），就可以摆盘开吃（事务提交）。整个过程没有任何人协助，每一个环节的判断和操作都需要自己完成。

• 优点：事务控制的颗粒度极细，能精确到“代码块级别”——比如你可以只在“处理牛羊肉卷”这一步加“如果肉卷化冻变质就丢弃”的逻辑（仅对某段代码做事务控制），灵活性极高；

• 缺点：代码侵入性强，事务逻辑与业务逻辑高度混杂——就像煮火锅时，你既要关注“火候大小”（业务逻辑），又要盯着“食材新鲜度”（事务判断），代码会变得臃肿冗余，后续修改业务时，还得同步调整事务代码，维护成本高。

2. 声明式事务管理

• 核心逻辑：基于 AOP（面向切面编程）实现，无需编写任何事务控制代码，只需在方法或类上添加 @Transactional 注解（或通过配置文件声明规则），Spring 会自动在方法执行前织入“开启事务”逻辑，执行后根据结果织入“提交事务”或“回滚事务”逻辑，相当于“把事务管理交给 Spring 托管”。

• 通俗易懂的例子：就像“在火锅店点一份现成的火锅套餐”——你只需要告诉服务员“要一份微辣的双人火锅套餐”（编写业务逻辑：定义方法实现“吃火锅”的核心需求），至于“后厨如何准备食材、煮制火锅、发现食材问题后重新备菜”（事务控制逻辑），全由火锅店负责（Spring 自动处理）。你不用关注中间的任何流程，只需等服务员把煮好的火锅端上桌（获取业务结果）。

• 优点：代码简洁干净，事务逻辑与业务逻辑完全分离——你只需专注于“怎么吃火锅”（业务逻辑），不用管“食材出问题怎么办”（事务控制），后续修改业务时，无需调整事务相关配置，维护效率高；

• 缺点：事务控制的颗粒度较粗，仅能到“方法级别”——就像在火锅店点套餐，你只能选择“整份套餐”，没法要求“只上套餐里的牛羊肉卷，不上蔬菜”（无法精确到方法内的某几行代码）；如果需要对同一方法内的不同代码块做差异化事务控制，声明式事务无法满足需求。

三、请说明 Spring 定义的事务隔离级别有哪些？分别对应什么场景？

核心回答

Spring 在 TransactionDefinition 接口中定义了 5 种事务隔离级别，本质是对“数据库隔离级别”的封装，核心目的是解决“多事务并发执行时的数据混乱问题”（如脏读、不可重复读、幻读）。每种隔离级别对应不同的“数据可见性规则”，适用于不同的业务场景。

各隔离级别详解

1. ISOLATION_DEFAULT（默认隔离级别）

• 核心逻辑：不主动指定具体隔离级别，直接沿用底层数据库的默认隔离规则——比如 MySQL 数据库默认的隔离级别是“可重复读”，Oracle 数据库默认是“读已提交”，相当于“遵循数据库的原生习惯”。

• 通俗易懂的例子：就像你去朋友家做客，朋友家有“进门换拖鞋、吃饭前洗手”的默认家庭规则（数据库默认隔离级别），你不用额外询问“该怎么做”，直接跟着朋友的习惯行动即可，无需自己制定新规则。

• 适用场景：90%以上的日常业务场景，尤其是当你不确定“业务需要多高的隔离级别”时，选择默认值是最安全的方案——既能避免过度消耗数据库性能（无需额外开启高隔离级别的资源占用），又能覆盖大部分常规数据一致性需求（如普通订单创建、用户信息修改）。

2. ISOLATION_READ_UNCOMMITTED（读未提交）

• 核心逻辑：允许当前事务读取“其他事务尚未提交的数据”，会导致“脏读”（读取到无效的临时数据），是所有隔离级别中安全性最低的一种，但性能最高（无需等待其他事务提交）。

• 通俗易懂的例子：就像你去超市买水果，称重员正在给一筐苹果贴“促销价标签”（其他事务开启，数据未提交），标签还没贴完（未提交），你就看到了标签上的临时价格“5元/斤”（读取未提交数据），于是拿了几个苹果去结账；结果称重员发现标签贴错了（事务回滚），实际价格是“8元/斤”，你只能要么补差价，要么把苹果放回——这就是“脏读”，相当于读了个无效的临时数据，最终导致业务纠纷。

• 适用场景：几乎不用于正式业务系统，仅适合“对数据准确性要求极低、只需要快速获取粗略数据”的场景，比如统计“某分钟内网站的大致访问量”——就算读了未提交的访问记录（比如用户刷新页面的临时请求），最终统计结果有少量误差，也不影响业务决策。

3. ISOLATION_READ_COMMITTED（读已提交）

• 核心逻辑：仅允许当前事务读取“其他事务已经提交的数据”，能有效避免“脏读”，但可能出现“不可重复读”（同一事务内多次读取同一数据，结果不一致），是很多数据库的默认隔离级别，兼顾安全性和性能。

• 通俗易懂的例子：就像你在手机上查外卖订单状态——中午12点查时，订单显示“商家正在备餐”（读取已提交数据，此时商家的“备餐事务”已提交）；12点10分你在同一事务里再查，订单显示“骑手正在配送”（其他事务“商家完成备餐、派单给骑手”已提交）——两次读取的结果不一样，这就是“不可重复读”。但你读的都是“已确认的有效状态”（没有脏读），这种变化符合业务逻辑（订单状态本就该随流程更新）。

• 适用场景：适合“对数据实时性要求高、但能接受同一事务内数据动态变化”的场景，比如电商平台的“商品详情页价格”“外卖订单状态”“快递物流信息”——用户每次刷新页面，看到的都是最新的已确认数据，就算同一事务内数据变化，也能提升用户体验（用户需要实时了解最新状态）。

4. ISOLATION_REPEATABLE_READ（可重复读）

• 核心逻辑：确保同一事务内，多次读取同一数据的结果“完全一致”，能有效避免“不可重复读”，但可能出现“幻读”（同一事务内，读取同一条件的数据，行数不一致），是 MySQL 数据库的默认隔离级别，安全性比“读已提交”更高。

• 通俗易懂的例子：就像你在电商平台“抢购限量商品”——你开启事务（点击“抢购页面”），搜索“某品牌限量运动鞋（库存10双）”，显示库存10双（第一次读取）；此时其他用户买了2双（新事务提交，实际库存变成8双）；你在同一事务里再搜“某品牌限量运动鞋”，还是显示库存10双（可重复读，事务内数据保持一致）；当你点击“下单10双”时（同一事务内执行写操作），系统会提示“库存不足，仅剩8双”——这就是“幻读”，读的是“事务内的一致数据”，但实际数据已变化，导致写操作与读操作结果冲突。

• 适用场景：适合“对数据一致性要求高、需要同一事务内数据稳定不变”的场景，比如银行的“账户余额查询与转账”“财务系统的账单统计”——你查完账户余额准备转账时，就算期间有利息到账（其他事务提交），同一转账事务里看到的余额还是“查询时的金额”，避免因余额突然变化导致“转账金额超过实际余额”的问题；财务统计账单时，同一事务内多次统计同一时间段的收支，结果一致，确保账单准确。

5. ISOLATION_SERIALIZABLE（串行化）

• 核心逻辑：最高隔离级别，强制所有事务“按顺序串行执行”（不允许并发），能完全避免脏读、不可重复读、幻读，但性能极低（相当于“单线程处理事务”），仅在极端场景下使用。

• 通俗易懂的例子：就像你去政务大厅办理“社保转移”业务——政务窗口一次只能接待一个人（事务串行执行），你在办理时（事务开启），后面的人只能排队等待（其他事务阻塞）；你办完所有手续（事务提交）后，下一个人才能到窗口办理（下一个事务开始）。这种方式不会出现“两个人同时修改同一社保记录”（数据混乱），但所有人都要排队，办理效率极低（比如10个人办理，需要等前9个人全办完）。

• 适用场景：仅适合“数据绝对不能出错、并发量极低”的核心业务场景，比如财务系统的“年度结账”“银行的季度对账”“税务系统的个税汇算清缴”——这类业务一年或一季度只执行一次，就算耗时1小时甚至更久，也比出现数据错误（如对账金额不一致、个税计算错误）的风险更值得，此时性能不是重点，数据绝对准确才是核心。

四、什么是 Spring 事务的传播机制？它的实现原理和常见注意点是什么？

核心回答

Spring 事务的传播机制，指的是“多个事务方法相互调用时，Spring 如何决定这些方法的事务归属关系”——比如 A 方法有事务，调用了 B 方法，B 方法是“加入 A 方法的现有事务”，还是“自己新建一个独立事务”，或是“不使用事务”？这就是传播机制要解决的核心问题。其底层实现依赖 ThreadLocal（将事务信息存储在当前线程的本地变量中），如果被调用的方法在新线程中执行，传播机制会直接失效（新线程无法获取原线程的事务信息）。

通俗易懂的例子

可以把事务传播机制类比成“学校社团活动协作”：

• 每个“事务方法”就是一个“社团成员”，“事务”就是“社团活动项目”；

• 传播机制就是“成员加入项目的规则”——比如新成员是“加入已有的项目组”，还是“自己牵头新建项目组”，或是“不参与任何项目组”。

1. 最常用的传播属性：PROPAGATION_REQUIRED（默认）

• 规则：如果当前线程已有事务（已有项目组），则加入该事务；如果当前线程没有事务（没有项目组），则新建一个事务（新建项目组）。

• 例子：学校“科技节APP开发项目组”（A方法，已有事务）需要招人，新加入的“UI设计师”（B方法）会直接加入这个项目组，和其他成员一起开发APP（B加入A的事务）；如果学校还没有科技节项目组（A方法无事务），新招的“UI设计师”会牵头成立“科技节APP开发项目组”（B新建事务），再吸引其他成员加入。这是日常开发中最常用的传播属性，能确保相关方法在同一事务内执行，保证数据一致性（比如“创建订单”和“扣减库存”必须在同一事务，要么都成功，要么都失败）。

2. 常见的其他传播属性：PROPAGATION_REQUIRES_NEW

• 规则：无论当前线程是否有事务，都新建一个独立事务；如果当前线程已有事务，则将原有事务挂起（暂停执行），待新事务完成后，再恢复原有事务。

• 例子：学校“科技节APP开发项目组”（A方法，已有事务）正在推进，突然接到“紧急修复校园官网bug”的任务（B方法）——此时不会让B加入APP开发组（避免bug修复影响APP开发进度），而是让B单独成立“官网bug修复专项组”（B新建独立事务）；APP开发组的工作暂时暂停（A事务挂起），等B的bug修复完成（B事务提交），再继续APP开发（A事务恢复）。这种属性适合“需要独立事务、不影响原有事务”的场景，比如“订单支付失败后记录日志”——就算日志记录失败（B事务回滚），也不能影响“订单支付失败回滚”（A事务），两者必须独立。

3. 传播机制失效的典型场景：新线程调用

• 原因：ThreadLocal 的特性是“事务信息仅存储在当前线程”，新线程无法获取原线程的事务信息，导致传播规则无法生效。

• 例子：学校“科技节APP开发项目组”（A方法，主线程事务）需要“测试APP兼容性”（B方法），但测试成员需要“在家远程测试”（B方法在新线程执行）——此时B的测试工作（新线程）不在学校的“项目协作系统”里（无法获取主线程的事务信息），就算B测试出bug（B事务回滚），也不会影响APP开发组的进度（A事务）；APP开发组甚至不知道B的测试结果（传播机制失效），因为两者不在同一“协作环境”（线程）。这种场景在实际开发中很容易被忽略，比如用 new Thread() 或线程池调用事务方法，都会导致传播机制失效。

五、请简述声明式事务的实现原理？

核心回答

声明式事务的实现原理是 AOP动态代理 + 事务拦截器，整个过程分为两步：第一步是“Spring容器初始化Bean时，为有事务注解的Bean创建代理对象”（给Bean“配一个事务管家”）；第二步是“调用Bean方法时，代理对象触发事务拦截器，自动织入事务逻辑”（管家帮Bean处理事务的开启、提交/回滚）。简单来说，Spring给有 @Transactional 注解的Bean“包了一层事务处理壳”，这层壳会自动完成所有事务操作，Bean本身只需专注于业务逻辑。

通俗易懂的例子

可以把这个过程类比成“宠物医院的宠物托管服务”：

• 有事务注解的Bean（如 OrderService）就像“需要托管的宠物”——负责“完成自己的日常活动”（执行业务逻辑），但不懂“如何处理突发状况”（事务控制）；

• 代理对象就像“宠物管家”——是宠物的“全权代理”，负责处理宠物的“非日常事务”（事务逻辑）；

• @Transactional 注解就像“宠物主人和管家的托管协议”——明确约定“宠物生病要送医”“没按时吃饭要提醒”（事务规则，如回滚异常类型、隔离级别）。

第一步：Bean初始化时创建代理对象（管家确认托管需求）

Spring 容器初始化所有Bean时，会像“宠物医院登记宠物信息”一样，逐个检查Bean的方法：

1. 检查事务注解：判断Bean的方法是否有 @Transactional 注解（宠物主人是否提出“托管需求”）；

2. 创建代理对象：如果有注解，Spring 会为这个Bean创建一个“代理对象”（给宠物分配专属管家），代理对象会记录 @Transactional 的所有规则（比如“宠物生病要送指定医院”——对应事务的回滚异常类型，“每天要喂3次饭”——对应事务的隔离级别）；

3. 选择代理方式：默认情况下，如果Bean实现了接口（如 OrderService 实现 IOrderService），用JDK动态代理（管家按“有证宠物”流程管理）；如果Bean没实现接口，用Cglib动态代理（管家按“无证宠物”流程管理）——两种方式不同，但最终目的都是“给Bean配一个事务管家”。

第二步：方法执行时触发事务拦截器（管家处理托管事务）

当你调用Bean的方法时（宠物主人让宠物“吃饭”），实际调用的是“代理对象”（管家），代理对象会立即触发 TransactionInterceptor（事务拦截器，相当于管家的“事务处理手册”），按以下三步自动处理事务：

1. 方法执行前：开启事务：管家先确认“宠物的状态是否正常”（检查当前线程是否有事务），如果没有，就“开启托管服务”（开启事务）——比如确认宠物没生病，就准备好食物（事务资源），开始托管；

2. 方法执行中：调用原业务方法：管家让宠物“自己吃饭”（调用Bean的原业务方法）——此时Bean只需专注于“完成吃饭”（执行业务逻辑），不用管“食物够不够”“要不要洗碗”（事务逻辑）；

3. 方法执行后：提交/回滚事务：

◦ 如果宠物顺利吃完（方法无异常）：管家“清理餐具、记录托管日志”（提交事务）——确认事务执行成功，释放资源；

◦ 如果宠物吃饭时呛到了（方法抛出 @Transactional 约定的异常，如“宠物生病”）：管家“立即送宠物去医院、通知主人”（回滚事务）——撤销事务内的所有操作，恢复到事务开启前的状态；

◦ 如果宠物只是挑食（方法抛出非约定异常，如“不想吃狗粮”）：管家“不处理，只记录情况”（不回滚事务）——因为这种异常不在托管协议内，不算“需要紧急处理的事务问题”。

整个过程中，Bean（宠物）只需专注于“执行业务”（吃饭），所有事务逻辑（开启、提交/回滚）都由代理对象和事务拦截器（管家）自动完成——这就是声明式事务“无需手动写事务代码”的核心原理。

六、声明式事务在哪些场景下会失效？请举例说明。

核心回答

声明式事务失效的本质，是“Spring的事务拦截器没有触发”——要么是拦截器无法读取事务配置（如非public方法），要么是方法调用没有经过代理对象（如同一类内调用），最终导致事务逻辑无法织入方法执行流程，事务自然无法生效。以下是6种最常见的失效场景，每种场景都有明确的原因和贴近生活的例子。

1. @Transactional 注解用在非 public 修饰的方法上

• 失效原因：Spring AOP 在处理事务时，会通过 AbstractFallbackTransactionAttributeSource 类的 computeTransactionAttribute 方法检查方法修饰符——如果方法不是 public，会直接返回 null（不读取事务配置），事务拦截器无法触发，事务自然失效。

• 通俗易懂的例子：就像你去公司前台申请“使用会议室”——前台的规则是“仅允许正式员工（public方法）申请”，如果你是“实习生（private方法）”，就算你说“要订会议室开项目会”（加了 @Transactional），前台也会回复“没有权限申请”（不读取事务配置），最终你没法使用会议室（事务失效）。这种场景不会报错，只会“默默失效”，很容易在开发中被忽略。

• 注意：就算给 private、protected 或 default 修饰的方法加 @Transactional，Spring 也不会提示错误，但运行时事务完全不生效，需要特别注意方法的访问修饰符。

2. @Transactional 的 propagation（传播属性）配置错误

• 失效原因：传播属性决定了“方法是否需要事务支持”，如果配置了“不支持事务”或“禁止事务”的属性，就算加了注解，Spring 也不会创建事务，导致事务失效。

• 通俗易懂的例子：就像你去咖啡店买咖啡，告诉店员“要一杯热拿铁（加了 @Transactional）”，但同时补充“不要用杯子装（传播属性配置错误）”——店员就算做好了拿铁（业务逻辑执行），也没法给你（无法创建事务容器），最终你拿不到咖啡（事务失效）。常见的错误传播属性有3种：

◦ PROPAGATION_SUPPORTS：“有事务就加入，没事务就非事务运行”——比如你说“有杯子就用杯子装，没杯子就用手捧”，如果店里刚好没杯子（没事务），你只能用手捧（非事务运行），相当于事务没生效；

◦ PROPAGATION_NOT_SUPPORTED：“强制非事务运行，有事务就挂起”——比如你说“不管有没有杯子，都用手捧”，就算店里有杯子（有事务），店员也不会用（挂起事务），还是非事务运行；

◦ PROPAGATION_NEVER：“禁止事务，有事务就抛异常”——比如你说“绝对不用杯子，用杯子就不买了”，如果店员拿了杯子（有事务），你会直接转身离开（抛异常），事务自然无法执行。

• 注意：配置传播属性时，需根据业务场景选择，避免用上述3种属性（除非明确不需要事务），日常开发优先用默认的 PROPAGATION_REQUIRED。

3. @Transactional 的 rollbackFor（回滚异常类型）配置错误

• 失效原因：Spring 默认只对“RuntimeException（运行时异常）”和“Error（系统错误）”触发事务回滚，如果业务方法抛出的是“受检异常”（如 IOException、SQLException），且没在 rollbackFor 中配置，就算方法执行失败，事务也不会回滚，相当于“事务部分失效”（仅提交不回滚）。

• 通俗易懂的例子：就像公司的“请假审批规则”——公司默认只批“突发疾病请假（RuntimeException）”，如果你请的是“产假（自定义受检异常 MyMaternityLeaveException）”，且没在“审批规则（rollbackFor）”里添加“产假”，HR会说“不在审批范围内（不触发回滚）”，最终你的请假申请不会被批准（事务不回滚）。

• 例子细节：比如“订单支付”方法加了 @Transactional，但没配置 rollbackFor；方法中调用“第三方支付接口”时，抛出“支付超时异常（自定义受检异常 PaymentTimeoutException）”——Spring 会认为“这是正常业务异常，不是需要回滚的异常”，就算支付失败，也不会回滚“扣减库存”的操作，导致“库存扣了，钱没收到”的业务漏洞。

4. 同一类内的方法相互调用（无事务方法调用有事务方法）

• 失效原因：同一类内，A方法（无事务）调用B方法（有 @Transactional）时，会直接调用“Bean的原方法”，不经过代理对象——事务拦截器无法触发，事务配置无法读取，导致B方法的事务失效。

• 通俗易懂的例子：就像你在家做饭，让家人“帮忙拿酱油（B方法，有事务）”——你（A方法，无事务）在厨房，家人在客厅，你直接喊“拿瓶酱油过来”（同一类内调用），家人会直接从冰箱拿酱油给你（调用原方法），不会经过“外卖平台（代理对象）”；就算家人拿错了酱油（B方法事务出错），也没法通过外卖平台“重新送一瓶（事务回滚）”，因为没走代理流程（事务失效）。

• 例子细节：比如 OrderService 类里有 createOrder() 方法（无 @Transactional）和 deductStock() 方法（有 @Transactional）；createOrder() 方法中直接用 this.deductStock() 调用——这里的 this 是 OrderService 的原对象，不是 Spring 创建的代理对象，deductStock() 的事务配置无法被读取，就算扣库存失败，也不会回滚。

5. 方法内捕获异常后未重新抛出

• 失效原因：Spring 是通过“捕获方法抛出的异常”来判断是否回滚事务的——如果在方法内用 try-catch 捕获了异常，且没有重新抛出，Spring 会认为“方法执行成功”，不会触发事务回滚，导致事务“只提交不回滚”。

• 通俗易懂的例子：就像你点外卖，外卖员把餐送丢了（方法抛异常），但他没告诉平台（catch 后不抛异常），平台会显示“餐已送达（Spring 认为方法成功）”，不会给你重新送一份（事务不回滚）；只有外卖员告诉平台“餐丢了（重新抛异常）”，平台才会安排重送（事务回滚）。

• 例子细节：比如“转账”方法加了 @Transactional，方法内 try 块执行“扣减转账方余额”和“增加收款方余额”，catch 块捕获了“转账失败异常”，但只打印了日志（e.printStackTrace()），没重新抛出——Spring 没感知到异常，会认为“转账成功”，就算实际转账失败，也不会回滚“扣减余额”的操作，导致“转账方钱少了，收款方钱没多”的错误。

6. 事务方法所在的类未被 Spring 管理

• 失效原因：如果事务方法所在的类，没加 @Service、@Component 等注解，没被 Spring 扫描成 Bean——Spring 不会为其创建代理对象，@Transactional 注解就是“空注解”，事务自然无法生效。

• 通俗易懂的例子：就像你没在小区物业“登记入住信息（没被 Spring 管理）”，就算你跟物业说“帮我代收快递（加了 @Transactional）”，物业也不会帮你——因为物业系统里没有你的信息，没法给你建“代收档案（代理对象）”，最终快递没法代收（事务失效）。

• 例子细节：比如忘了给 OrderService 加 @Service 注解，在 Controller 里直接用 new OrderService() 创建对象，调用 orderService.createOrder() 方法——这个 orderService 是“手动 new 的对象”，不是 Spring 管理的 Bean，没有代理对象，@Transactional 完全不生效。