事务的隔离特性与理解

转自：https://blog.csdn.net/nbskycity/article/details/106134899

事务的隔离在Spring注解中使用@Transactional(isolation = Isolation.REPEATABLE_READ)来配置。

事务的隔离类型

1. REPEATABLE_READ Mysql默认

可重复读,。如果两个事务同时执行，在提交第一个事务之前，第二个事务不能更改现有记录，但是可以添加新记录。提交第二个事务后，新添加的记录将反映在仍未提交的第一个事务中。

2. READ_COMMITTED

读已提交。如果两个事务同时执行，在提交第一个事务之前，可以更改现有记录，也可以通过第二个事务更改新记录。 提交第二个事务后，新添加的记录和更新的记录也会反映在仍未提交的第一个事务中。第二个事务未提交时，第一个事务无法读取到新添加和更新的记录。

3. READ_UNCOMMITTED

读未提交。如果两个事务正在同时执行，在提交第一个事务之前，可以更改现有记录，也可以通过第二个事务更改新记录。即使未提交第二个事务，新添加的以及更新的记录也会反映在仍未提交的第一个事务中。

4. SERIALIZABLE

序列化。如果两个事务同时执行，则好像是串行执行事务，即仅第一个事务被提交，然后第二个事务被执行。这是完全隔离。因此，正在运行的事务永远不会受到其他事务的影响。但是，这可能会导致问题，因为性能会降低，并且可能发生死锁。

事务隔离级别示例中理解

现在有以下场景：智能电表上报读数，如果读数与上次读数差额较大，则处理业务逻辑与预警通知。

这种情况我们一般会使用同步来处理读数计算，如下：

 1     synchronized (Object.class) {
 2         //查询上一次读数
 3         Double lastReading = dao.selectLastReading();
 4         Double thisUseData = lastReading - thisReading;
 5         if(thisUseData <= 0) {
 6             return ;
 7         }
 8         //记录本次读数
 9         dao.save();
10     }

这个时候我们的方法会加上事务处理；假定电表上报读数会同一时间上报多条；业务逻辑用时会较长。

这个时候就会出现第二次上报读数时，查询到的上一次读数一直都是最开始的读数，并不是第一次上报的读数。

这是因为默认的事务隔离级别为REPEATABLE_READ，第一次的事务还未提交，所以第二次上报处理的时候不能获取到第一次的读数。

我们可以修改事务隔离级别为READ_UNCOMMITTED来解决。第二次处理逻辑可以读到第一次未提交的数据。但是这样可能会造成脏读，当第一次处理回滚，第二次处理计算的起始值就会不对。

事务隔离级别性质

• 脏读-假设有两个事务-事务A和事务B同时运行。如果事务A修改了一条记录但没有提交。事务B读取该记录，但是事务A再次回滚该记录的更改并提交。因此，事务B的值有误。
• 不可重复读取-假设两个事务-事务A和事务B同时运行。如果事务A读取某些记录。事务B在提交事务A之前先修改这些记录。因此，如果事务A再次读取这些记录，它们将是不同的。因此，相同的select语句会导致不同的现有记录。
• 幻读-假设有两个事务-事务A和事务B同时运行。如果事务A读取某些记录。事务B在提交事务A之前添加了更多此类记录。因此，如果事务A再次读取，则记录将比前一个select语句更多。因此，相同的select语句会导致显示不同的数字记录，因为也会添加新记录。