java主流锁之乐观锁和悲观锁

java提供了很多种类的锁，每种锁都有其特性，根据特性在适当的场景下能够展现出非常高的效率。

下图来源于https://zhuanlan.zhihu.com/p/50098743

在一个高并发秒杀的场景下中，很有可能会出现超卖的情况，要解决超卖的问题，可以对数据库中的表或记录加锁。我刚开始在秒杀项目中是用悲观锁来解决超卖的问题，但是在并发量很高的情况，悲观锁的效率可能不是很好，因此，我改用乐观锁来代替悲观锁。那么，什么是乐观锁和悲观锁呢？乐观锁在并发量很高的情况下性能为什么要优于悲观锁呢？怎样简单实现乐观锁和悲观锁呢（下一篇文章中实现）？

什么是悲观锁和乐观锁？

悲观锁

正如其名，它指的是对数据被外界（包括本系统的其它事务，以及来自外部系统的事务处理）修改持保守态度，因此，每次对数据进行操作时，都会将数据置为被锁定状态，这样别的事务想要拿到这个数据都会阻塞。悲观的实现，往往依靠数据库提供的锁机制（也只有数据库提供的锁机制才能真正保证数据访问的排他性）。传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁。

在悲观锁的情况下，为了保证事务的隔离性，就需要一致性锁定读。读取数据时给加锁，其他事务只能读数据，而不能修改、删除数据。当修改删除数据时也要加锁，此时其他事务无法读取数据。

乐观锁

相对悲观锁而言，乐观锁采取了更为宽松的锁机制。悲观锁大部分情况下都要依靠数据库的锁机制实现，以保证操作的独占性。但是随之而来的就是数据库性能的大幅度开销，特别是对长事务来说，这样的开销往往无法接受。

而乐观锁机制在一定程度上解决了这个问题。乐观锁，顾名思义，总是假设最好的情况，每次去拿数据的时候都认为只有自己一个人拿，因此就不会加锁，但是在更新的时候会判断在自己操作数据期间，有没有其他人操作过数据。

乐观锁，大多是基于数据版本（Version）记录机制实现的。那什么是数据版本？数据版本就是为数据增加一个版本标识，在基于数据库表的版本解决方案中，一般是通过给数据库表增加一个"Version" 字段来实现。读取数据时，将此版本号一起读出，之后更新时，将此版本号加一。此时，将提交数据的版本数据与数据库表对应记录的当前版本信息进行比对，如果提交的数据版本号大于数据库表当前版本号，则予以更新，否则认为是过期数据。

除了使用版本号机制外，还可以使用CAS算法来实现乐观锁。例如：在Java中java.util.concurrent.atomic包下面的原子变量类就是使用了乐观锁的CAS实现方式实现的。

乐观锁和悲观锁的使用场景

从以上对两种锁的介绍可以知道两种锁各有其有优缺点，不能认为一种好于另一种，只是说适用于不同的场景。像乐观锁适用于写比较少的场景（多读场景），即冲突真的很少发生的时候，这样就省去了锁的开销，加到了系统的整个吞吐量。但如果是多写的情况，一般会经常发生冲突，这会导致上层的应用会不断地进行retry，这样反倒是降低了性能。所以一般多写的场景下使用悲观锁。

乐观锁实现方式

出来上述的基于版本号机制实现乐观锁外，最长是采用CAS（Compare And Swap（比较与交换））算法实现。CAS算法是一种有名的无锁算法。无锁编程，即不使用锁的情况下实现多线程之间的变量同步，也就是在没有线程被阻塞的情况下实现变量的同步，所以也叫非阻塞同步（Non-blocking Synchronization）

CAS算法基于三个操作数：

• 需要读写的内存值V
• 进行比较的值A
• 拟写入的新值B

当且仅当 V 的值等于 A 时，CAS通过原子方式用新值B来更新V的值，否则不会执行任何操作（比较和替换是一个原子操作）。一般情况下是一个自旋操作，即不断的重试。

当然，虽然CAS算法很高效，但是也会存在很多问题，例如：

• ABA问题
• 循环时间长开销大
• 只能保证一个共享变量的原子操作

我对这些问题产生的原因和解决方案也了解的不是很清楚，所以如果大家有兴趣的话，可以去查阅相关资料。