乐观锁和悲观锁的使用场景

悲观锁和乐观锁只适用于更新操作。

使用哪种机制,取决于你的场景,本质上原则和目标:提高写效率。

悲观锁是避免冲突,乐观锁是检验冲突。

若存在大量冲突的情况下,使用悲观锁的效率会更高。

概念

悲观锁:每次改变数据时,都担心数据被修改。故在悲观锁的环境中,在改变对象之前就将该对象锁住,直到你提交更改后才释放锁。悲观锁的缺点在于可能会长时间限制其他用户的访问,也就是说悲观锁的并发访问性不好。

乐观锁:每次更改数据时,不担心数据被修改。因此乐观锁在提交更改时才会将对象锁住,当读取或改变对象时并不加锁。可见乐观锁加锁时间比悲观锁短,乐观锁加锁粒度比较小。但是在你提交改变时,发现对象已经被改变,于是你不得不重新读取该对象并作出改变(自旋操作)这说明在乐观锁环境中,会增加并发用户读取对象的数量。

如何抉择

乐观锁可以提供并发访问的效率,但是如果出现了冲突只能向上抛出,然后重来一遍;悲观锁可以避免冲突的发生,但是会降低效率。

选择使用哪一种锁取决于冲突频率一旦发生冲突的严重性。如果系统并发访问冲突的频率很低或者冲突发生后的后果并不严重(所谓后果应该就是被检测到冲突的提交会失败,必须重来一次),可以使用乐观锁,否则使用悲观锁。

适用场景

实际上,无论是悲观锁还是乐观锁,都是update(行级锁)操作。悲观锁语法是select * from table for update预先加锁,防止其他用户访问。而乐观锁,本质上是检测冲突(检测是否发生改变),而非预防冲突。一般使用版本号控制。

一般来说,我们业务操作,一般在接受请求后,登记流水表(状态"未处理")。而在响应的时候,需要更新流水表(一个条件便是状态),此时便是使用了乐观锁:在提交改变时检测是否冲突

你可能感兴趣的:(乐观锁和悲观锁的使用场景)