浅谈悲观锁、乐观锁

骑猪看日落 2023-10-11 17:12 46阅读 0赞

#### 文章目录 ####

*  1.为什么会产生悲观锁、乐观锁?
 *  2.脏读、幻读、不可重复读
 *   *  2.1 脏读
     *  2.2 幻读
     *  2.3 不可重复读
     *  2.4 数据库隔离级别
     *   *  读未提交（Read Uncommited）
         *  读已提交（Read Committed）
         *  可重复读（Repeatable Read）
         *  可串行化（Serializable）
 *  3.悲观锁(Pessimistic Lock)
 *   *  3.1 悲观锁的实现
 *  4.乐观锁(Optimistic Locking)
 *   *  4.1 乐观锁的实现
 *  5.具体实现
 *   *  5.1 悲观锁的实现
     *  5.2 乐观锁的实现
 *  6.理解 CAS 底层
 *  7.CAS 典型应用--atomic
 *   *  synchronized 加锁
     *  Atomic 原子类
 *  8.CAS 性能优化
 *  9.如何选择悲观锁还是乐观锁

## 1.为什么会产生悲观锁、乐观锁? ##

当程序中可能出现并发的情况时，就需要保证在并发情况下数据的准确性，以此确保当前用户和其他用户一起操作时，所得到的结果和他单独操作时的结果是一样的。这就叫做并发控制。并发控制的目的是保证一个用户的工作不会对另一个用户的工作产生不合理的影响。  
没有做好并发控制，就可能导致脏读、幻读和不可重复读等问题。  
常说的并发控制，一般都和数据库管理系统(DBMS)有关。在 DBMS 中并发控制的任务，是确保多个事务同时增删改查同一数据时，不破坏事务的隔离性、一致性和数据库的统一性。  
**实现并发控制的主要手段分为乐观并发控制和悲观并发控制两种。**  
无论是悲观锁还是乐观锁，都是开发者定义出来的概念，可以认为是一种思想。其实不仅仅是关系型数据库系统中有乐观锁和悲观锁的概念，像 hibernate、tair、memcache 等都有类似的概念。所以，不应该拿乐观锁、悲观锁和其他的数据库锁等进行对比。

*  乐观锁比较适用于读多写少的情况(**多读场景**)
 *  悲观锁比较适用于写多读少的情况(**多写场景**)。

![在这里插入图片描述][watermark_type_d3F5LXplbmhlaQ_shadow_50_text_Q1NETiBAWk5pbmVTdW4_size_16_color_FFFFFF_t_70_g_se_x_16_pic_center]

在讲解悲观锁与乐观锁之前，我们需要先对脏读，幻读以及不可重复读有一个简单的了解

## 2.脏读、幻读、不可重复读 ##

### 2.1 脏读 ###

A事务执行过程中，B事务读取了A事务的修改。但是由于某些原因，A事务可能没有完成提交，发生RollBack了操作，则B事务所读取的数据就会是不正确的。这个未提交数据就是脏读（Dirty Read）。脏读产生的流程如下：  
![在这里插入图片描述][watermark_type_d3F5LXplbmhlaQ_shadow_50_text_Q1NETiBAWk5pbmVTdW4_size_20_color_FFFFFF_t_70_g_se_x_16_pic_center]

### 2.2 幻读 ###

B事务读取了两次数据，在这两次的读取过程中A事务添加了数据，B事务的这两次读取出来的集合不一样。幻读产生的流程如下：  
![在这里插入图片描述][watermark_type_d3F5LXplbmhlaQ_shadow_50_text_Q1NETiBAWk5pbmVTdW4_size_20_color_FFFFFF_t_70_g_se_x_16_pic_center 1]

### 2.3 不可重复读 ###

