面试官常问：事务隔离级别中的可重复读能防幻读吗?

每次谈到数据库的事务隔离级别，大家一定会看到这张表。

经常看到RR（可重复读）级别是可以重复读的，但是无法解决幻读，只有可串行化(Serializable)才能解决幻读，这个说法是否正确呢?

假设我们的数据库中有如下结构和数据的Users表，下文中我们将对这张表进行操作

什么是幻读

在说幻读之前，我们要先来了解脏读和不可重复读。

脏读

当一个事务读取到另外一个事务修改但未提交的数据时，就可能发生脏读。

在我们的例子中，事务2修改了一行，但是没有提交，事务1读了这个没有提交的数据。

现在如果事务2回滚了刚才的修改或者做了另外的修改的话，事务1中查到的数据就是不正确的了，所以这条数据就是脏读。

不可重复读

“不可重复读”现象发生在当执行SELECT 操作时没有获得读锁或者SELECT操作执行完后马上释放了读锁；另外一个事务对数据进行了更新，读到了不同的结果。

在这个例子中，事务2提交成功，因此他对id为1的行的修改就对其他事务可见了。导致了事务1在此前读的class_id=1，第二次读的class_id=2，两次结果不一致，这就是不可重复读。

幻读

“幻读”又叫"幻象读"：当事务1两次执行''SELECT ... WHERE''检索一定范围内数据的操作中间，事务2在这个表中创建了(如[[INSERT]])了一行新数据，这条新数据正好满足事务1的“WHERE”子句。

如图事务1执行了两遍同样的查询语句，第二遍比第一遍多出了一条数据，这就是幻读。

三者到底什么区别

脏读：指读到了其他事务未提交的数据。

不可重复读：读到了其他事务已提交的数据(update)。

不可重复读与幻读都是读到其他事务已提交的数据，但是它们针对点不同。

不可重复读：update。

幻读：delete，insert。

MySQL中的四种事务隔离级别

未提交读

未提交读（READ UNCOMMITTED）是最低的隔离级别，在这种隔离级别下，如果一个事务已经开始写数据，则另外一个事务则不允许同时进行写操作，但允许其他事务读此行数据。

把脏读的图拿来分析分析，因为事务2更新id=1的数据后，仍然允许事务1读取该条数据,所以事务1第二次执行查询，读到了事务2更新的结果，产生了脏读。

已提交读

由于MySQL的InnoDB默认是使用的RR（可重复读）级别，所以我们先要将该session开启成RC级别，并且设置binlog的模式

SET session transaction isolation level read committed;
SET SESSION binlog_format = 'ROW';（或者是MIXED）

在已提交读（READ COMMITTED）级别中，读取数据的事务允许其他事务继续访问该行数据，但是未提交的写事务将会禁止其他事务访问该行，会对该写锁一直保持直到到事务提交。

同样，我们来分析脏读，事务2更新id=1的数据后，在提交前，会对该对象写锁，所以事务1读取id=1的数据时，会一直等待事务2结束，处于阻塞状态，避免了产生脏读。

同样，来分析不可重复读，事务1读取id=1的数据后并没有锁住该数据，所以事务2能对这条数据进行更新，事务2对更新并提交后，该数据立即生效，所以事务1再次执行同样的查询，查询到的结果便与第一次查到的不同，所以已提交读防不了不可重复读。

可重复读

在可重复读（REPEATABLE READS）是介于已提交读和可串行化之间的一种隔离级别。

它是InnoDb的默认隔离级别。

可串行化

可串行化（Serializable ）是高的隔离级别，它求在选定对象上的读锁和写锁保持直到事务结束后才能释放，所以能防住上诉所有问题，但因为是串行化的，所以效率较低。

可重复读（Repeatable read）能防住幻读吗?

在讲可重复读之前，我们先在mysql的InnoDB下做下面的实验。

可以看到，事务A既没有读到事务B更新的数据，也没有读到事务C添加的数据，所以在这个场景下，它既防住了不可重复读，也防住了幻读。

悲观锁与乐观锁

我们前面说的在对象上加锁，是一种悲观锁机制。

有些文章说，可重复读的隔离级别防得了幻读，是认为可重复读会对读的行加锁，导致其他事务修改不了这条数据，直到事务结束。

但是这种方案只能锁住数据行，如果有新的数据进来，是阻止不了的，所以会产生幻读。

可是MySQL、ORACLE、PostgreSQL等已经是非常成熟的数据库了，怎么会单纯地采用这种如此影响性能的方案呢?

悲观锁

正如其名，它指的是对数据被外界（包括本系统当前的其他事务，以及来自外部系统的事务处理）修改持保守态度，因此，在整个数据处理过程中，将数据处于锁定状态。

