浅谈数据库中乐观锁与悲观锁

乐观锁与悲观锁，其实都是对于我们并发时数据库操作时保证数据安全或者完整性的一种方法。

悲观锁：

当一个事务对数据库进行操作时假设使用了悲观锁，其他事务必须排队等待，等这个事务完成操作后，才能对数据库进行操作。类似于线程同步，排队的这种方式。这样就会导致一个效率底下的问题，假设先拿到数据库操作权限的事务，这里假设为A，拿到权限后，一直处于阻塞或者排队的状态，那么此时其他事务本来可以对数据库进行操作，但由于没有权限，所以必须得需要等待A事务释放权限，这样就会一直等待，导致效率很慢。

乐观锁：

乐观锁相对于悲观锁来说，就很好解决了效率问题。假设还是A事务和B事务，同时需要对数据库进行操作，那么当A事务对数据进行操作的时候，B事务不用排队等待A事务结束，而是能够同时对数据进行操作，这样性能就有了很好的提升。但是乐观锁如何保证数据安全呢？

乐观锁保证数据安全的方法一般有两种，CAS算法以及版本号控制。（一般使用版本号机制）

CAS算法：

CAS算法（compare and swap），比较并交换，有三个操作数，内存地址V，预期值B，要替换得到的目标值A。CAS指令执行时，比较内存地址V与预期值B是否相等，若相等，则将A赋给B（若不相等，则会循环比较直到相等）整个比较赋值操作是一个原子操作。但是CAS算法也有缺点。

CAS算法的缺点：

• 循环时间开销大：当内存地址v与预期值B不相等时会一直循环比较直到相等。
• 只能保证一个共享变量的原子操作。
• 如果一个变量V初次读取的时候是A值，并且在准备赋值的时候检查它任然是A值，，那么就说明它的值没有被其他线程修改过吗？很明显不是，因为这段时间里它可能被其他线程修改成其他值，然后又改回为A，那么CAS操作就会认为它的值从来没有被改变过，这个问题被称为CAS操作上的“ABA”问题。

版本号机制：

版本号机制一般是常用的实现乐观锁的方法也是最经典的实现方法。

一般就是在 表设计的时候加多一个版本号version字段当数据表中的数据被修改时，他就会加1，当需要更新时，在读取数据时也会读取version值，在提交更新时，如果数据库中version与之前读取到的version一致，则执行更新操作，否则，重试更新操作，直到更新成功。