乐观锁能实现的,悲观锁都能实现。
而且,通过 [设置锁的颗粒度] 、 [读写锁] 等方式优化,也能解决悲观锁并发受限制的问题。
那为什么要用乐观锁呢?
比如,这篇博客中举的 [在线文档] 的例子,
https://xiaolincoding.com/os/4_process/pessim_and_optimi_lock.html#乐观锁与悲观锁这里举一个场景例子:在线文档。
我们都知道在线文档可以同时多人编辑的,如果使用了悲观锁,那么只要有一个用户正在编辑文档,此时其他用户就无法打开相同的文档了,这用户体验当然不好了。
那实现多人同时编辑,实际上是用了乐观锁,它允许多个用户打开同一个文档进行编辑,编辑完提交之后才验证修改的内容是否有冲突。
[疑问]
像 MySQL 那样用行级别的锁(或者更小的粒度,一个单元格一把锁),不是和使用 [乐观锁] 的效果一样,都能支持 [多用户并发写入] 吗?
一个用户写入单元格,另一个用户不能读的问题,不是也可以通过 [读写锁] 的方式来解决吗?
那么为什么这个场景用乐观锁?
我能想到的解释只有:因为用颗粒度小的悲观锁,需要锁监视器监视大量的锁,导致使用悲观锁的成本太高?
还有其它的解释吗?
这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。
https://www.v2ex.com/t/985369
V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。
V2EX is a community of developers, designers and creative people.