企业官网建设流程全解析

Spring 只读事务面试详解

只读事务是@Transactional的一个属性，看起来简单，但面试中能问出很多深度问题。很多人只知道readOnly = true能优化查询，但说不清楚它到底优化了什么、底层怎么实现的、什么时候会失效。下面从面试角度把这个问题讲透。

一、基础概念

什么是只读事务？

@Transactional(readOnly = true)表示这个事务只执行读操作，不会修改数据。它是@Transactional的一个属性，默认值是false。

@Transactional(readOnly=true)publicList<User>findAll(){returnuserMapper.selectAll();}

为什么需要只读事务？

• 提示数据库和框架，这个事务不会写数据，可以做针对性优化。
• 防止误操作，在只读事务中执行写操作可能报错。
• 减少不必要的锁和日志开销，提升查询性能。

二、面试常问：只读事务到底优化了什么？

这是最核心的问题。很多人答“提升性能”，但说不清具体优化点。

1. MySQL InnoDB 层面的优化

在 MySQL InnoDB 中，只读事务会：

• 不分配事务 ID（TRX_ID）：普通事务在第一次写操作时会分配一个递增的事务 ID，只读事务不需要，减少了全局事务 ID 分配的开销。
• 减少 undo log 的维护：只读事务不需要回滚，不需要记录 undo log，减少了日志写入。
• 使用一致性读（Consistent Read）：只读事务通过 MVCC 快照读，不加锁，不阻塞其他事务。

2. JDBC 驱动层面

Connection.setReadOnly(true)会传递给数据库驱动。不同数据库驱动有不同处理：

• MySQL：驱动会发送SET SESSION TRANSACTION READ ONLY，将当前会话标记为只读。
• Oracle：设置只读事务后，Oracle 会使用更高效的读一致性机制。
• PostgreSQL：设置为只读事务后，数据库会拒绝写操作。

3. Spring 层面

Spring 把readOnly传递给TransactionDefinition，事务管理器根据这个标记决定是否调用Connection.setReadOnly(true)。在DataSourceTransactionManager中：

// AbstractPlatformTransactionManager（简化）if(definition.isReadOnly()){con.setReadOnly(true);}

4. Hibernate/JPA 层面

在 JPA 中，只读事务会：

• 跳过脏检查（Dirty Checking）：Hibernate 不需要在事务提交时对比实体快照，减少内存和 CPU 开销。
• 不维护持久化上下文的一级缓存快照。
• 设置FlushMode.MANUAL，不自动 flush。

这一点在 JPA 场景下优化效果明显，但在 MyBatis 中不存在脏检查，优化主要体现在数据库层面。

三、面试常问：只读事务能阻止写操作吗？

答案：不一定。

readOnly = true是一种提示，不是强制约束。是否能阻止写操作取决于数据库实现：

所以不能依赖只读事务来保证安全。如果需要严格禁止写操作，应该在代码层面做校验，或使用数据库账号权限控制。

面试追问：那为什么还要用只读事务？

因为：

• 大多数数据库会阻止，能起到防护作用。
• 提示数据库做优化，减少开销。
• 代码可读性更好，明确表达这个方法只读。

四、面试常问：只读事务的传播行为影响

只读事务的传播行为有一个特殊规则：

如果当前已有事务，只读标记不会覆盖当前事务的读写属性。

@Transactional(readOnly=false)publicvoidouter(){// 外层事务是读写事务innerService.query();// 内层声明 readOnly = true}@Transactional(readOnly=true)publicvoidquery(){// 虽然是 REQUIRED，加入外层事务// 但外层事务是读写的，内层不会强制变成只读}

原因：REQUIRED传播行为下，内层方法加入外层事务，事务属性由外层决定。内层的readOnly = true只在新建事务时生效。

如果内层用REQUIRES_NEW，会新建独立事务，此时readOnly = true会生效。

@Transactional(propagation=Propagation.REQUIRES_NEW,readOnly=true)publicvoidquery(){// 新建独立只读事务}

五、面试常问：只读事务与查询性能

问：只读事务能让查询变快吗？

答：能，但有前提。

• 在 MySQL InnoDB 中：只读事务减少了事务 ID 分配和 undo log 维护，对高频查询有提升，但提升幅度有限。
• 在 JPA/Hibernate 中：跳过脏检查，优化明显，尤其查询大量实体时。
• 在 MyBatis 中：没有脏检查，优化主要来自数据库层面，效果相对小。
• 如果查询本身没有写操作：不加只读事务，性能差异不大。

真正的性能提升来自：

• 数据库层面的读一致性优化。
• 减少锁竞争（只读事务不加锁）。
• 框架层面跳过不必要的检查。

不要指望只读事务能带来数量级的性能提升，它更多是一种规范和安全保障。

六、面试常问：只读事务能用在哪些方法上

典型场景：

// 推荐：多个查询需要读一致性@Transactional(readOnly=true)publicOrderDetailgetOrderDetail(LongorderId){Orderorder=orderDao.findById(orderId);List<OrderItem>items=orderItemDao.findByOrderId(orderId);Useruser=userDao.findById(order.getUserId());returnnewOrderDetail(order,items,user);}

这个场景中，三个查询需要在同一个一致性快照下执行，只读事务保证了读一致性。

七、面试常问：只读事务的坑

1. 内部调用失效

@ServicepublicclassUserService{publicvoiddoSomething(){this.query();// ❌ 内部调用，只读事务不生效}@Transactional(readOnly=true)publicList<User>query(){returnuserMapper.selectAll();}}

内部调用不经过代理，@Transactional不生效。

2. 只读事务中做写操作

@Transactional(readOnly=true)publicvoidupdateUser(Useruser){userDao.update(user);// ❌ MySQL 会报错}

3. 只读事务与延迟加载

在 JPA 中，只读事务中访问懒加载关联可能报错，因为只读事务的 FlushMode 是 MANUAL。需要提前初始化关联，或关闭懒加载。

4. 只读事务不能解决脏读

只读事务保证的是“这个事务不写”，不保证“读到最新数据”。隔离级别才决定读的可见性。只读事务 + 低隔离级别，依然可能读到旧数据。

5. 嵌套事务中只读失效

@Transactionalpublicvoidouter(){inner.query();// REQUIRED 加入外层事务，只读失效}@Transactional(readOnly=true)publicvoidquery(){}

外层是读写事务，内层REQUIRED加入后，只读标记被忽略。

八、面试实战：完整回答模板

面试官：说一下你对只读事务的理解。

回答框架：

1. 定义：readOnly = true是@Transactional的属性，表示事务中只执行读操作。
2. 优化点：
   • 数据库层面：不分配事务 ID、不维护 undo log、使用一致性读。
   • 框架层面：JPA 跳过脏检查，MyBatis 优化较小。
   • Spring 层面：调用Connection.setReadOnly(true)。
3. 限制：
   • 不是强制约束，是否阻止写操作取决于数据库。
   • REQUIRED传播行为下，内层只读不覆盖外层读写。
   • 内部调用失效。
4. 适用场景：多个查询需要读一致性时使用，单个查询收益有限。
5. 注意事项：不要依赖它做安全控制，不要在只读事务中写数据。

九、总结

只读事务是 Spring 事务属性中被低估的一个。面试中能答出“优化了什么”和“传播行为的影响”，就能体现你对事务的深入理解。记住核心：只读事务是提示，不是强制；优化有限，但规范和安全价值明确。