Java 中的悲观锁和乐观锁的实现

红太狼 2022-05-22 00:51 121阅读 0赞

一、定义

1.悲观锁：即很悲观，每次拿数据的时候都觉得数据会被人更改，所以拿数据的时候就把这条记录锁掉，这样别人就没法改这条数据了，一直到你的锁释放。

2.乐观锁：即很乐观，查询数据的时候总觉得不会有人更改数据，等到更新的时候再判断这个数据有没有被人更改，有人更改了则本次更新失败。

二、实现过程

2.悲观锁：悲观锁的实现采用的数据库内部的锁机制，一个典型的倚赖数据库的悲观锁调用：

select \* from account where name=”张三” for update

这条sql 语句锁定了account 表中所有符合检索条件（name=”Erica”）的记录。本次事务提交之前（事务提交时会释放事务过程中的锁），外界无法修改这些记录。也就是 我们可以在查询数据的时候先用for update把这条数据锁住，然后更改完这条数据再提交。这样别的线程没法更新这条数据，也就保证了不会丢失更新。

2.1.悲观锁带来的性能问题。我们试想一个场景：如一个金融系统，当某个操作员读取用户的数据，并在读出的用户数据的基础上进行修改时（如更改用户帐户余额），如果采用悲观锁机制，也就意味着整个操作过程中（从操作员读出数据、开始修改直至提交修改结果的全过程），数据库记录始终处于加锁状态，可以想见，如果面对几百上千个并发，这样的情况将导致怎样的后果？所以我们这个时候可以使用乐观锁。

1.乐观锁：乐观锁的实现可以通过在表里面加一个版本号的形式，下面是一个实例。

![123_method_get-resource_shareToken_2AB794771AEF44E1BF8296C10C93726A_entryId_199816347][]

讲解：也就是每个人更新的时候都会判断当前的版本号是否跟我查询出来得到的版本号是否一致，不一致就更新失败，一致就更新这条记录并更改版本号。

二、使用场景

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

三、另一种的乐观锁实现方法叫做CAS，具体请参照： [https://www.cnblogs.com/qjjazry/p/6581568.html][https_www.cnblogs.com_qjjazry_p_6581568.html]

原理其实和上面说的是一样的，也是通过类似版本号这种模式来进行判断的，不过CAS是在内存中实现这个版本号判断的。

想要更多干货、技术猛料的孩子，快点拿起手机扫码关注我，我在这里等你哦~

![70][]

[123_method_get-resource_shareToken_2AB794771AEF44E1BF8296C10C93726A_entryId_199816347]: https://note.youdao.com/yws/api/group/76450073/noteresource/50EE3AAFAA83423085087A5BDBFA22BC/version/123?method=get-resource&shareToken=2AB794771AEF44E1BF8296C10C93726A&entryId=199816347
[https_www.cnblogs.com_qjjazry_p_6581568.html]: https://www.cnblogs.com/qjjazry/p/6581568.html
[70]: /images/20220522/b41e8a24e6f6485f9eac89fa2a8895ad.png