1.在下面并发业务场景
库存业务，stock(id, num)，其中：
id为库存id 是 1
num为库存值是 5
2.并发下查询
select num from stock where id=1
select num from stock where id=1
得到的值都是5 , 没有问题
3.并发修改
---->用户1 :先查询库存是5
update stock set num=2 where id=1
---->用户2 :先查询库存是5
update stock set num=3 where id=1
并发下 , 库存实际上变成了2或者3 , 这就不符合逻辑 ,应该变成0 , 因为卖出了5件商品
4.CAS优化
update stock set num=$num_new where id=1 and num=$num_old
只有当库存是最开始查询出的库存值时才允许修改
5. ABA问题
考虑如下操作：
并发1(上)：获取出数据的初始值是A，后续计划实施CAS乐观锁，期望数据仍是A的时候，修改才能成功
并发2：将数据修改成B
并发3：将数据修改回A
并发1(下)：CAS乐观锁，检测发现初始值还是A，进行数据修改
并发1在修改数据时，虽然还是A，但已经不是初始条件的A了，中间发生了A变B，B又变A的变化，此A已经非彼A，数据却成功修改，可能导致错误
ABA问题导致的原因，是CAS过程中只简单进行了“值”的校验，再有些情况下，“值”相同不会引入错误的业务逻辑(例如库存)，有些情况下，“值”虽然相同，却已经不是原来的数据了。
6.使用版本号机制解决ABA问题
库存的并发读写例子，引入版本号的具体实践如下：
(1)库存表由
stock(id, num)
升级为
stock(id, num, version)
(2)查询库存时同时查询版本号
select num, version from stock where id=$id
使用版本号比对并修改 , 版本号可以每次修改都+1
update stock set num=$num_new, version=$version_new where id=$id and version=$version_old
修改失败的要有重试机制 , 客户就无感知了
