悲观锁_悲观锁和乐观锁 场景_oracle乐观锁和悲观锁

悲观锁(Pessimistic Lock), 顾名思义，就是很悲观，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会block直到它拿到锁。传统的关系型里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁。

乐观锁(Optimistic Lock), 顾名思义，就是很乐观，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号等机制。乐观锁适用于多读的应用类型，这样可以提高吞吐量，像如果提供类于write_condition机制的其实都是提供的乐观锁。

为什么需要锁（并发控制）？

在多用户环境中，在同一时间可能会有多个用户更新相同的记录，这会产生冲突。这就是著名的并发性问题。

典型的冲突有：

l丢失更新：一个事务的更新覆盖了其它事务的更新结果，就是所谓的更新丢失。例如：用户A把从6改为2，用户B把从2改为6，则用户A丢失了他的更新。

l脏读：当一个事务读取其它完成一半事务的记录时，就会发生脏读取。例如：用户A,B看到的都是6，用户B把改为2，用户A读到的仍为6。

为了解决这些并发带来的问题。 我们需要引入并发控制机制。悲观锁

并发控制机制

悲观锁：假定会发生并发冲突，屏蔽一切可能违反数据完整性的操作。[1]

乐观锁：假设不会发生并发冲突，只在提交操作时检查是否违反数据完整性。[1]乐观锁不能解决脏读的问题。悲观锁

乐观锁应用

1.使用自增长的整数表示数据版本号。更新时检查版本号是否一致，比如中数据版本为6，更新提交时version=61,使用该version(=7)与version1(=7)作比较，如果相等，则可以更新，如果不等则有可能其他程序已更新该记录，所以返回错误。

2.使用时间戳来实现.

注：对于以上两种方式,Hibernate自带实现方式：在使用乐观锁的字段前加annotation: @Version, Hibernate在更新时自动校验该字段。

悲观锁应用

需要使用的锁机制，比如SQL SERVER 的TABLOCKX（排它表锁）此选项被选中时，SQL Server 将在整个表上置排它锁直至该命令或事务结束。这将防止其他进程读取或修改表中的数据。

SqlServer中使用

Begin Tran

select top 1 @TrainNo=T_NO

from Train_ticket with (UPDLOCK) where S_Flag=0

update Train_ticket

set T_Name=user,

T_Time=getdate(),

S_Flag=1

whereT_NO=@TrainNo

commit

我们在查询的时候使用了with (UPDLOCK)选项,在查询记录的时候我们就对记录加上了更新锁,表示我们即将对此记录进行更新. 注意更新锁和共享锁是不冲突的,也就是其他用户还可以查询此表的内容,但是和更新锁和排它锁是冲突的.所以其他的更新用户就会阻塞.

结论

在实际生产环境里边,如果并发量不大且不允许脏读，可以使用悲观锁解决并发问题；但如果系统的并发非常大的话,悲观锁定会带来非常大的性能问题,所以我们就要选择乐观锁定的方法.

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

本文来自电脑杂谈，转载请注明本文网址：
http://www.pc-fly.com/a/tongxinshuyu/article-39296-1.html