面试官：可以谈谈乐观锁和悲观锁吗

Posted 2022-08-03 共饮一杯无

什么是悲观锁和乐观锁

乐观锁和悲观锁是两种思想，用于解决并发场景下的数据竞争问题。它们的使用是非常广泛的，不局限于某种编程语言或数据库。乐观锁对应于生活中乐观的人总是想着事情往好的方向发展，悲观锁对应于生活中悲观的人总是想着事情往坏的方向发展。这两种人各有优缺点，不能不以场景而定说一种人好于另外一种人。

悲观锁

悲观锁顾名思义是从悲观的角度去思考问题，解决问题。它总是会假设当前情况是最坏的情况，在每次去拿数据的时候，都会认为数据会被别人改变，因此在每次进行拿数据操作的时候都会加锁，如此一来，如果此时有别人也来拿这个数据的时候就会阻塞知道它拿到锁。在Java中，Synchronized和ReentrantLock等独占锁的实现机制就是基于悲观锁思想。在数据库中也经常用到这种锁机制，如行锁，表锁，读写锁等，都是在操作之前先上锁，保证共享资源只能给一个操作（一个线程）使用。
由于悲观锁的频繁加锁，因此导致了一些问题的出现：比如在多线程竞争下，频繁加锁、释放锁导致频繁的上下文切换和调度延时，一个线程持有锁会导致其他线程进入阻塞状态，从而引起性能问题。

乐观锁

总是假设最好的情况，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号机制和CAS算法实现。乐观锁适用于多读的应用类型，这样可以提高吞吐量，像数据库提供的类似于write_condition机制，其实都是提供的乐观锁。在Java中java.util.concurrent.atomic包下面的原子变量类就是使用了乐观锁的一种实现方式CAS实现的。

两种锁的使用场景

与悲观锁相比，乐观锁适用的场景受到了更多的限制，无论是CAS还是版本号机制。
在并发冲突概率大的高竞争环境下，如果CAS一直失败，会一直重试，CPU开销较大。针对这个问题的一个思路是引入退出机制，如重试次数超过一定阈值后失败退出。当然，更重要的是避免在高竞争环境下使用乐观锁。
CAS的功能是比较受限的，例如CAS只能保证单个变量（或者说单个内存值）操作的原子性，这意味着：

• 原子性不一定能保证线程安全，例如在Java中需要与volatile配合来保证线程安全；
• 当涉及到多个变量(内存值)时，CAS也无能为力。

除此之外，CAS的实现需要硬件层面处理器的支持，在Java中普通用户无法直接使用，只能借助atomic包下的原子类使用，灵活性受到限制。
如果悲观锁和乐观锁都可以使用，那么选择就要考虑竞争的激烈程度：

• 当竞争不激烈 (出现并发冲突的概率小)时，乐观锁更有优势，因为悲观锁会锁住代码块或数据，其他线程无法同时访问，影响并发，而且加锁和释放锁都需要消耗额外的资源。
• 当竞争激烈(出现并发冲突的概率大)时，悲观锁更有优势，因为乐观锁在执行更新时频繁失败，需要不断重试，浪费CPU资源。

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

乐观锁主要两种实现方式

乐观锁一般会使用版本号机制或CAS算法实现。

版本号机制

一般是在数据表中加上一个数据版本号version字段，表示数据被修改的次数，当数据被修改时，version值会加一。当线程A要更新数据值时，在读取数据的同时也会读取version值，在提交更新时，若刚才读取到的version值为当前数据库中的version值相等时才更新，否则重试更新操作，直到更新成功。
举一个简单的例子