CAS-乐观锁的一种实现方式

什么是乐观锁?

顾名思义,就是很乐观,每次去拿数据的时候认为别人不会修改,所以不会上锁,但是在更新的时候会判断一下在此期间别人有没有去更新这个数据,可以使用版本号机制的。乐观锁适用于读多的应用类型,这样可以提高吞吐量,

什么是CAS?

CAS全称是Compare and Swap,即比较并交换,是通过原子指令来实现多线程的同步功能,将获取存储在内存地址的原值和指定的内存地址进行比较,只有当他们相等时,交换指定的预期值和内存中的值,这个操作是原子操作,若不相等,则重新获取存储在内存地址的原值。

什么是CAS的ABA问题?

CAS乐观锁机制确实能够提升吞吐,并保证一致性,但在极端情况下可能会出现ABA问题。

考虑如下操作:

  • 并发1(上):获取出数据的初始值是A,后续计划实施CAS乐观锁,期望数据仍是A的时候,修改才能成功
  • 并发2:将数据修改成B
  • 并发3:将数据修改回A
  • 并发1(下):CAS乐观锁,检测发现初始值还是A,进行数据修改

上述并发环境下,并发1在修改数据时,虽然还是A,但已经不是初始条件的A了,中间发生了A变B,B又变A的变化,此A已经非彼A,数据却成功修改,可能导致错误,这就是CAS引发的所谓的ABA问题。

ABA问题可以怎么优化?

ABA问题导致的原因,是CAS过程中只简单进行了“值”的校验,再有些情况下,“值”相同不会引入错误的业务逻辑(例如余额),有些情况下,“值”虽然相同,却已经不是原来的数据了(例如堆栈)。

因此,CAS不能只比对“值”,还必须确保是原来的数据,才能修改成功。

常见的实践是,将“值”比对,升级为“版本号”的比对,一个数据一个版本,版本变化,即使值相同,也不应该修改成功

余额并发读写例子,引入版本号的具体实践如下:

  • 查询余额时,同时查询版本号:
1
SELECT money FROM balance WHERE uid=$uid

升级为:

1
SELECT money,version FROM balance WHERE uid=$uid

假设有并发操作,都会将版本号查询出来。

  • 设置余额时,必须版本号相同,并且版本号要修改:

旧版本“值”比对:

1
UPDATE balance SET money=38 WHERE uid=$uid AND money=100

升级为“版本号”比对:

1
UPDATE balance SET money=38, version=$version_new WHERE uid=$uid AND version=$version_old

此时假设有并发操作,首先操作的请求会修改版本号,并发操作会执行失败。

有用就打赏一下作者吧!