B事务读取了两次数据，在这两次的读取过程中A事务修改了数据，B事务的这两次读取出来的数据不一样。B事务这种读取的结果，即为不可重复读（Nonrepeatable Read）。不可重复读的产生的流程如下：  
![在这里插入图片描述][watermark_type_d3F5LXplbmhlaQ_shadow_50_text_Q1NETiBAWk5pbmVTdW4_size_20_color_FFFFFF_t_70_g_se_x_16_pic_center 2]

我们可以看到不可重复读和幻读的概念很相像，但是两者有个本质上的不同就是不可重复读就是有数据的修改，再次读取时和原数据不同，而幻读是指读取的集合数量不一样，可能第一次获取12条数据，第二次在读的时候因为某些原因，删除了一条数据，导致最终读取到的就只有9条数据，就好像这条数据从未出现过一样。

### 2.4 数据库隔离级别 ###

#### 读未提交（Read Uncommited） ####

在该隔离级别，所有事务都可以看到其他未提交事务的执行结果。本隔离级别是最低的隔离级别，虽然拥有超高的并发处理能力及很低的系统开销，但很少用于实际应用。因为采用这种隔离级别只能防止第一类更新丢失问题，不能解决脏读，不可重复读及幻读问题。

#### 读已提交（Read Committed） ####

这是大多数数据库系统的默认隔离级别（但不是MySQL默认的）。它满足了隔离的简单定义：一个事务只能看见已经提交事务所做的改变。  
这种隔离级别可以防止脏读问题，但会出现不可重复读及幻读问题。

#### 可重复读（Repeatable Read） ####

这是MySQL的默认事务隔离级别，它确保同一事务的多个实例在并发读取数据时，会看到同样的数据行。这种隔离级别可以防止**除幻读**外的其他问题。

#### 可串行化（Serializable） ####

这是最高的隔离级别，它通过强制事务排序，使之不可能相互冲突，从而解决幻读、第二类更新丢失问题。在这个级别，可以解决上面提到的所有并发问题，但可能导致大量的超时现象和锁竞争，通常数据库不会用这个隔离级别，我们需要其他的机制来解决这些问题:乐观锁和悲观锁。  
![在这里插入图片描述][63a595e395104eab87e625c3ee965cc2.png_pic_center]  
首先说读未提交，它是性能最好，也可以说它是最野蛮的方式，因为它压根儿就不加锁，所以根本谈不上什么隔离效果，可以理解为没有隔离。

再来说串行化。串行化就相当于上面所说的，处理一个人请求的时候，别的人都等着。读的时候加共享锁，也就是其他事务可以并发读，但是不能写。写的时候加排它锁，其他事务不能并发写也不能并发读。

最后说读提交和可重复读。这两种隔离级别是比较复杂的，既要允许一定的并发，又想要兼顾的解决问题。MySQL默认事务隔离级别为可重复读(RR),oracle默认事务隔离级别为读已提交(RC),

数据库的事务隔离越严格，并发副作用越小，但付出的代价越大；因为事务隔离本质就是使事务在一定程度上处于串行状态，这本身就是和并发相矛盾的。

同时，不同的应用对读一致性和事务隔离级别是不一样的，比如许多应用对数据的一致性没那么个高要求，相反，对并发有一定要求。

## 3.悲观锁(Pessimistic Lock) ##

当要对数据库中的一条数据进行修改的时候，为了避免同时被其他人修改，最好的办法就是直接对该数据进行加锁以防止并发。  
这种借助数据库锁机制，在修改数据之前先锁定，再修改的方式被称之为悲观并发控制。

悲观锁，具有强烈的**独占**和**排他特性**。它指的是对数据被外界(包括本系统当前的其他事务，以及来自外部系统的事务处理)修改持保守态度。因此，在整个数据处理过程中，将数据处于锁定状态。

### 3.1 悲观锁的实现 ###

悲观锁的实现，往往依靠数据库提供的锁机制(也只有数据库层提供的锁机制才能真正保证数据访问的排他性，否则，即使在本系统中实现了加锁机制，也无法保证外部系统不会修改数据)。  
悲观锁的大致过程如下：  
![在这里插入图片描述][watermark_type_d3F5LXplbmhlaQ_shadow_50_text_Q1NETiBAWk5pbmVTdW4_size_20_color_FFFFFF_t_70_g_se_x_16_pic_center 3]

