面试官：并发减库存，怎么保证不超卖？

末蓝、 2022-10-23 11:18 119阅读 0赞

**点击关注公众号，回复****面试****获取优质资料**![370a6038de4cd6a6ce0bdc83ac87f21d.png][]

面试中很容易被问到并发减库的问题，如果能回答上来，那是绝对的加分项。

秒杀的场景有很多，比如：抢购、抢票、抢红包等等。总之，就是在极短时间内有大量的请求。

我们都知道，这种系统设计的大方向就是限流，即通过层层过滤，最终只让相对较少的请求进入到核心业务处理层。

这里不谈秒杀设计，不谈使用队列等使请求串行化，就谈下怎么用锁来保证数据正确，就是已经到减库存那一步了，在这一步中如果保证不超卖。

[用队列的话，可以是Java自动的队列，也可以用Redis的LPUSH RPOP][Java_Redis_LPUSH RPOP]

[重点是扣减库存][Java_Redis_LPUSH RPOP]

[我理解，主要的方式是加锁。][Java_Redis_LPUSH RPOP]

[加锁有两个层面：一个是程序层面，另一个是数据库层面。][Java_Redis_LPUSH RPOP]

[![409abea8a10e04db9a03d8674550d60e.png][]][409abea8a10e04db9a03d8674550d60e.png 1]

## [分布式锁][409abea8a10e04db9a03d8674550d60e.png 1] ##

这种场景下应该很少有人用Java自带的锁（比如：synchronized、Lock）吧，因为它们只在同一个JVM内有效，如果你的应用部署了多台的话，应该用分布式锁。

其实，这里加分布式锁就是将多线程请求转成单线程请求，因为每次只有一个线程获得锁并执行，其余都被阻塞了。

这里有一点需要注意，就是当你应用了事务的话可能会存在问题，请看下面的代码

![8f644479f086162ecffd05729c6cd754.png][]

可能有人会这样写，第一眼看起来挺好的，没问题啊，但仔细实践证明是由问题的。

我们知道，mysql默认的事务隔离级别是**REPEATABLE-READ。**

在这种隔离级别下，同一个事务中多次读取，返回的数据是一样的

同时，Spring声明式事务默认的传播特性REQUIRED

[![3a6d306d571aa456e6197507bcf7714b.png][]][3a6d306d571aa456e6197507bcf7714b.png 1]

Spring声明式事务是Spring AOP最好的例子，Spring是通过AOP代理的方式来实现事务的，也就是说在调用reduceStock()方法的之前就已经开启了事务。另外，关注公众号Java技术栈，在后台回复：面试，可以获取我整理的 Spring 系列面试题和答案，非常齐全。

那么，在并发情况下可能会存在这样的情况，假设线程T1和T2都执行到这里，于是它们都开启了事务S1和S2，T1先执行，T2后执行，

由于T2执行的时候事务已经创建了，根据隔离级别，这个时候事务S2读取不到S1已提交的数据，于是就会出现T1和T2读取到的值是一样的，即T2读取的是T1更新前的库存数据。

关于这一点，大家可以自己写个代码测试一下，下面是一段参考：

![1043174a2de506d9a6e4e96d57518928.png][]

鉴于这种情况呢，可以将库存放到Redis中，我们直接读写Redis，这样可以避免受数据库事务的影响，当然这也会带来新的问题，不再讨论。另外，关注公众号Java技术栈，在后台回复：面试，可以获取我整理的 Redis 系列面试题和答案，非常齐全。

## 数据库乐观锁 ##

### CAS（compare and swap）比较并交换 ###

[在Java中，一个线程想修改某个变量的值，那么第一步是将变量的值从主内存中读取到自己工作内存中，然后修改，最后写回主内存。][Java_Redis_LPUSH RPOP]

[这个过程可以归结为：读取——修改——写入，在写回内存的时候可能当前内存中那个值已经发生了变化，这个时候如果继续写则会覆盖别人的数据，只有当内存中的那个值和它修改之前读到的那个值一样，才可以写入。][Java_Redis_LPUSH RPOP]

[这个跟数据库是一样的。][Java_Redis_LPUSH RPOP]

[Java中通过Unsafe中compareAndSwapObject这样的方法类实现的，它直接调用CPU指令。][Java_Redis_LPUSH RPOP]

![08a42ba4dfc4eb34aea8514b6d4b33ff.png][]

数据库中也有CAS，乐观锁就是一种CAS。

### 经典的乐观锁实现： ###

数据增加一个版本标识，一般是通过为数据库表增加一个数字类型的 “version” 字段来实现。当读取数据时，将version字段的值一同读出，数据每更新一次，对此version值加一。

当我们提交更新的时候，判断数据库表对应记录的当前版本信息与第一次取出来的version值进行比对，如果数据库表当前版本号与第一次取出来的version值相等，则予以更新，否则认为是过期数据。

更新的时候带上版本号，只有当前版本号与更新之前查询时的版本一致，才会更新

