Java中高级核心知识全面解析——乐观锁与悲观锁（何谓悲观锁与乐观锁？乐观锁的两种实现方式以及缺点、CAS算法(1)

ghfgjfg679

于 2024-05-10 06:00:53 发布

阅读量931

点赞数 15

分类专栏：程序员文章标签： java 面试学习

本文链接：https://blog.csdn.net/ghfgjfg679/article/details/138643528

版权

程序员专栏收录该内容

207 篇文章 0 订阅

订阅专栏

总结

面试建议是，一定要自信，敢于表达，面试的时候我们对知识的掌握有时候很难面面俱到，把自己的思路说出来，而不是直接告诉面试官自己不懂，这也是可以加分的。

以上就是蚂蚁技术四面和HR面试题目，以下最新总结的最全，范围包含最全MySQL、Spring、Redis、JVM等最全面试题和答案，仅用于参考

一份还热乎的蚂蚁金服面经（已拿Offer）面试流程4轮技术面+1轮HR

本文已被CODING开源项目：【一线大厂Java面试题解析+核心总结学习笔记+最新讲解视频+实战项目源码】收录

需要这份系统化的资料的朋友，可以点击这里获取

总是假设最坏的情况，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会阻塞直到它拿到锁（共享资源每次只给一个线程使用，其它线程阻塞，用完后再把资源转让给其它线程）。传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁。Java中synchronized和ReentrantLock等独占锁就是悲观锁思想的实现。

2)乐观锁

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

3) 两种锁的使用场景

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

二、乐观锁常见的两种实现方式

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

1.版本号机制

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

举一个简单的例子：
假设数据库中帐户信息表中有一个version 字段，当前值为1；而当前帐户余额字段（balance）为$100 。

操作员A此时将其读出（version=1），并从其帐户余额中扣除 $50（ $100-$50 ）。
在操作员 A 操作的过程中，操作员B也读入此用户信息（version=1），并从其帐户余额中扣除$20（$100-$20）。
操作员 A 完成了修改工作，将数据版本号加一（version=2），连同帐户扣除后余额（balance=$50 ），提交至数据库更新，此时由于提交数据版本大于数据库记录当前版本，数据被更新，数据库记录version更新为2。
操作员B完成了操作，也将版本号加一（version=2）试图向数据库提交数据（ balance=$80），但此时比对数据库记录版本时发现，操作员B提交的数据版本号为2，数据库记录当前版本也为2，不满足 “ 提交版本必须大于记录当前版本才能执行更新 “ 的乐观锁策略，因此，操作员B的提交被驳回。

这样，就避免了操作员B用基于version=1的旧数据修改的结果覆盖操作员A 的操作结果的可能。

2.CAS算法

即compare and swap（比较与交换），是一种有名的无锁算法。无锁编程，即不使用锁的情况下实现多线程之间的变量同步，也就是在没有线程被阻塞的情况下实现变量的同步，所以也叫非阻塞同步（Non-blocking Synchronization）。CAS算法涉及到三个操作数