乐观锁的两种实现方式

什么场景下须要使用锁？

在多节点部署或者多线程执行时，同一个时间可能有多个线程更新相同数据，产生冲突，这就是并发问题。这样的状况下会出现如下问题：

更新丢失：一个事务更新数据后，被另外一个更新数据的事务覆盖。

脏读：一个事务读取另外一个事物为提交的数据，即为脏读。

其次还有幻读。。

针对并发引入并发控制机制，即加锁。

加锁的目的是在同一个时间只有一个事务在更新数据，经过锁独占数据的修改权。

锁的实现方式

          一、悲观锁，前提是，必定会有并发抢占资源，强行独占资源，在整个数据处理过程当中，将数据处于锁定状态。

          二、乐观锁，前提是，不会发生并发抢占资源，只有在提交操做的时候检查是否违反数据完整性。只能防止脏读后数据的提交，不能解决脏读。

          固然，还有其余的锁机制，暂时很少介绍，着重于乐观锁的实现。

          乐观锁，使用版本标识来肯定读到的数据与提交时的数据是否一致。提交后修改版本标识，不一致时能够采起丢弃和再次尝试的策略。

           记录1，id,status1,status2,stauts3,version，表示有三个不一样的状态，以及数据当前的版本

           操做1：update table set status1=1,status2=0,status3=0 where id=111;  

           操做2：update table set status1=0,status2=1,status3=0 where id=111;

           操做3：update table set status1=0,status2=0,status3=1 where id=111;

           没有任何控制的状况下，顺序执行3个操做，最后前两个操做会被直接覆盖。

           加上version字段，每一次的操做都会更新version，提交时若是version不匹配，中止本次提交，能够尝试下一次的提交，以保证拿到的是操做1提交后的结果。

          这是一种经典的乐观锁实现。

          另外，java中的compareandswap即cas，解决多线程并行状况下使用锁形成性能损耗的一种机制。

          CAS操做包含三个操做数，内存位置（V）,预期原值（A）和新值（B）。若是内存位置的值与预期原值相匹配，那么处理器会西东将该位置值更新为新值。不然，处理器不作任何操做。

          记录2: id，stauts，status 包含3种状态值 1，2，3

           操做，update status＝3 where id＝111 and status＝1；

           即 若是内存值为1，预期值为1，则修改新值。对于没有执行的操做则丢弃。

          思考：这两种方式有什么区别？