我们经常会用锁机制来处理多线程的并发，本文就来讨论下悲观锁和乐观锁这两个非常常用的概念。

悲观锁

悲观锁总是假设最坏的情况，每次去拿数据的时候都认为有人会修改，所以每次在拿数据的时候都会上锁，这样其他线程想拿这个数据就得等它解锁。共享资源每次只给一个线程使用，其它线程阻塞，用完后再把资源转让给其它线程。

传统的关系型数据库里边就用到了很多悲观锁机制，比如行锁、表锁等，都是在操作之前先上锁。Java中 synchronized 和 ReentrantLock 等独占锁就是基于悲观锁机制。

乐观锁

乐观锁总是假设最好的情况，每次去拿数据的时候都认为不会有人修改，所以不会上锁，但是在更新的时候会判断一下在此期间有没有线程更新过这个数据，可以使用版本号机制和CAS算法实现。

乐观锁适用于多读的应用类型，这样可以提高吞吐量。在Java中java.util.concurrent.atomic包下面的原子变量类就是使用了乐观锁的典型实现方式Compare and Swap。

乐观锁适用于写比较少的情况，即冲突很少发生的情况，这样就省去了锁的开销，加大了系统的整个吞吐量。但如果是经常产生冲突的情况，乐观锁会导致上层应用会不断进行重试，这样反倒是降低了性能，所以一般多写的场景下用悲观锁就比较合适。

乐观锁和悲观锁是一种思想，不是一项具体的技术。这两种机制不仅仅被用于Java虚拟机内部，在数据库、互联网应用中也用得非常多。

MySQL数据库自带的锁机制可以很好地解决单节点的数据访问并发问题，但是在大规模并发的场景中，由于读写性能问题是不推荐使用 MySQL的。

高并发场景下的应用

秒杀和抢购是电商系统中典型的高并发场景。这类场景中有一个非常严重的问题，就是“超发”。假设某个抢购场景中库存中仅剩最后一个商品，此时系统发来2个并发请求，这2个请求读取到的商品余量都是1个，2个请求都抢购成功，最终导致超发。

悲观锁思路

对于上述多写场景，我们可以采用悲观锁的思路，也就是在修改库存数据的时候，采用锁定状态，排斥外部请求的修改。没有拿到锁的请求，必须等待，这样会不断累积请求，有可能出现死锁，或者系统陷入内存异常。

为了避免在服务器积累太多的请求，我们可以先将请求放入FIFO队列中，等前面的请求处理完，再处理队列中排队的请求，避免太多请求同时进入发生死锁，就不会导致某些请求永远获取不到锁。

高并发的场景下，有可能一瞬间出现大量请求将队列内存撑爆，我们可以设计一个极大的内存队列，但是队列内的请求积累得过多，最终平均响应时延会大幅延长。

乐观锁思路

乐观锁是更为宽松的加锁机制，甚至也可以认为是不加锁。乐观锁的实现通常采用带版本号的CAS操作。所有请求都有资格去修改库存数据，都会获得一个数据的版本号，只有版本号符合的才能更新成功，其他的都抢购失败，这样不需要考虑排队的问题。

很多软件和服务都支持乐观锁的功能，例如Redis中的watch就是其中之一。Redis watch 命令用于监视一个或多个 key。如果在事务执行之前，发现key 被其他命令所改动，那么事务将被打断。通过这种乐观锁的实现方式，我们也可以保证数据的安全。

我会持续更新关于物联网、云原生以及数字科技方面的文章，用简单的语言描述复杂的技术，也会偶尔发表一下对IT产业的看法，欢迎大家关注，谢谢。