> 之所以叫做悲观锁，是因为这是一种对数据的修改持有悲观态度的并发控制方式。总是假设最坏的情况，每次读取数据的时候都默认其他线程会更改数据，因此需要进行加锁操作，当其他线程想要访问数据时，都需要阻塞挂起。悲观锁的实现：

常见的悲观锁实现：

*  传统的关系型数据库使用这种锁机制，比如行锁、表锁、读锁、写锁等，都是在操作之前先上锁。
 *  Java 里面的同步 synchronized 关键字的实现。

悲观锁主要分为共享锁和排他锁：

*  1.共享锁【shared locks】又称为读锁，简称 S 锁。顾名思义，共享锁就是多个事务对于同一数据可以共享一把锁，都能访问到数据，但是**只能读不能修改**。
 *  2.排他锁【exclusive locks】又称为写锁，简称 X 锁。顾名思义，排他锁就是不能与其他锁并存，如果一个事务获取了一个数据行的排他锁，其他事务就不能再获取该行的其他锁，包括共享锁和排他锁。获取排他锁的事务可以对数据行读取和修改。

> 悲观并发控制实际上是“**先取锁再访问**”的保守策略，为数据处理的安全提供了保证。但是在效率方面，处理加锁的机制会让数据库产生额外的开销，还有增加产生死锁的机会。另外还会降低并行性，一个事务如果锁定了某行数据，其他事务就必须等待该事务处理完才可以处理那行数据。

## 4.乐观锁(Optimistic Locking) ##

乐观锁是相对悲观锁而言的，乐观锁假设数据一般情况不会造成冲突，所以在数据进行提交更新的时候，才会正式对数据的冲突与否进行检测，如果冲突，则返回给用户异常信息，让用户决定如何去做。乐观锁适用于**读多写少**的场景，这样可以提高程序的吞吐量。  
![在这里插入图片描述][watermark_type_d3F5LXplbmhlaQ_shadow_50_text_Q1NETiBAWk5pbmVTdW4_size_20_color_FFFFFF_t_70_g_se_x_16_pic_center 4]

乐观锁采取了更加宽松的加锁机制。也是为了避免数据库幻读、业务处理时间过长等原因引起数据处理错误的一种机制，但乐观锁不会刻意使用数据库本身的锁机制，而是依据数据本身来保证数据的正确性。

### 4.1 乐观锁的实现 ###

*  CAS 实现：Java 中java.util.concurrent.atomic包下面的原子变量使用了乐观锁的一种 CAS 实现方式。
 *  版本号控制：一般是在数据表中加上一个数据版本号 version 字段，表示数据被修改的次数。当数据被修改时，version 值会 +1。当线程 A 要更新数据时，在读取数据的同时也会读取 version 值，在提交更新时，若刚才读取到的 version 值与当前数据库中的 version 值相等时才更新，否则重试更新操作，直到更新成功。

> 乐观并发控制相信事务之间的数据竞争(data race)的概率是比较小的，因此尽可能直接做下去，直到提交的时候才去锁定，所以不会产生任何锁和死锁。

## 5.具体实现 ##

### 5.1 悲观锁的实现 ###

悲观锁的实现，往往依靠数据库提供的锁机制。在数据库中，悲观锁的流程如下：

*  1.在对记录进行修改前，先尝试为该记录加上排他锁(exclusive locks)。
 *  2.如果加锁失败，说明该记录正在被修改，那么当前查询可能要等待或者抛出异常。具体响应方式由开发者根据实际需要决定。
 *  3.如果成功加锁，那么就可以对记录做修改，事务完成后就会解锁了。
 *  4.期间如果有其他对该记录做修改或加排他锁的操作，都会等待解锁或直接抛出异常。

