乐观锁和悲观锁 你更钟情于哪一个？(2)

举个例子：下面交互图中存在的3个用户。他们3个都在使用CAS尝试去更改X对象 —— 每个客户端都成功，但是一次只有一个。

你并不需要释放锁，吩咐Couchbase就好了

当你做一个get-and-lock的操作时，你提供一个值作为锁的参数。一个键默认会被锁定15秒。15秒过后，如果你还没有手动的释放锁，那么Couchbase会自动的为你释放。

最终的见解

当然不是在所有的情况下，乐观锁都是最好的解决方案。在许多用例中乐观锁可能会有很好的表现，但在其它情况下可能就会需要像悲观锁这样更严格的方案。

当然锁也不是适合所有的情况 —— 如果出现锁竞争，你的应用程序可能就会抛锚。如果一个线程已经获得了一个锁，而OS又没有对这个锁的安排；那么其他想争用这个锁的线程将会被阻塞。当然其中的一个选择就是避免完全加锁，尽量的使用原子操作。这些API对存在高度竞争的数据是很有效的。

原文虽确定了Couchbase Server这个使用背景，但是有些思想和API还是值得借鉴的。

原文链接：Optimistic or pessimistic locking - Which one should you pick? （编译/仲浩 审校/包研）

欢迎关注@CSDN云计算微博，了解更多云信息。

本文为CSDN编译整理，未经允许不得转载。如需转载请联系market@csdn.net

以上就是关于悲观锁的全部内容，相信你一定会非常满意。

本文来自电脑杂谈，转载请注明本文网址：
http://www.pc-fly.com/a/shenmilingyu/article-6655-2.html