![4e2ee63fb23b27034a94af1d9f0107f1.png][]

![f90f90c71280606de7cd4a11ede0c231.png][]

## [ABA问题][ABA] ##

这里顺便多提一句，CAS中的ABA问题

假设，原先的值是A，线程-1读取到的值是A，想把它改成D，但是在此期间，有可能其他线程已经多次修改过这个值，只不过最后当线程-1准备将A改成D的时候，它发现恰好还是A，以为没有人改过，其实这时候的A已经不是原来的A了。

也就是说，尽管修改之前做了比较，当然，仍然会出现如下情况：

![6d3193ae5bdfbbce78b5b7fa1c3ff5a7.png][]

### 产生原因    ###

ABA问题导致的原因，是CAS过程中只简单进行了“值”的校验，有些情况下，“值”虽然相同，却已经不是原来的数据了。

### 优化方向 ###

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

### 常见实践 ###

“版本号”的比对，一个数据一个版本，版本变化，即使值相同，也不应该修改成功。

不仅要关注值，还要关注是不是原来的对象

![948eda317f68b5651925aa43326709f6.png][]

[基于“值”的CAS乐观锁，可能导致ABA问题。CAS乐观锁，必须保证修改时的“此数据”就是“彼数据”，应该由“值”比对，优化为“版本号”比对。][ABA]

![11c3bbcffabb5e476c184f5e5c7afc1b.png][]

来源：http://ii081.cn/RjWvU

欢迎加入我的知识星球，升职加薪的好帮手！

![2c0c3d207ddd015a45f52191ca373aa5.png][]

[370a6038de4cd6a6ce0bdc83ac87f21d.png]: /images/20221023/c9be11d4800c4fcc872a1cf9ffe144b1.png
[Java_Redis_LPUSH RPOP]: http://mp.weixin.qq.com/s?__biz=MzI3ODcxMzQzMw%3D%3D&chksm=eb5000fcdc2789ea55afe3a9ffe54659e1b6a8cfb3f491ced82140a5c963cc0eb03788a9543f&idx=2&mid=2247517642&scene=21&sn=258dd06dbb03db2ee49fa0ee40394d35#wechat_redirect
[409abea8a10e04db9a03d8674550d60e.png]: /images/20221023/b0ee24e585f94e27b670af9b362ecd89.png
[409abea8a10e04db9a03d8674550d60e.png 1]: http://mp.weixin.qq.com/s?__biz=MzU4MDM3MDgyMA%3D%3D&chksm=fd555034ca22d9227a63f380444a6cbed806d8096af39e478a0bf1b7a9d674f3a72928844f6c&idx=1&mid=2247497951&scene=21&sn=070d021f91f3c202b8f7ad4d9ec38c9d#wechat_redirect
[8f644479f086162ecffd05729c6cd754.png]: /images/20221023/6ffbaa4b371a441784767f0df29310a9.png
[3a6d306d571aa456e6197507bcf7714b.png]: /images/20221023/3225f003775f4ad288ab885816f33a99.png
[3a6d306d571aa456e6197507bcf7714b.png 1]: http://mp.weixin.qq.com/s?__biz=MzU4MDM3MDgyMA%3D%3D&chksm=fd555158ca22d84e79ccedb310e76635c9de7d218191405bb4ea33440d177450840e4a97b2a9&idx=1&mid=2247498163&scene=21&sn=084b93d5ab3ec1d8c2495ffb46273306#wechat_redirect
[1043174a2de506d9a6e4e96d57518928.png]: /images/20221023/725156d26a304a09a0d265e339ede3b7.png
[08a42ba4dfc4eb34aea8514b6d4b33ff.png]: /images/20221023/d0674c72ed194b0ab04bd7c90f73b837.png
[4e2ee63fb23b27034a94af1d9f0107f1.png]: /images/20221023/49b538b6d80048499b148bb4ec891c34.png
[f90f90c71280606de7cd4a11ede0c231.png]: /images/20221023/8c6ece2afe1240059e0efc29f00878b0.png
[ABA]: http://mp.weixin.qq.com/s?__biz=MzU4MDM3MDgyMA%3D%3D&chksm=fd56b5edca213cfb9e7ae5f54a4076203ff957648d36244a427c8a3443fda04d7edcd86148ba&idx=2&mid=2247490822&scene=21&sn=9563ee974559a60037c814e0a19fff86#wechat_redirect
[6d3193ae5bdfbbce78b5b7fa1c3ff5a7.png]: /images/20221023/36ee11ce5c034f5aa271977573c61ae4.png
[948eda317f68b5651925aa43326709f6.png]: /images/20221023/f2127e5918524587aaf4f0b394da588a.png
[11c3bbcffabb5e476c184f5e5c7afc1b.png]: /images/20221023/5261da0dc52f41d09ad2c4c4bbff2aa0.png
[2c0c3d207ddd015a45f52191ca373aa5.png]: /images/20221023/d25ce12df7994ab9a190af5262c4a757.png