具体我们以MySql Innodb 引擎举例，说明 SQL 中悲观锁的应用  
要使用悲观锁，必须关闭 MySQL 数据库的自动提交属性set autocommit=0。因为 MySQL 默认使用 autocommit 模式，也就是说，当执行一个更新操作后，MySQL 会立刻将结果进行提交。  
具体的实现即 通过 select … for update 来实现  
![在这里插入图片描述][49a46de90b5e441cadcca6b0b717aa51.png_pic_center]

[《select…for update会锁表还是锁行》][select_for update]

### 5.2 乐观锁的实现 ###

**乐观锁不需要借助数据库的锁机制**  
主要就是两个步骤：

*  冲突检测
 *  数据更新。

比较典型的就是 CAS (Compare and Swap)。  
CAS 即比较并交换。

> 是解决多线程并行情况下使用锁造成性能损耗的一种机制，CAS 操作包含三个操作数——内存位置(V)、预期原值(A)和新值(B)。如果内存位置的值(V)与预期原值(A)相匹配，那么处理器会自动将该位置值更新为新值(B)。否则，处理器不做任何操作。无论哪种情况，它都会在 CAS 指令之前返回该位置的值。CAS 有效地说明了“我认为位置(V)应该包含值(A)。如果包含该值，则将新值(B)放到这个位置；否则，不要更改该位置，只告诉我这个位置现在的值即可”。Java 中，sun.misc.Unsafe 类提供了硬件级别的原子操作来实现这个 CAS。java.util.concurrent包下大量的类都使用了这个 Unsafe.java 类的 CAS 操作。

当多个线程尝试使用 CAS 同时更新同一个变量时，只有其中一个线程能更新变量的值，而其它线程都失败，失败的线程并不会被挂起，而是被告知这次竞争中失败，并可以再次尝试。比如前面的扣减库存问题，我们就可以通过乐观锁实现  
![在这里插入图片描述][3d12a4eab3eb4b87acc787532ef6a35b.png_pic_center]

在更新之前，先查询一下库存表中当前库存数(quantity)，然后在做 update 的时候，以库存数作为一个修改条件。  
当提交更新的时候，判断数据库表对应记录的当前库存数与第一次取出来的库存数进行比对，如果数据库表当前库存数与第一次取出来的库存数相等，则予以更新，否则认为是过期数据。  
你感觉以上操作ok吗？  
其实上面的操作会遇到一个很常见的问题ABA:  
![在这里插入图片描述][watermark_type_d3F5LXplbmhlaQ_shadow_50_text_Q1NETiBAWk5pbmVTdW4_size_20_color_FFFFFF_t_70_g_se_x_16_pic_center 5]

*  线程一从数据库中取出库存数 3，这时候线程二也从数据库中取出库存数 3，并且线程二进行了一些操作变成了 2。
 *  然后线程二又将库存数变成 3，这时候线程一进行 CAS 操作发现数据库中仍然是 3，然后线程一操作成功。
 *  尽管线程一的 CAS 操作成功，但是不代表这个过程就是没有问题的。

**一个比较好的解决办法，就是通过一个单独的可以顺序递增的 version 字段。优化如下：**  
![在这里插入图片描述][watermark_type_d3F5LXplbmhlaQ_shadow_50_text_Q1NETiBAWk5pbmVTdW4_size_20_color_FFFFFF_t_70_g_se_x_16_pic_center 6]

乐观锁每次在执行数据修改操作时，都会带上一个版本号，一旦版本号和数据的版本号一致就可以执行修改操作并对版本号执行 +1 操作，否则就执行失败。因为每次操作的版本号都会随之增加，所以不会出现 ABA 问题。除了 version 以外，还可以使用时间戳，因为时间戳天然具有顺序递增性。  
但你感觉这样又ok了？  
你又错了!!!  
就是一旦遇上高并发的时候，就只有一个线程可以修改成功，那么就会存在大量的失败。对于像淘宝这样的电商网站，高并发是常有的事，总让用户感知到失败显然是不合理的。所以，还是要想办法减少乐观锁的粒度。一个比较好的建议，就是减小乐观锁力度，最大程度的提升吞吐率，提高并发能力！如下：  
![在这里插入图片描述][6b262e7f7beb46bf925410e5640a4470.png_pic_center]