读取数据时给加锁，其它事务无法修改这些数据。修改删除数据时也要加锁，其它事务无法读取这些数据。

乐观锁

相对悲观锁而言，乐观锁机制采取了更加宽松的加锁机制。悲观锁大多数情况下依靠数据库的锁机制实现，以保证操作最大程度的独占性。但随之而来的就是数据库性能的大量开销，特别是对长事务而言，这样的开销往往无法承受。而乐观锁机制在一定程度上解决了这个问题。乐观锁，大多是基于数据版本（ Version ）记录机制实现。

何谓数据版本？即为数据增加一个版本标识，在基于数据库表的版本解决方案中，一般是通过为数据库表增加一个 “version” 字段来实现。读取出数据时，将此版本号一同读出，之后更新时，对此版本号加一。此时，将提交数据的版本数据与数据库表对应记录的当前版本信息进行比对，如果提交的数据版本号大于数据库表当前版本号，则予以更新，否则认为是过期数据。

MySQL、ORACLE、PostgreSQL等都是使用了以乐观锁为理论基础的MVCC（多版本并发控制）来避免不可重复读和幻读，MVCC的实现没有固定的规范，每个数据库都会有不同的实现方式，这里讨论的是InnoDB的MVCC。

MVCC(多版本并发控制)

在InnoDB中，会在每行数据后添加两个额外的隐藏的值来实现MVCC，这两个值一个记录这行数据何时被创建，另外一个记录这行数据何时过期（或者被删除）。

在实际操作中，存储的并不是时间，而是事务的版本号，每开启一个新事务，事务的版本号就会递增。在可重读Repeatable reads事务隔离级别下：

• SELECT时，读取创建版本号<=当前事务版本号，删除版本号为空或>当前事务版本号。
• INSERT时，保存当前事务版本号为行的创建版本号
• DELETE时，保存当前事务版本号为行的删除版本号
• UPDATE时，插入一条新纪录，保存当前事务版本号为行创建版本号，同时保存当前事务版本号到原来删除的行

通过MVCC，虽然每行记录都要额外的存储空间来记录version，需要更多的行检查工作以及一些额外的维护工作，但可以减少锁的使用，大多读操作都不用加锁，读取数据操作简单，性能好。

细心的同学应该也看到了，通过MVCC读取出来的数据其实是历史数据，而不是最新数据。

这在一些对于数据时效特别敏感的业务中，很可能出问题，这也是MVCC的短板之处，有办法解决吗？当然有。

MVCC这种读取历史数据的方式称为快照读(snapshot read)，而读取数据库当前版本数据的方式，叫当前读(current read)。

快照读

我们平时只用使用select就是快照读，这样可以减少加锁所带来的开销。

select * from table ....

当前读

对于会对数据修改的操作(update、insert、delete)都是采用当前读的模式。在执行这几个操作时会读取最新的记录，即使是别的事务提交的数据也可以查询到。

假设要update一条记录，但是在另一个事务中已经delete掉这条数据并且commit了，如果update就会产生冲突，所以在update的时候需要知道最新的数据。读取的是最新的数据，需要加锁。

以下第一个语句需要加共享锁，其它都需要加排它锁。

select * from table where ? lock in share mode; 
select * from table where ? for update; 
insert; 
update; 
delete;

我们再利用当前读来做试验。

可以看到在读提交的隔离级别中，事务1修改了所有class_id=1的数据，当事务2 insert后，事务A莫名奇妙地多了一行class_id=1的数据，而且没有被之前的update所修改，产生了读提交下的的幻读。

而在可重复度的隔离级别下，情况就完全不同了。

事务1在update后，对该数据加锁，事务B无法插入新的数据，这样事务A在update前后数据保持一致，避免了幻读，可以明确的是，update锁的肯定不只是已查询到的几条数据，因为这样无法阻止insert，有同学会说，那就是锁住了整张表呗。

还是那句话，Mysql已经是个成熟的数据库了，怎么会采用如此低效的方法呢？其实这里的锁，是通过next-key锁实现的。

Next-Key锁（间隙锁）

在Users这张表里面，class_id是个非聚簇索引，数据库会通过B+树维护一个非聚簇索引与主键的关系，简单来说，我们先通过class_id=1找到这个索引所对应所有节点，这些节点存储着对应数据的主键信息，即id=1，我们再通过主键id=1找到我们要的数据，这个过程称为回表。

假设我们上面用到的User表需要对Name建立非聚簇索引，是怎么实现的呢？我们看下图：

B+树的特点是所有数据都存储在叶子节点上，以非聚簇索引的秦寿生为例，在秦寿生的右叶子节点存储着所有秦寿生对应的Id，即图中的34。

