【MySQL】乐观锁 & 悲观锁

参考

简单理解悲观锁、乐观锁
面试必备之乐观锁与悲观锁
数据库索引到底是什么，是怎样工作的？
B-Tree和B+Tree

1 对比

悲观锁

悲观锁假定会发生并发冲突，屏蔽一切可能违反数据完整性的操作。
悲观锁的特点是先获取锁，再进行业务操作。

悲观锁（Pessimistic Lock），每次取数据时都认为数据会被其他线程修改，所以每次在拿数据的时候都会上锁，这样一旦加锁，不同线程同时执行时，只能有一个线程执行，其他的线程在入口处等待，直到锁被释放。

传统的关系型数据库里边就用到了悲观锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁。Java中synchronized和ReentrantLock等独占锁就是悲观锁思想的实现。

乐观锁

乐观锁假设不会发生并发冲突，只在提交操作时检查是否违反数据完整性。
乐观锁的特点先进行业务操作，不到万不得已不去拿锁。

乐观锁（Optimistic Lock），每次去拿数据的时候都认为不会有其他线程对数据进行修改，所以不会上锁，但是提交更新时会判断一下在此期间数据有没有被更改（可以使用版本号机制和CAS(compare and swap)算法实现）。

乐观锁适用于多读的应用类型，这样可以提高吞吐量，像数据库提供的类似于write_condition机制，其实都是提供的乐观锁。在Java中java.util.concurrent.atomic包下面的原子变量类就是使用了乐观锁的一种实现方式CAS实现的。

适用场景

乐观锁适用于写比较少的情况下（多读场景），即冲突真的很少发生的时候，这样可以省去了锁的开销，加大了系统的整个吞吐量。但如果是多写的情况，一般会经常产生冲突，这就会导致上层应用会不断的进行retry，这样反倒是降低了性能，所以一般多写的场景下用悲观锁就比较合适。

2 悲观锁的实现

MySQL InnoDB采用的是两阶段锁定协议（two-phase locking protocol）。在事务执行过程中，随时都可以执行锁定，锁只有在执行 COMMIT或者ROLLBACK的时候才会释放，并且所有的锁是在同一时刻被释放。前面描述的锁定都是隐式锁定，InnoDB会根据事务隔离级别在需要的时候自动加锁。
另外，InnoDB也支持通过特定的语句进行显示锁定，这些语句不属于SQL规范：

SELECT … LOCK IN SHARE MODE
SELECT … FOR UPDATE

使用select…for update会把数据给锁住，不过我们需要注意一些锁的级别，MySQL InnoDB默认行级锁。行级锁都是基于索引的，如果一条SQL语句用不到索引是不会使用行级锁的，会使用表级锁把整张表锁住，这点需要注意。

3 乐观锁的实现

版本号机制

应用最多。
步骤：
取出数据，并记录当前版本号version为 OldVersion;
准备更新数据时，比较此时版本号version与之前保存的OldVersion;
如果version = OldVersion，表示这段时间内从取出数据到现在的这段时间内数据没有被更改过，执行数据更新然后版本号加一，如果两者不相等，则更新失败，重新来过。
使用时间戳和这个类似。

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;
}

CAS 算法涉及三个操作数，需要读写的内存值reg，进行比较的值oldval（最初读取数据时读入的reg内的值），拟写入的新值newval，当且仅当 *reg == oldval 时，将 newval 更新为 reg 内的值，否则不会执行任何操作（比较和替换是一个 原子操作），一般情况下是一个自旋操作，即不断地重试。

CAS 算法存在的问题：
1） ABA 问题。
2）循环时间长开销大。
3）只能保证一个共享变量的 原子操作。
CAS与synchronized的使用情景
待补