以上 SQL 语句中，如果用户下单数为 1，则通过quantity - 1 > 0的方式进行乐观锁控制。在执行过程中，会在一次原子操作中查询一遍 quantity 的值，并将其扣减掉 1。

**高并发环境下锁粒度把控是一门重要的学问。选择一个好的锁，在保证数据安全的情况下，可以大大提升吞吐率，进而提升性能。**

## 6.理解 CAS 底层 ##

![在这里插入图片描述][watermark_type_d3F5LXplbmhlaQ_shadow_50_text_Q1NETiBAWk5pbmVTdW4_size_20_color_FFFFFF_t_70_g_se_x_16_pic_center 7]

假如说有 3 个线程并发的要修改一个 AtomicInteger 的值，底层机制如下：

*  首先，每个线程都会先获取当前的值，接着走一个原子的 CAS 操作。  
    原子的意思就是这个 CAS 操作一定是自己完整执行完的，不会被别人打断。
 *  然后 CAS 操作里，会比较一下，现在的值是不是刚才获取到的那个值。如果是，说明没人改过这个值，然后设置成累加 1 之后的一个值。
 *  同理，如果有人在执行 CAS 的时候，发现之前获取的值跟当前的值不一样，会导致 CAS 失败。失败之后，进入一个无限循环，再次获取值，接着执行 CAS 操作。

## 7.CAS 典型应用–atomic ##

java.util.concurrent.atomic包下的类大多是使用 CAS 操作来实现的，比如 AtomicInteger、AtomicBoolean、AtomicLong。  
一般在竞争不是特别激烈的时候，使用该包下的原子操作性能比使用 synchronized 关键字的方式高效的多(查看 getAndSet()，可知如果资源竞争十分激烈的话，这个 for 循环可能会持续很久都不能成功跳出。不过这种情况可能需要考虑降低资源竞争才是)。  
有一个很典型的应用就是计数应用

public class Increment {
        
        private int count = 0;
        public void add() {
        
            count++;
        }
    }

上面的代码我们需要面临什么的情况：  
在并发环境下对 count 进行自增运算是不安全的，为什么不安全以及如何解决这个问题呢？

在并发环境下，count 自增操作不安全？因为 count++ 不是原子操作，而是三个原子操作的组合：

*  读取内存中的 count 值赋值给局部变量 temp；
 *  执行 temp+1 操作；
 *  将 temp 赋值给 count。

所以如果两个线程同时执行 count++ 的话，不能保证线程一按顺序执行完上述三步后线程二才开始执行。

**并发环境下 count++ 不安全问题的解决方案**

### synchronized 加锁 ###

同一时间只有一个线程能加锁，其他线程需要等待锁，这样就不会出现 count 计数不准确的问题了：

public class Increment {
        
        private int count = 0;
        public synchronized void add() {
        
            count++;
        }
    }

你以为解决了线程安全就万事大吉啦，你不仅需要功能能够正常的完成还要保证能够正常的使用  
但是引入 synchronized 会造成多个线程排队的问题，相当于让各个线程串行化了，一个接一个的排队、加锁、处理数据、释放锁，下一个再进来。同一时间只有一个线程执行，这样的锁有点“重量级”了。  
这类似于悲观锁的实现，需要获取这个资源，就给它加锁，别的线程都无法访问该资源，直到操作完后释放对该资源的锁。虽然随着 Java 版本更新，也对 synchronized 做了很多优化，但是处理这种简单的累加操作，仍然显得“太重了”。

### Atomic 原子类 ###

对于 count++ 的操作，完全可以换一种做法，Java 并发包下面提供了一系列的 Atomic 原子类，比如说 AtomicInteger：

