悲观锁和乐观锁的原理及使用场景

悲观锁和乐观锁的区别

术语	描述	示例
乐观锁	每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据	版本号或时间戳控制，适用于多读少写的场景
悲观锁	每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会block直到它拿到锁	DB的行锁、表锁等，适用于数据一致性比较高的场景

场景

什么时候使用乐观锁？

资源提交冲突，其他使用方需要重新读取资源，会增加读的次数，但是可以面对高并发场景，前提是如果出现提交失败，用户是可以接受的。因此一般乐观锁只用在高并发、多读少写的场景。
其中：GIT,SVN,CVS等代码版本控制管理器，就是一个乐观锁使用很好的场景，例如：A、B程序员，同时从SVN服务器上下载了code.html文件，当A完成提交后，此时B再提交，那么会报版本冲突，此时需要B进行版本处理合并后，再提交到服务器。这其实就是乐观锁的实现全过程。如果此时使用的是悲观锁，那么意味者所有程序员都必须一个一个等待操作提交完，才能访问文件，这是难以接受的。

什么时候使用悲观锁？

一旦通过悲观锁锁定一个资源，那么其他需要操作该资源的使用方，只能等待直到锁被释放，好处在于可以减少并发，但是当并发量非常大的时候，由于锁消耗资源，并且可能锁定时间过长，容易导致系统性能下降，资源消耗严重。因此一般我们可以在并发量不是很大，并且出现并发情况导致的异常用户和系统都很难以接受的情况下，会选择悲观锁进行。

示例

乐观锁

版本号控制

1, start transaction  
2, first_version = get_cur_version() // 获取当前数据版本
3, update_data(version+=1)           // 更新操作版本号+1
4, cur_version = get_cur_version()   // 提交更新时，获取版本号
5, if first_version == cur_version   // 比较提交时的版本号与第一次获取的版本号，如果一致，那么认为资源是最新的，可以更新
     then commit 
  else rollback or raise exception  // 否则回滚或者抛出异常

时间戳控制

1, start transaction
2, first_timestamp = get_cur_timestamp()
3, update_data(timestamp=get_sys_cur_timestamp)
4, if first_timestamp = get_cur_timestamp()
      then commit 
   else rollback or raise Exception

悲观锁

悲观锁的实现一般都是通过锁机制来实现的，锁可以简单理解为资源的访问的入口。如果要对一个具有锁属性的资源执行访问时，在更新操作时，需要持锁权才能进行操作，但是往往这种操作可以保证数据的一致性和完整性。例如数据库表的行锁。