漫谈悲观锁乐观锁

关注公众号【高性能架构探索】，后台回复【pdf】，免费获取计算机必备经典书籍

概念

悲观锁(Pessimistic Lock)

总是假设最坏的情况，每次拿数据的时候，都认为别人也会修改，所以每次都会加锁。当要对数据库中的一条数据进行修改的时候，为了避免同时被其他人修改，最好的办法就是直接对该数据进行加锁以防止并发。这种借助数据库锁机制，在修改数据之前先锁定，再修改的方式被称之为悲观并发控制【Pessimistic Concurrency Control，缩写“PCC”，又名“悲观锁”】。

悲观锁，正如其名，具有强烈的独占和排他特性。它指的是对数据被外界(包括本系统当前的其他事务，以及来自外部系统的事务处理)修改持保守态度。因此，在整个数据处理过程中，将数据处于锁定状态。悲观锁的实现，往往依靠数据库提供的锁机制(也只有数据库层提供的锁机制才能真正保证数据访问的排他性，否则，即使在本系统中实现了加锁机制，也无法保证外部系统不会修改数据)。

乐观锁(Optimistic Locking)

乐观锁是相对悲观锁而言的，总是假设最好的情况，每次拿数据的时候，都认为别人不会修改。但是在更新数据的时候，会判断再次期间有没有人去修改这个数据，如果发现被修改了即产生了冲突，则返回给用户错误的信息，让用户决定如何去做。乐观锁适用于读操作多的场景，这样可以提高程序的吞吐量。

基本原理

实现方式

悲观锁

悲观锁的实现是依赖于数据库提供的锁机制，流程如下：

1. 修改记录前，对记录加上排他锁(exclusive locking)

2. 如果加锁失败，说明这条数据正在被修改，那么当前查询要等待或者抛出异常，这由开发者决定

3. 如果加锁成功，可以对这条数据修改了，事务完成解锁

4. 加锁修改期间，其他事务也想对这条记录进行操作时，都要等待或者直接抛出异常

注意：在使用 mysql Innodb 引擎实现悲观锁时，必须关闭 mysql 的自动提交属性，因为 MySQL 默认使用 autocommit 模式，也就是说，当你执行一个更新操作后，MySQL 会立刻将结果进行提交。执行：set autocommit = 0;

乐观锁

通常有两种实现方式：

1、版本号方式，由用户来实现

2、CAS(Compare And Set)

下面以一个例子来理解悲观锁和乐观锁的机制

A和B用户最近都想吃猪肉脯，于是他们打开了购物网站，并且找到了同一家卖猪肉脯的店铺。

该店铺的商品表goods和表数据如下：

id	name	num
1	猪肉脯	1
2	牛肉干	1

从表中可以看到猪肉脯目前的数量只有1个了。在不加锁的情况下，如果A，B同时下单，就有可能导致超卖。

悲观锁解决：

利用悲观锁的解决思路是，我们认为数据修改产生冲突的概率比较大，所以在更新之前，我们显示的对要修改的记录进行加锁，直到自己修改完再释放锁。加锁期间只有自己可以进行读写，其他事务只能读不能写。

A下单前先给猪肉脯这行数据（id=1）加上悲观锁（行锁）。此时这行数据只能A来操作，也就是只有A能买。B想买就必须一直等待。

当A买好后，B再想去买的时候会发现数量已经为0，那么B看到后就会放弃购买。

那么如何给猪肉脯也就是id=1这条数据加上悲观锁锁呢？我们可以通过以下语句给id=1的这行数据加上悲观锁

select num from goods where id = 1 for update;

通过开启mysql的两个会话来分析整个悲观锁的执行过程

1、事务A执行命令给id = 1的数据上悲观锁准备更新数据

//0.开始事务begin; //1.查询出商品库存信息select num from goods where id = 1 for update;//2.修改商品库存为2update goods set num = 0 where id = 1;//3.提交事务commit;

2、事务B也去给id = 1的数据上悲观锁准备更新数据

//0.开始事务begin; //1.查询出商品库存信息select num from goods where id = 1 for update;

事务B将会阻塞，一直在等待A释放锁，如果A长期不释放锁，那么最终事务B将会报错(超时)

3、当事务A执行完成后，事务B拿到了锁，此时获取到的商品数为0，那么B看到后，就知道没有库存了。

乐观锁解决：

版本号方式

id	name	num	version
1	猪肉脯	1	0
2	牛肉干	1	0

使用乐观锁的解决思路是，我们认为数据修改产生的冲突的概率不大，多个事务在修改数据之前，先查出版本号，在修改的时候，把当前版本号作为修改条件，只会有一个事务可以修改成功，其他事务则会失败

A和B同事将id = 1的猪肉铺的数据查出来，然后A先买，A将id = 1的version= 1作为条件进行数据更新，即数量-1，并且将版本号+1

此时版本号变为1，A此时就完成了商品的购买。最后B开始卖，B也将id = 1和version = 0作为条件，进行数据更新，但是更新完后发现更新的数据行数为0，此时说明已经有人改动过数据，此时就应该提示用户重新查看最新数据购买。

1、A事务和B事务同时查找id = 1 的数量和版本号

select num, version from goods where id = 1;//此时得到的值分别为1 和 0

2、事务A进行购买

update goods set num = num - 1, version = version + 1 where id = 1;select num, version from goods where id = 1;//此时得到的值为0和1

3、事务B进行购买

update goods set num = num - 1, version = version + 1 where id = 1 and version = 1;//购买失败

CAS方式

CAS是一种乐观锁实现方式，顾名思义就是先比较后更新。在对一个数据进行更新前，先持有对这个数据原有值的备份。比如，要将a=2更新为a=3，在进行更新前会比较此刻a是否为2.如果是2，才会进行更新操作。当多个线程尝试使用CAS同时更新一个变量时，只有一个线程能够成功，其余都是失败。失败的线程不会被挂起，而是被告知这次竞争失败，并且可以再次尝试。

其代码实现如下：

int compare_and_swap(int* reg, int oldval, int newval) {    ATOMIC();    int old_reg_val = *reg;    if (old_reg_val == oldval)        *reg = newval;    END_ATOMIC();    return old_reg_val;}

因为其实现方式与version方式类似，此处不再赘述

使用场景

切不可说某种锁优于另外一种锁，每种锁都有其适合的场景，一般来说，乐观锁适用于读比较多，写比较少的场景，这样，省去了系统开销，加大了系统吞吐量；而悲观锁适用于写比较多的场景，如果在多写的场景下用乐观锁，这就使得应用层有大量的retry操作。

优缺点：

悲观锁

优点：悲观锁利用数据库中的锁机制来实现数据变化的顺序执行，这是最有效的办法

缺点：一个事务用悲观锁对数据加锁后，其他事务将不能对加锁的数据进行除了查询以外的所有操作，如果该事务执行的时间很长，那么其他事务将一直等待，那是比影响我们系统的吞吐量。

乐观锁

乐观锁不在数据库上加锁，任何事务都可以对数据进行操作，这样就避免了使用悲观锁造成的吞吐量下降。

缺点：

1、乐观锁是通过人为实现的，仅仅适用于我们自己业务中，如果有外部事务插入，势必引起异常

2、循环时间长开销大

自选CAS如果长时间不成功，会给CPU带来非常大的执行开销

3、只能保证一个共享变量的原子操作。