乐观锁和悲观锁的介绍以及应用场景

很多程序，比如秒杀程序这种，我们经常只限定卖出去一定量的订单，但是往往这种秒杀活动，大量的用户并发的请求我们的服务器，因此如果按我们的正常的程序流程：

①用户登录前端页面--->②访问后台服务器--->③判断是否还有库存--->④有库存则库存减一，下单成功。

但是，往往这种请求都是大量且并发的，因此由于多个线程，往往会出现异常，发生超卖的现象。

正常情况

异常情况

如上图，显然发生超卖是由于我们线程①在查询库存后，发现库存够，然后准备扣减库存，而在扣减库存前，线程②也来查询库存，发现也够，也进行扣减库存，而此时如果库存只有一个，但是两个线程甚至更多线程都判断库存够，都去扣减库存，因此就会发生超卖的现象。

那么，如何解决上述问题呢？这里很容易想到可以给线程加“锁”，目前我们常见的锁有两种：①悲观锁②乐观锁。

“悲观锁”：悲观锁的思想是认为所有程序都一定会发生线程问题，因此对于某个程序，每进来一个线程，先去判断锁有没有人获取，如果此时锁没人获取，那么就获取锁后进行程序的下一步，而其他线程此时来判断锁有无被获取发现已经被人获取，那么此时就阻塞进程，等待获取锁的那个线程释放锁后再获取锁，进行程序的下一步。JAVA中我们常用的synchronize、lock等锁都是悲观锁。

“乐观锁”：乐观锁的思想是认为程序不会发生线程问题，因此并不像悲观锁那样会阻塞进程，而是对于某个数据加上一个版本号，比如：对于某个商品，我们查询库存的时候会给当前数据加上一个版本号①，当修改库存的时候，会判断现在的版本号（也就是查询出来的版本号）和此时数据库中数据的版本号一不一致，如果一致则修改，如果不一致则不修改。版本号是一个判断标志，当数据每修改一次，版本号便会递增一次，因此对于上述的线程问题：“就算只剩下一个商品时，多个线程同时查询发现库存足够，准备去修改库存时，第一个修改库存的线程发现数据库中版本与查询出来的一致，便扣减库存，下单成功，同时让该数据版本递增一次；而其他线程在准备修改该数据时，发现版本与先前查询的版本不一致，便无法扣减库存。”便解决了线程问题。我们平时数据库中，如MySQL数据库常会用到乐观锁。

以上便是悲观锁和乐观锁的思想和应用场景。