在我们对这条数据做了当前读后，就会对这条数据加行锁，对于行锁很好理解，能够防止其他事务对其进行update或delete，但为什么要加GAP锁呢?

还是那句话，B+树的所有数据存储在叶子节点上，当有一个新的叫秦寿生的数据进来，一定是排在在这条id=34的数据前面或者后面的，我们如果对前后这个范围进行加锁了，那当然新的秦寿生就插不进来了。

那如果有一个新的范统要插进行呢？因为范统的前后并没有被锁住，是能成功插入的，这样就极大地提高了数据库的并发能力。

马失前蹄

上文中说了可重复读能防不可重复读，还能防幻读，它能防住所有的幻读吗？当然不是，也有马失前蹄的时候。

比如如下的例子：

(1) a事务先select，b事务insert确实会加一个gap锁，但是如果b事务commit，这个gap锁就会释放（释放后a事务可以随意操作)。

(2) a事务再select出来的结果在MVCC下还和第一次select一样。

(3) 接着a事务不加条件地update，这个update会作用在所有行上（包括b事务新加的）。

(4) a事务再次select就会出现b事务中的新行，并且这个新行已经被update修改了。

Mysql官方给出的幻读解释是：只要在一个事务中，第二次select多出了row就算幻读，所以这个场景下，算出现幻读了。

面试需要掌握那些技能？

1. Java基础知识：包括面向对象编程、集合框架、多线程编程、JVM、测试和调试技术等。

2. 熟悉Spring框架：包括Spring MVC、Spring Boot、Spring Cloud等。

3. 掌握常见的数据库操作技术：如SQL语句、关系型数据库和非关系型数据库等。

4. 熟练使用版本控制工具：如Git等。

5. 对Web开发有一定的了解，熟悉前端相关技术：如HTML、CSS、JavaScript等。

6. 能够写高效的算法，并对数据结构有一定的了解。

7. 有良好的代码习惯，能够编写易于维护和扩展的代码，并理解单元测试和集成测试等概念。

8. 在面试过程中，还需要表达清晰、思路清晰明了、能够准确地回答面试官提出的问题，此外，自信、积极和礼貌也是很重要的。

---

大厂面试官常问的技术核心知识点

1. Java基础知识：Java语言的基本知识，包括数据类型、继承、多态、接口等。

2. 面向对象编程：对面向对象编程原则和设计模式的理解，如单例、工厂、观察者、策略等。

3. 数据库知识：对关系型数据库和非关系型数据库操作的熟悉程度，掌握SQL语言，了解事务管理机制，并清楚地描述ORM框架的使用场景及实际操作。

4. Web开发：Web开发相关技术，例如Servlet、JSP、Spring MVC、JSON、RESTful API等。熟悉HTTP/HTTPS协议以及网络通信机制。

5. 常用框架：Spring、Hibernate、MyBatis等框架，尤其是Spring框架，深入理解Spring IOC，AOP等核心原理，知道如何配置基础设施组件，如事务管理、缓存等基础组件。

6. 分布式系统架构：分布式系统相关技术，如Dubbo、Zookeeper等，对微服务架构模式有一定的了解，熟悉分布式锁、分布式缓存、分布式数据存储等高可用性方案。

7. 性能排查：了解性能优化的方法，包括代码和SQL调优等，并且熟悉性能监测和分析工具，例如掌握JVM内存结构及堆栈排查技术。

8. 算法和数据结构：有基本的算法和数据结构知识，例如排序、查找、哈希表等。

---

我最近整理了一些小伙伴们发给我的面试题以及我的一些最新的面试等学习资料，有需要的小伙伴可以找我领取下。或者点击 → 《最新Java后端全套VIP面试学习资源》直接获取以下Java后端架构VIP进阶学习面试资料。

资料里面包含了：Java基础、MySQL、jvm、分布式、性能优化、spring 、spring boot、spring cloud、 MyBatis、Netty源码分析、算法、乙级高并发、Redis、dubbo、Tomcat、集合框架、锁、MQ、百万简历模板等等学习视频资料。

资料如图展示：（知识其中一部分）

同时也欢迎大家关注公众号【Java烂猪皮】，回复【666】，获取最新Java后端架构VIP学习资料以及视频学习教程，然后一起学习，一文在手，面试我有。

 看完三件事❤️

• 如果你觉得这篇内容对你还蛮有帮助，我想邀请你帮我三个小忙：
• 点赞，转发，有你们的 『点赞和评论』，才是我创造的动力。
• 关注作者公众号 『 java烂猪皮 』，不定期分享原创知识。
• 关注后回复【666】扫码即可获取学习资料包。
• 同时可以期待后续文章ing🚀。