乐观锁两种实现机制

难通过简单的版本号来实现乐观锁。

（2）竞争激烈程度

如果悲观锁和乐观锁都可以使用，那么选择就要考虑竞争的激烈程度：

当竞争不激烈时(出现并发冲突的概率小)：

乐观锁更有优势，因为悲观锁会锁住代码块或数据，其他线程无法同时访问，影响并发，而且加锁和释放锁都需要消耗额外的资源。

当竞争激烈时(出现并发冲突的概率大)：

悲观锁更有优势，因为乐观锁在执行更新时频繁失败，需要不断᯿试，浪费CPU资源。

（3）实际操作

悲观锁：

先获取锁，再进行业务操作，一般就是利用类似 SELECT … FOR UPDATE 这样的语句，对数据加锁，避免其他事务意外修改数据。

当数据库执行SELECT … FOR UPDATE时会获取被select中的数据行的行锁，select for update获取的行锁会在当前事务结束时自动释放，

因此必须在事务中使用。

乐观锁：

先进行业务操作，只在最后实际更新数据时进行检查数据是否被更新过。

Java 并发包中的AtomicFieldUpdater 类似，也是利用 CAS 机制，并不会对数据加锁，而是通过对比数据的时间戳或者版本号，来实现乐观锁需要的版本判断。

乐观锁两种实现机制

1、CAS机制（Compare And Swap）

（1）CAS操作包括了3个操作数

1. 需要读写的内存位置(V)
2. 进行比较的预期值(A)
3. 拟写入的新值(B)

（2）操作逻辑

如果内存位置V的值等于预期的A值，则将该位置更新为新值B，否则不进行任何操作。

许多CAS的操作是自旋的：如果操作不成功，会一直᯿试，直到操作成功为止。

（3）问题

问题一、既然CAS包含了Compare和Swap两个操作，它又如何保证原子性呢？

CAS是由CPU支持的原子操作，其原子性是在硬件层面进行保证的。