0%

[转]数据库的乐观锁和悲观锁

悲观锁

悲观锁假定其他用户企图访问或者改变你正在访问、更改的对象的概率是很高的,因此在悲观锁的环境中,在你开始改变此对象之前就将该对象锁住,并且直到你提交了所作的更改之后才释放锁。悲观的缺陷是不论是页锁还是行锁,加锁的时间可能会很长,这样可能会长时间的限制其他用户的访问,也就是说悲观锁的并发访问性不好。


乐观锁

乐观锁则认为其他用户企图改变你正在更改的对象的概率是很小的,因此乐观锁直到你准备提交所作的更改时才将对象锁住,当你读取以及改变该对象时并不加锁。可见乐观锁加锁的时间要比悲观锁短,乐观锁可以用较大的锁粒度获得较好的并发访问性能。但是如果第二个用户恰好在第一个用户提交更改之前读取了该对象,那么当他完成了自己的更改进行提交时,数据库就会发现该对象已经变化了,这样,第二个用户不得不重新读取该对象并作出更改。这说明在乐观锁环境中,会增加并发用户读取对象的次数。


例子

以版本控制系统为例,来说说两种最基本的并发性问题。


【丢失更新】

小张想修改源代码里面的a方法,正在她修改的同时,小李打开了这个文件,修改了b方法并且保存了文件,等小张修改完成后,保存文件,小李所做的修改就被覆盖了。


【不一致的读】

小张想要知道包里面一共有多少个类,包分了a,b两个子包。小张打开a包,看到了7个类。突然小张接到老婆打来的电话,在小张接电话的时候,小李往a包中加了2个类,b包中加了3个类(原先b包中是5个类)。

小张接完电话后再打开b包,看到了8个类,很自然得出结论:包中一共有15个类。

很遗憾,15个永远不是正确的答案。在小李修改前,正确答案是12(7+5),修改后是17(9+8)。这两个答案都是正确的,虽然有一个不是当前的。但15不对,因为小张读取的数据是不一致的。

小结:不一致读指你要读取两种数据,这两种数据都是正确的,但是在同一时刻两者并非都正确。


隔离和不可变

在企业应用中,解决并发冲突的两种常用手段是隔离和不可变。

只有当多个活动(进程或者线程)同时访问同一数据时才会引发并发问题。一种很自然的思路就是同一时刻只允许一个活动访问数据。如果小张打开了文件,就不允许其他人打开,或者其他人只能通过只读的方式打开副本,就可以解决这个问题。

隔离能够有效减少发生错误的可能。我们经常见到程序员陷入到并发问题的泥潭里,每一段代码写完都要考虑并发问题,这样太累了。我们可以利用隔离技术创建出隔离区域,当程序进入隔离区域时不用关心并发问题。好的并发性设计就是创造这样的一些隔离区域,并保证代码尽可能的运行在其中。

另一种思路:只有当你需要修改共享的数据时才可能引发并发性问题,所以我们可以将要共享的数据制作为“不可变”的,以避免并发性问题。当然我们不可能将所有的数据都做成不可变的,但如果一些数据是不可变的,对它们进行并发操作时我们就可以放松自己的神经了。


乐观并发控制、悲观并发控制

如果数据是可变的,并且无法隔离呢?这种情况下最常用的两种控制就是乐观并发控制和悲观并发控制。

假设小张和小李想要同时修改同一个文件。如果使用乐观锁,俩人都能打开文件进行修改,如果小张先提交了内容,没有问题,他所做的改变会保存到服务器上。但小李提交时就会遇到麻烦,版本控制服务器会检测出两种修改的冲突,小李的提交会被具体,并由小李决定该如何处理这种情况(对于绝大部分版本控制软件来说,会读取并标识出小张做的改变,然后由小李决定是否合并)。

如果使用的是悲观锁,小张先检出(check out)文件,那么小李就无法再次检出同一文件,直到小张提交了他的改变。

建议你将乐观锁想成一种检测冲突的手段,而悲观锁是一种避免冲突的手段(严格来说,乐观锁其实不能称之为“锁”,但是这个名字已经流传开了,那就继续使用吧)。一些老的版本控制系统,比如VSS 6.0使用的是悲观锁的机制。而现代的版本控制系统一般两种都支持,默认使用乐观锁。

乐观锁可以提高并发访问的效率,但是如果出现了冲突只能向上抛出,然后重来一遍;悲观锁可以避免冲突的发生,但是会降低效率。

选择使用那一种锁取决于访问频率和一旦产生冲突的严重性。如果系统被并发访问的概率很低,或者冲突发生后的后果不太严重(所谓后果应该指被检测到冲突的提交会失败,必须重来一次),可以使用乐观锁,否则使用悲观锁。


实现

我们经常会在访问数据库的时候用到锁,怎么实现乐观锁和悲观锁呢?以Hibernate为例,可以通过为记录添加版本或时间戳字段来实现乐观锁。可以用session.Lock()锁定对象来实现悲观锁(本质上就是执行了SELECT * FROM t FOR UPDATE语句)。


转至:

http://www.cnblogs.com/chenlulouis/archive/2010/08/17/1801358.html

觉得不错,就打赏一下吧