在一场面试里，有个同学说商品出现超卖问题用了乐观锁去解决。

我就问，为什么这个地方用乐观锁不用悲观锁？

这个同学直接卡壳了，然后面试自然就挂了。

因为这是他自己在简历上写的功能点，我就按照他写的来面，甚至没有扩展。

其实很多人的简历上都写着这种功能点，但是一提问，不管是985的还是二本的同学基本都答不太对。

关于这个问题，首先要知道什么是乐观锁和悲观锁？

它们一般是在数据库层面，分两步，第一步需要select去查询，第二步进行update。

那在出现所谓的超卖的情况时，也就是用户量比较大的时候，乐观锁是个什么形态？

大家注意，一定不要去背名词。

因为在场景题或者在提问里面，不是问那个考点本身。

而且在场景和产品需求里面，如果不理解你很难以考点的内容来回答。

这里的乐观锁我们不讲分布式的业务，也不讲在代码层级的锁，我们就讲数据库锁。

在发量很大的情况下，乐观锁的性能很差。

比如说有1万个人同时过来访问的话，可以抢10个商品，乐观锁的特点是每轮只能卖一个，其他的9,999全部失败。

然后要重新过来抢，每次抢一个，10个商品要抢10次。

有人说那就用悲观锁。

悲观锁在量级很大的时候，好处是如果有10个库存，能一下被抢完。

但是后面的人会等的比较久一点，他会在等前面都执行完了，再执行到他那块。

你会发现在这个场景下，数据库的乐观锁和悲观锁实际上都满足不了超卖问题的需求的。

不管怎么问，因为不满足，所以最后都会减分。

减分那你还想找到工作吗？

而且这还只是单机，还不是说数据库的集群的方式。

所以大家在简历上写的东西不要给自己挖坑。

特别是这种很大的架构的问题，你是要写上去，大厂一定会追问场景，场景不是你说假如说怎么怎么样就好，必须是要真实合理的。

面试的项目部分一定要体现出你的设计能力和分析能力怎么样，你背个考点是展示不出来的。

简历上写的东西一定要自己真实会，而不是一问就卡壳了。