本文力求来通俗地讲讲编程中的乐观锁和悲观锁，以及分别是怎么实现的。

啥是锁？啥又是乐观锁和悲观锁？很多人往往觉得自己是飞将数奇，怀才不遇，但一问这些基本的概念都含糊其辞，夸夸而谈，甚至有可能自己代码都敲过，但是就是不知道怎么说，抑或就是根本没理解所以然。今天小马就来做个小整理，通俗地聊一聊吧。

什么是锁，编程中我们提到锁通常是指并发资源锁。那么啥是资源锁，我们通俗地理解加锁行为，当一个资源被两个程序（进程）争夺时，为了保证资源只能够被其中一方使用，因此在获取资源后给其加锁，使用期间不让其他进程获得的过程。由此我们联想到操作系统死锁的概念，我们引用一下便于加深理解，也是一个经典的问题，同时也是我们实现锁时需要注意的一个重点问题：

死锁是指两个或两个以上的进程在执行过程中，由于竞争资源或者由于彼此通信而造成的一种阻塞的现象，若无外力作用，它们都将无法推进下去。此时称系统处于死锁状态或系统产生了死锁，这些永远在互相等待的进程称为死锁进程。虽然进程在运行过程中，可能发生死锁，但死锁的发生也必须具备一定的条件，死锁的发生必须具备以下四个必要条件：互斥条件，请求和保持条件，不剥夺条件，环路等待条件。

大家知道的大名鼎鼎的银行家算法（先借给可以满足全部需求的人完成项目后以等待回款）就是就是避免死锁问题的，只要不让其满足上面的四个条件中的一个就可以。这个算法被用来解决生活中的实际问题，如银行贷款。

怎么理解锁呢？我们来举个栗子。

大学中我们经常看到期末考大家占位图书馆的位置，往往就是让同学放一本书上去，等自己慢悠悠地过去。那么这个放书的动作就相当于对这个位置的资源加锁了。等你自习完，离开后把书也同时拿走了，这就是资源解锁了。哈哈，是不是很好理解也很现实。

抛砖引玉，那么啥是乐观锁和悲观锁。顾名思义，乐观锁就是很乐观地认为资源不会被别人占用，悲观锁就是悲观地认为资源很快就是被占走了，于是加一下锁。对应到场景就是，今天你在宿舍宣布你要去图书馆自习，但是你乐观地认为我昨天的位置肯定没人争夺，于是你认定了那个昨天的位置资源，到那时并没有提前放书占座。等你到达现场，你判断是否被人占走了资源，如果占用了你就不坐了，如果没占那你就会坐下去，成功拥有这个资源。这就是乐观锁，实际上就是在使用前乐观地没有加锁而在使用时做的判断。

那么悲观锁呢？其实就是前一天你离开的时候先放了一本书，然后把资源占住了，你用完再放开这个资源给别人用。嘿嘿，那么死锁是怎么对应到这个场景呢？其实就是你放了一本书，别人也同时放了一本书，然后第二天，你看到有书了在等那个人来把书拿走，你才能坐，而那个人也是一样，在等你把书拿走，她才能坐下去。于是你们都在等彼此，而彼此都没法坐下去使用这个资源，造成了死锁。题外话，如果你用书占了资源但第二天又迟迟不来，那就有点贾人渡河了哈，因此管理员可能会在傍晚直接收书，这其实就是锁的有效期，哈哈哈。

乐观锁与悲观锁的实现

我们常见的悲观锁有哪些呢？比如用redis实现的并发锁，文件锁。那乐观锁有哪些呢？比如DB操作的update where price > 0,还有使用版本号（DB字段或者redis记录版本号）来实现乐观锁，以及CAS。锁主要用于我们编程中的哪些场景呢？非常经典的就是秒杀场景的防止超卖，两种锁的区别在于：悲观锁阻塞（一旦一方锁住资源，其他人都需要等待它释放后才能操作），乐观锁非阻塞（操作时都能操作，最后判断是否成功）。我们分别来详细展开这些锁的实现。

redis实现并发锁（悲观锁）

还有一种防止超卖的并发锁方案是，我们仍然可借助redis，先扣除资源（库存数量redis字段库存减或者销量加或者库存少的话将库存先放入队列也可以），操作失败时回滚库存，但这种方案可能导致少卖的问题。比如A扣除了资源，B查询时没有资源，A执行失败回滚库存，B离开了。这样就多了个库存资源没被卖出了，嘿嘿，是不是很好理解呢。

redis实现乐观锁

我们就根据上面的例子，顺藤摸瓜来搞一个用redis实现版本号乐观锁。

至于版本号其实也可以用查询时取出来的数据库表字段来直接实现，具体视业务需求而定。其实还有一种最简单的方式，就是DB也可以直接实现乐观锁。也就是我们在执行更新操作的时候判断一下条件，原来出来的值是不是更新时数据库的值，如果不是，说明使用使用的同时资源已经被其他人使用过了，类似update  price = 0.02 where price =before_price。总结一下，乐观锁本身其实是不对资源加锁，乐观地认为数据不会被修改，只是等更新的时候来判断是否被修改。

CAS乐观锁

借助于上面的原理，我们来看看CAS乐观锁，CAS其实在JAVA中比较常见，CAS 要解决的问题就是保证原子操作。CAS（Compare and swap），即比较并交换，也是实现我们平时所说的自旋锁或乐观锁的核心操作。CAS机制当中使用了3个基本操作数：内存地址V，旧的预期值A，要修改的新值B。更新一个变量的时候，只有当变量的预期值A和内存地址V当中的实际值相同时，才会将内存地址V对应的值修改为B。

我们可以看到，其实CAS的原理和我们上面提到的乐观锁一样。那是它是借助CPU直接实现的，靠的是直接硬件实现。虽然透明但缺点尚在，在高并发量的情况下，如果多线程反复尝试更新某一个变量，却一直更新不成功，循环往复，给CPU带来巨大压力；CAS机制所保证的只是一个变量的原子性操作，而不能保证整个代码块的原子性，因此代码块的原子性需要协助其他方案。CAS在这里就点到为止，不展开了。

当然，以上只是简单的概念理解和入门例子，具体的实现将更为复杂，需要考虑处理的场景将更为丰富。比如如何避免死锁；没有获取到锁直接失败是不是对用户体验不好，需不需要考虑自旋锁等等问题，redis+lua实现分布式锁不在本文的讨论范围（核心是：自己解自己的锁；要保证条件判断和执行操作的原子性）。在这里就不展开了，有兴趣的可以和小马进一步交流。感谢品阅，拜拜。

原创文章，未经允许请勿转载！