//import java.util.concurrent.atomic.AtomicInteger;
    public static void main(String[] args) {
        
        public static AtomicInteger count = new AtomicInteger(0);
        public static void increase() {
        
            count.incrementAndGet();
        }
    }

多个线程可以并发的执行 AtomicInteger 的 incrementAndGet()，意思就是把 count 的值累加 1，接着返回累加后最新的值。实际上，Atomic 原子类底层用的不是传统意义的锁机制，而是无锁化的 CAS 机制，通过 CAS 机制保证多线程修改一个数值的安全性。

## 8.CAS 性能优化 ##

大量的线程同时并发修改一个 AtomicInteger，可能有很多线程会不停的自旋，进入一个无限重复的循环中。这些线程不停地获取值，然后发起 CAS 操作，但是发现这个值被别人改过了，于是再次进入下一个循环，获取值，发起 CAS 操作又失败了，再次进入下一个循环。在大量线程高并发更新 AtomicInteger 的时候，这种问题可能会比较明显，导致大量线程空循环，自旋转，性能和效率都不是特别好。那么如何优化呢？  
Java8 有一个新的类，LongAdder，它就是尝试使用分段 CAS 以及自动分段迁移的方式来大幅度提升多线程高并发执行 CAS 操作的性能，这个类具体是如何优化性能的呢？如图：  
![在这里插入图片描述][watermark_type_d3F5LXplbmhlaQ_shadow_50_text_Q1NETiBAWk5pbmVTdW4_size_20_color_FFFFFF_t_70_g_se_x_16_pic_center 8]

LongAdder 核心思想就是**热点分离**，这一点和 ConcurrentHashMap 的设计思想相似。  
就是将 value 值分离成一个数组，当多线程访问时，通过 hash 算法映射到其中的一个数字进行计数。而最终的结果，就是这些数组的求和累加。这样一来，就减小了锁的粒度。

## 9.如何选择悲观锁还是乐观锁 ##

在乐观锁与悲观锁的选择上面，主要看下两者的区别以及适用场景就可以了。

*  响应效率：如果需要非常高的响应速度，建议采用乐观锁方案，成功就执行，不成功就失败，不需要等待其他并发去释放锁。乐观锁并未真正加锁，效率高。一旦锁的粒度掌握不好，更新失败的概率就会比较高，容易发生业务失败。
 *  冲突频率：如果冲突频率非常高，建议采用悲观锁，保证成功率。冲突频率大，选择乐观锁会需要多次重试才能成功，代价比较大。
 *  重试代价：如果重试代价大，建议采用悲观锁。悲观锁依赖数据库锁，效率低。更新失败的概率比较低。
 *  乐观锁如果有人在你之前更新了，你的更新应当是被拒绝的，可以让用户从新操作。悲观锁则会等待前一个更新完成。这也是区别。

