悲观锁乐观锁简单整理

Posted chinano1

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了悲观锁乐观锁简单整理相关的知识,希望对你有一定的参考价值。

一:介绍

悲观锁,正如其名,具有强烈的独占和排他特性。它指的是对数据被外界(包括本系统当前的其他事务,以及来自外部系统的事务处理)修改持保守态度,因此,在整个数据处理过程中,将数据处于锁定状态。悲观锁的实现,往往依靠数据库提供的锁机制(也只有数据库层提供的锁机制才能真正保证数据访问的排他性,否则,即使在本系统中实现了加锁机制,也无法保证外部系统不会修改数据)。
乐观锁机制采取了更加宽松的加锁机制。悲观锁大多数情况下依靠数据库的锁机制实现,以保证操作最大程度的独占性。但随之而来的就是数据库 性能的大量开销,特别是对长事务而言,这样的开销往往无法承受。相对悲观锁而言,乐观锁更倾向于开发运用。

1. 乐观锁是一种思想,具体实现是,表中有一个版本字段,第一次读的时候,获取到这个字段。处理完业务逻辑开始更新的时候,需要再次查看该字段的值是否和第一次的一样。如果一样更新,反之拒绝。之所以叫乐观,因为这个模式没有从数据库加锁。
2. 悲观锁是读取的时候为后面的更新加锁,之后再来的读操作都会等待。这种是数据库锁

二:解决的问题
在多节点部署或者多线程执行时,同一个时间可能有多个线程更新相同数据,产生冲突,这就是并发问题。这样的情况下会出现以下问题:
更新丢失:一个事务更新数据后,被另一个更新数据的事务覆盖。
脏读:一个事务读取另一个事物为提交的数据,即为脏读。
其次还有幻读。。
针对并发引入并发控制机制,即加锁。
加锁的目的是在同一个时间只有一个事务在更新数据,通过锁独占数据的修改权。
三:优缺点
1、悲观锁,前提是,一定会有并发抢占资源,强行独占资源,在整个数据处理过程中,将数据处于锁定状态。
2、乐观锁,前提是,不会发生并发抢占资源,只有在提交操作的时候检查是否违反数据完整性。只能防止脏读后数据的提交,不能解决脏读。

两种锁各有优缺点,不可认为一种好于另一种,像乐观锁适用于写比较少的情况下,即冲突真的很少发生的时候,这样可以省去了锁的开销,加大了系统的整个吞吐量。但如果经常产生冲突,上层应用会不断的进行retry,这样反倒是降低了性能,所以这种情况下用悲观锁就比较合适。

四:使用场景
1.响应速度:如果需要非常高的响应速度,建议采用乐观锁方案,成功就执行,不成功就失败,不需要等待其他并发去释放锁
2.冲突频率:如果冲突频率非常高,建议采用悲观锁,保证成功率,如果冲突频率大,乐观锁会需要多次重试才能成功,代价比较大
3.重试代价:如果重试代价大,建议采用悲观锁

参考
https://www.zhihu.com/question/29420056
https://yq.aliyun.com/articles/69708?spm=a2c4e.11153940.blogcont69707.72.1e5447c5h3QZjq

 

注:如有不妥之处,欢迎指正



















以上是关于悲观锁乐观锁简单整理的主要内容,如果未能解决你的问题,请参考以下文章

mysql中的乐观锁和悲观锁

浅谈数据库悲观锁和乐观锁

CAS乐观锁悲观锁讲解

乐观锁与悲观锁的简单区分

悲观锁和乐观锁,啥情况

Mysql锁机制--乐观锁 & 悲观锁