乐观锁和悲观锁

最新推荐文章于 2025-04-26 22:19:03 发布

遇_见

最新推荐文章于 2025-04-26 22:19:03 发布

阅读量672

点赞数

CC 4.0 BY-SA版权

分类专栏：分布式存储文章标签：悲观锁乐观锁事务

本文链接：https://blog.csdn.net/hustraiet/article/details/27052167

分布式存储专栏收录该内容

14 篇文章

订阅专栏

为了得到最大的性能，一般数据库都有并发机制，不过带来的问题就是数据访问的冲突。这会产生得冲突，就是著名的并发性问题。典型的冲突有：

丢失更新：一个事务的更新覆盖了其它事务的更新结果，就是所谓的更新丢失。例如：用户A把值从6改为2，用户B把值从2改为6，则用户A丢失了他的更新。
脏读：当一个事务读取其它完成一半事务的记录时，就会发生脏读取。例如：用户A,B看到的值都是6，用户B把值改为2，用户A读到的值仍为6。

为了解决这些并发带来的问题，我们需要引入并发控制机制，大多数数据库用的方法就是数据的锁定。

数据的锁定分为两种方法，第一种叫做悲观锁，第二种叫做乐观锁。什么叫悲观锁呢，悲观锁顾名思义，就是对数据的冲突采取一种悲观的态度，也就是说假设数据肯定会冲突，所以在数据开始读取的时候就把数据锁定住。而乐观锁就是认为数据一般情况下不会造成冲突，所以在数据进行提交更新的时候，才会正式对数据的冲突与否进行检测，如果发现冲突了，则让用户返回错误的信息，让用户决定如何去做，乐观锁不能解决脏读的问题，一个事务读到另外一个事务还没有提交的数据，我们称之为脏读。

对于悲观锁的情况，每次读取数据之前都会对数据加锁，不管是共享锁还是排它锁，操作结束之后释放锁。例如sqlserver就使用过页级锁，操作之前锁定整个页面，也就是说在一个页上的更新插入操作必须要串行化执行（更新插入操作必须一个接着一个），这样的话会造成系统性能下降，用户会经常感觉到系统“假死”(当前用户进程被挂起)。Oracle则使采用了行级锁（如在sql中加入for update 或是for update nowait），只是针对想锁定的数据进行锁定，降低了所的粒度，来提高并发的效率。但是要注意，悲观锁是针对并发的可能性较大的系统，对于一般的应用使用乐观锁就足够了。

与悲观锁相对的，乐观锁一开始就假设不会造成数据冲突，在最后提交的时候再进行数据冲突检测。在乐观锁中，我们有3种常用的做法来实现。

第一种就是在数据取得的时候把整个数据都copy到应用中，在进行提交的时候比对当前数据库中的数据和开始的时候更新前取得的数据。当发现两个数据一模一样以后（数据库状态一致），就表示没有冲突可以提交，否则则是并发冲突，需要去用业务逻辑进行解决。
第二种乐观锁的做法就是采用版本戳，这个在Hibernate中得到了使用（Hibernate自带实现方式：在使用乐观锁的字段前加annotation: @Version, Hibernate在更新时自动校验该字段）。采用版本戳的话，首先需要在你有乐观锁的数据库table上建立一个新的column，比如为number型，当你数据每更新一次的时候，版本数就会往上增加1。比如同样有2个session同样对某条数据进行操作。两者都取到当前的数据的版本号为1，当第一个session进行数据更新后，在提交的时候查看到当前数据的版本还为1，和自己一开始取到的版本相同。就正式提交，然后把版本号增加1，这个时候当前数据的版本为2。当第二个session也更新了数据提交的时候，发现数据库中版本为2，和一开始这个session取到的版本号不一致，就知道别人更新过此条数据，这个时候再进行业务处理，比如整个Transaction都Rollback等等操作。在用版本戳的时候，可以在应用程序侧使用版本戳的验证，也可以在数据库侧采用Trigger(触发器)来进行验证。不过数据库的Trigger的性能开销还是比较的大，所以能在应用侧进行验证的话还是推荐不用Trigger。
第三种做法和第二种做法有点类似，就是也新增一个Table的Column，不过这次这个column是采用timestamp型，存储数据最后更新的时间。在Oracle9i以后可以采用新的数据类型，也就是timestamp with time zone类型来做时间戳。这种Timestamp的数据精度在Oracle的时间类型中是最高的，精确到微秒(还没与到纳秒的级别)，一般来说，加上数据库处理时间和人的思考动作时间，微秒级别是非常非常够了，其实只要精确到毫秒甚至秒都应该没有什么问题。和刚才的版本戳类似，也是在更新提交的时候检查当前数据库中数据的时间戳和自己更新前取到的时间戳进行对比，如果一致则OK，否则就是版本冲突。如果不想把代码写在程序中或者由于别的原因无法把代码写在现有的程序中，也可以把这个时间戳乐观锁逻辑写在Trigger或者存储过程中。

当然不是在所有的情况下，乐观锁都是最好的解决方案。在许多用例中乐观锁可能会有很好的表现，但在其它情况下可能就会需要像悲观锁这样更严格的方案。

当然锁也不是适合所有的情况 —— 如果出现锁竞争，你的应用程序可能就会抛锚。如果一个线程已经获得了一个锁，而OS又没有对这个锁的安排；那么其他想争用这个锁的线程将会被阻塞。当然其中的一个选择就是避免完全加锁，尽量的使用原子操作。这些API对存在高度竞争的数据是很有效的。

参考：

http://blog.itpub.net/12158104/viewspace-374745