JUC并发编程（12）--- 悲观锁和乐观锁

Posted 2021-07-22 小样5411

前言

悲观锁和乐观锁都是一种设计思想

一、悲观锁

介绍
悲观锁总是很悲观、多疑，它在操作数据时总会认为别人会同时修改数据。每次拿数据的时候总是会给数据上锁。因此操作数据时会直接把数据锁住，直到操作完成才释放锁。常见用了悲观锁设计思想的有synchronized和ReetrantLock，这两个锁总是会给要执行的线程上锁。

使用场景

select status from goods where id=1 for update;

数据库中执行查询操作，从goods表中查询id=1对应记录的status，与普通查询不一样的是，我们使用了select…for update的形式，这是在数据库中实现悲观锁，表示id=1的那一条数据就被锁定了，其它的事务的操作必须等本次事务提交之后才能执行。这个思想还是经常遇见的，就是上锁之后必须等待当前被上锁的执行完，后面的其他线程才能执行，独占的意思。因为必须一个一个上锁，后面必须等待前面执行完才能执行，所以悲观锁的执行效率都不高，但可以保证一个线程安全，相当于牺牲效率，换取安全，执行中不会被修改，悲观锁使用情况确实越来越少了，因为和现在互联网追求高性能相违背，并且如果用悲观锁实现支付功能，为了保证数据安全和高效性，使用悲观锁锁住某个数据后，再遇到其他修改操作，却不能修改，因为被上锁了，这支付功能就有问题，影响很大，所以主要还是用乐观锁，但是线程冲突严重的情况下，乐观锁容易出现自旋，从而CPU开销大大增加，性能比synchronized还低，冲突比较大时还是用悲观锁会更好。

二、乐观锁

介绍
乐观锁总是非常乐观，它总是认为在操作数据时别人不会修改数据。乐观锁不会进行上锁，只是在执行更新的时候判断一下在此期间别人是否修改了数据：如果别人修改了数据则放弃操作（自旋），否则执行更新操作。

乐观锁一般有两种实现方式：版本号机制和CAS

这里就不班门弄斧，我看到一篇写的十分好的介绍版本号机制和CAS

https://blog.csdn.net/weixin_44224716/article/details/103398103

CAS可以看看我这篇文章：
https://blog.csdn.net/weixin_39615182/article/details/116379786