[watermark_type_d3F5LXplbmhlaQ_shadow_50_text_Q1NETiBAWk5pbmVTdW4_size_16_color_FFFFFF_t_70_g_se_x_16_pic_center]: https://img-blog.csdnimg.cn/155c6a91c22e4d0b8d857ab91ddcb298.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBAWk5pbmVTdW4=,size_16,color_FFFFFF,t_70,g_se,x_16#pic_center
[watermark_type_d3F5LXplbmhlaQ_shadow_50_text_Q1NETiBAWk5pbmVTdW4_size_20_color_FFFFFF_t_70_g_se_x_16_pic_center]: https://img-blog.csdnimg.cn/0084765332574acba93ec9f74d7ce71f.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBAWk5pbmVTdW4=,size_20,color_FFFFFF,t_70,g_se,x_16#pic_center
[watermark_type_d3F5LXplbmhlaQ_shadow_50_text_Q1NETiBAWk5pbmVTdW4_size_20_color_FFFFFF_t_70_g_se_x_16_pic_center 1]: https://img-blog.csdnimg.cn/848abd43a9234060bf9a6c87350ed114.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBAWk5pbmVTdW4=,size_20,color_FFFFFF,t_70,g_se,x_16#pic_center
[watermark_type_d3F5LXplbmhlaQ_shadow_50_text_Q1NETiBAWk5pbmVTdW4_size_20_color_FFFFFF_t_70_g_se_x_16_pic_center 2]: https://img-blog.csdnimg.cn/d33d5f364716495dbf334fa967d928c9.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBAWk5pbmVTdW4=,size_20,color_FFFFFF,t_70,g_se,x_16#pic_center
[63a595e395104eab87e625c3ee965cc2.png_pic_center]: https://img-blog.csdnimg.cn/63a595e395104eab87e625c3ee965cc2.png#pic_center
[watermark_type_d3F5LXplbmhlaQ_shadow_50_text_Q1NETiBAWk5pbmVTdW4_size_20_color_FFFFFF_t_70_g_se_x_16_pic_center 3]: https://img-blog.csdnimg.cn/c4158fc7387d4eeebb8dede80dc392b5.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBAWk5pbmVTdW4=,size_20,color_FFFFFF,t_70,g_se,x_16#pic_center
[watermark_type_d3F5LXplbmhlaQ_shadow_50_text_Q1NETiBAWk5pbmVTdW4_size_20_color_FFFFFF_t_70_g_se_x_16_pic_center 4]: https://img-blog.csdnimg.cn/eaa139109d02444b84284ceed8a0a0b1.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBAWk5pbmVTdW4=,size_20,color_FFFFFF,t_70,g_se,x_16#pic_center
[49a46de90b5e441cadcca6b0b717aa51.png_pic_center]: https://img-blog.csdnimg.cn/49a46de90b5e441cadcca6b0b717aa51.png#pic_center
[select_for update]: https://blog.csdn.net/zhiyikeji/article/details/123201796?spm=1001.2014.3001.5501
[3d12a4eab3eb4b87acc787532ef6a35b.png_pic_center]: https://img-blog.csdnimg.cn/3d12a4eab3eb4b87acc787532ef6a35b.png#pic_center
[watermark_type_d3F5LXplbmhlaQ_shadow_50_text_Q1NETiBAWk5pbmVTdW4_size_20_color_FFFFFF_t_70_g_se_x_16_pic_center 5]: https://img-blog.csdnimg.cn/c5a9a5959c4d46cf9ea6de1f3bebef68.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBAWk5pbmVTdW4=,size_20,color_FFFFFF,t_70,g_se,x_16#pic_center
[watermark_type_d3F5LXplbmhlaQ_shadow_50_text_Q1NETiBAWk5pbmVTdW4_size_20_color_FFFFFF_t_70_g_se_x_16_pic_center 6]: https://img-blog.csdnimg.cn/2718c72f05b24ceeb1eb28b35c518dff.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBAWk5pbmVTdW4=,size_20,color_FFFFFF,t_70,g_se,x_16#pic_center
[6b262e7f7beb46bf925410e5640a4470.png_pic_center]: https://img-blog.csdnimg.cn/6b262e7f7beb46bf925410e5640a4470.png#pic_center
[watermark_type_d3F5LXplbmhlaQ_shadow_50_text_Q1NETiBAWk5pbmVTdW4_size_20_color_FFFFFF_t_70_g_se_x_16_pic_center 7]: https://img-blog.csdnimg.cn/0969b48e099e4c1aa83f24de244f3bcb.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBAWk5pbmVTdW4=,size_20,color_FFFFFF,t_70,g_se,x_16#pic_center
[watermark_type_d3F5LXplbmhlaQ_shadow_50_text_Q1NETiBAWk5pbmVTdW4_size_20_color_FFFFFF_t_70_g_se_x_16_pic_center 8]: https://img-blog.csdnimg.cn/5f7063eb2a384b098314e6b41980d3a0.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBAWk5pbmVTdW4=,size_20,color_FFFFFF,t_70,g_se,x_16#pic_center