请求a查询库存，发现库存为1，请求b这时也来查询库存，库存也为1，然后请求a让数据库减1，这时候b查询到的仍然是1，也继续让库存减1，就会导致超卖。

超卖问题有以下几个解决方案：

  • 乐观锁：认为线程安全问题不一定会发生，因此不加锁，只是在更新数据时去判断有没有其它线程对数据做了修改。如果没有修改则认为是安全的，自己才更新数据。如果已经被其它线程修改说明发生了安全问题，此时可以重试或异常。
  • 悲观锁：认为线程安全问题一定会发生，因此在操作数据之前先获取锁，确保线程串行执行。例如Synchronized、Lock都属于悲观锁

实现乐观锁主要有以下两种方法：

  1. 版本号法

每次更新数据库的时候按照版本查询，并且要更新版本。

java普通商品防止超卖 java超卖问题_java普通商品防止超卖

  1. CAS

CAS是英文单词Compare And Swap的缩写，翻译过来就是比较并替换。

CAS机制当中使用了3个基本操作数：内存地址V，旧的预期值A，要修改的新值B。

更新一个变量的时候，只有当变量的预期值A和内存地址V当中的实际值相同时，才会将内存地址V对应的值修改为B。

java普通商品防止超卖 java超卖问题_java_02

CAS的缺点：

1.CPU开销较大
在并发量比较高的情况下，如果许多线程反复尝试更新某一个变量，却又一直更新不成功，循环往复，会给CPU带来很大的压力。

2.不能保证代码块的原子性
CAS机制所保证的只是一个变量的原子性操作，而不能保证整个代码块的原子性。比如需要保证3个变量共同进行原子性的更新，就不得不使用Synchronized了。

3.一人一单功能

要求同一个优惠券，一个用户只能下一单

java普通商品防止超卖 java超卖问题_redis_03


这样的方式会产生并发安全问题：

java普通商品防止超卖 java超卖问题_开发语言_04

通过加锁可以解决在单机情况下的一人一单安全问题，但是在集群模式下就不行了（每个jvm都有自己的锁监视器，集群模式下各个服务器的锁不共享）。
因此，我们的解决方案就是实现一个共享的锁监视器，即：
分布式锁：满足分布式系统或集群模式下多进程可见并且互斥的锁。