使用乐观锁定时是否会出现死锁？

Question

众所周知，有两种锁定策略：乐观锁定和悲观锁定

悲观锁定是锁定记录供您独占使用，直到您使用完它。它比乐观锁定具有更好的完整性，但是需要您小心应用程序设计以避免死锁。

也知道，乐观并发控制与多版本并发控制（Oracle或MSSQL-Snapshot/MVCC-RC）不同：乐观与多版本并发控制-差异？

但是，如果在两个事务中都使用OCC（乐观并发控制），会在两个交易之间发生死锁吗？

我们可以说乐观锁通过减少一致性来减少死锁的可能性吗？并且只有当每个更新都在一个单独的事务中时，死锁的可能性才是0%，但这是最小的一致性。

Answer 1

不会。在乐观锁定中，您乐观地假设“锁定”的键在事务提交之前不会改变。如果在提交事务之前更改了“锁定”键，则事务将被还原并重试。因为乐观锁是100%非阻塞的，所以没有死锁。由于这个原因，我甚至认为乐观锁有时比悲观锁更安全。

Answer 2

当然。

死锁只是意味着线程A持有线程B正在等待的锁，而线程B持有线程A正在等待的锁定。如果应用程序的设计不是在任何地方以相同的顺序锁定资源，那幺不管锁定策略如何，死锁都很容易。

假设线程A和线程B都希望更新父表和子表中的特定行。线程A首先更新父行。线程B首先更新子行。现在线程A尝试更新子行，发现自己被B阻止。同时，线程B尝试更新父行，发现自身被A阻止。您有死锁。

如果在Oracle中锁定资源的顺序是一致的（即总是先于父锁先于子锁），那么无论您的锁定策略如何，您都不会遇到死锁。在SQLServer中通常不会遇到死锁，但是在SQLServer中行级锁升级的可能性使得这一点不太确定。

Answer 3

恐怕您必须非常精确地定义乐观并发控制。在Bernstein、Goodman和Hadzilacos的经典定义中，乐观并发控制允许线程“虚拟地”获取锁，继续更新，然后在事务尝试提交时检查一致性冲突。如果发生一致性冲突，事务将被迫中止并重新提交。根据这个定义，不清楚死锁是如何发生的，因为线程在等待锁时“从不”被阻塞。乐观并发控制的经典定义在实际中不易实现。然而，最近在硬件事务性内存方面的工作打开了一些可能性，并为这个老问题提供了一些视角。