什么场景下需要使用锁？
在多节点部署或者多线程执行时，同一个时间可能有多个线程更新相同数据，产生冲突，这就是并发问题。这样的情况下会出现以下问题：
更新丢失：一个事务更新数据后，被另一个更新数据的事务覆盖。
脏读：一个事务读取另一个事物为提交的数据，即为脏读。
其次还有幻读。。
针对并发引入并发控制机制，即加锁。
加锁的目的是在同一个时间只有一个事务在更新数据，通过锁独占数据的修改权。
锁的实现方式
1、悲观锁，前提是，一定会有并发抢占资源，强行独占资源，在整个数据处理过程中，将数据处于锁定状态。
2、乐观锁，前提是，不会发生并发抢占资源，只有在提交操作的时候检查是否违反数据完整性。只能防止脏读后数据的提交，不能解决脏读。
当然，还有其他的锁机制，暂时不多介绍，着重于乐观锁的实现。
乐观锁，使用版本标识来确定读到的数据与提交时的数据是否一致。提交后修改版本标识，不一致时可以采取丢弃和再次尝试的策略。
记录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，则修改新值。对于没有执行的操作则丢弃。
思考：这两种方式有什么区别？