什么是乐观锁

乐观锁( Optimistic Lock ) 相对悲观锁而言，乐观锁假设认为数据一般情况下不会造成冲突，所以在数据进行提交更新的时候，才会正式对数据的冲突与否进行检测，如果发现冲突了，则让返回用户错误的信息，让用户决定如何去做。

应用场景：为什么需要乐观锁？

在多用户环境中，在同一时间可能会有多个用户更新相同的记录，这会产生冲突。这就是著名的并发性问题。

典型的冲突有：

1.丢失更新：一个事务的更新覆盖了其它事务的更新结果，就是所谓的更新丢失。例如：用户A把值从6改为2，用户B把值从2改为6，则用户A丢失了他的更新。

2.脏读：当一个事务读取其它完成一半事务的记录时，就会发生脏读取。例如：用户A,B看到的值都是6，用户B把值改为2，用户A读到的值仍为6。

为了解决这些并发带来的问题。我们需要引入并发控制机制。

锁,即给我们选定的目标数据上锁，使其无法被其他程序修改。

1.悲观锁：指的是对数据被外界(包括本系统当前的其他事务，以及来自外部系统的事务处理)修改持保守态度，因此，在整个数据处理过程中，将数据处于锁定状态

2.乐观锁：假设不会发生并发冲突，只在提交操作时检查是否违反数据完整性。乐观锁不能解决脏读的问题。

那么我们如何实现乐观锁呢，一般来说有以下2种方式：

这是乐观锁最常用的一种实现方式。

何谓数据版本？即为数据增加一个版本标识，一般是通过为数据库表增加一个数字类型的 “version” 字段来实现。

当读取数据时，将version字段的值一同读出，数据每更新一次，对此version值加一。

当我们提交更新的时候，判断数据库表对应记录的当前版本信息与第一次取出来的version值进行比对，如果数据库表当前版本号与第一次取出来的version值相等，则予以更新，否则认为是过期数据。用下面的一张图来说明：

如上图所示，如果更新操作顺序执行，则数据的版本(version)依次递增，不会产生冲突。

但是如果发生有不同的业务操作对同一版本的数据进行修改：
1.先提交的操作(图中B)会把数据version更新为2；
2.当A在B之后提交更新时发现数据的version已经被修改了，那么A的更新操作会失败。

乐观锁定的第二种实现方式和第一种差不多，同样是在需要乐观锁控制的table中增加一个字段，名称无所谓，字段类型使用时间戳(timestamp), 和上面的version类似，也是在更新提交的时候检查当前数据库中数据的时间戳和自己更新前取到的时间戳进行对比，如果一致则OK，否则就是版本冲突。

Java 中java.util.concurrent.atomic包下面的原子变量使用了乐观锁的一种 CAS 实现方式。

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

数据库的表：

create user_table (
    id bigint,
    value varchar(20),
    version bigint
);

有三个字段，分别是：id, value，version

具体实现方案：

1)先读 user_table 表的数据(实际上这个表只有一条记录)，得到 version 的值为 versionValue

2)每次更新 user_table 表中的 value 字段时，为了防止发生冲突，需要这样操作

update user_table 
set value = newValue, 
version =  versionValue + 1   
where version = versionValue;

只有这条语句执行了，才表明本次更新value字段的值成功。
这样保证更新 user_table 表时不发生并发冲突。