总结乐观锁和悲观锁

乐观锁和悲观锁，就是对数据库进行操作时使用的，乐观锁是update是开始，悲观锁是查询记录那一刻开始，两者结束都是commit或者 rollback

悲观锁，一直锁，不让改 乐观锁，只在更新的时候判断一下别人有没有改过这个数据，保证商品只被卖出一次，可以使用版本号等机制，可以提高数据吞吐量

 并发控制机制，当一个用户锁住了数据之后，其他用户就不能访问

 

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

 

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

 

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

 

1、无论是选择悲观锁策略，还是乐观锁策略。如果一个对象被上了锁，那么该对象都会受这个锁的控制和影响。如果这个锁是个排它锁，那么其它会话都不能修改它。

 

2、选择悲观锁策略，还是乐观锁策略，这主要是由应用和业务需求来确定的。如果你的应用和业务经常会出现从我看到要修改的记录的值，到我修改完成该记录这个时间段内，该记录有较大概率被其它会话所修改。换句话说就是，在我真正去做出修改时，这个记录的值很可能已经与我当初看到的不同了。那么这时，采取悲观锁策略，也许是更好的。而采取悲观锁策略的一个典型操作就是 select ... for undate。通过这种操作，使得从我一开始查看该记录起，这条记录就被上了排它锁，不允许其它会话再对该记录有任何修改。

 

相对的，如果你的业务和应用基本上很少出现这种情景，那么选择乐观锁策略也许就会更好。

 

3、这两种策略的核心其实就是持有锁的时间的起止点不同，悲观锁是从读取记录的那一刻就开始了，而乐观锁只从UPDATE那一刻开始；结束的点两者是一样的，都是发出commit或rollback命令。所以，悲观锁策略会使锁的持续时间更长，而乐观锁的持续时间则较短。其影响就是并发。悲观锁的并发性低于乐观锁。

 

4、无论是采用哪种策略，都要保证数据的完整性。所以，在采用乐观锁策略时，是有可能出现数据的不完整。举例来说：储户甲的存款余额100元，假设在几乎相同的时刻，发生了两笔业务，业务1为其存入了50元，另一个业务是其网上购物消费了30元。显然，这两个操作结束后，甲的存款余额应为120元（100+50-30）。但我们设想一下在数据库层面，可能出现这种情况，当其在银行柜台存入50元时，银行操作员收到了甲存入的50元现金，并通过 select 语句看到甲的当前余额为100元（其发出的指令是下面的语句：

 

select 余额

 

   from 存款余额表

 

where 储户帐号=储户甲的银行帐号;)

 

，接着，发出指令

 

update 存款余额表

 

      set 余额=150

 

    where 储户帐号=储户甲的银行帐号;

 

但就在其看到甲的余额为100元，到其修改甲的余额为150这期间，甲在网上的消费行为导致交易系统已经将甲的余额变成了70元（100-30）并提交了。当银行员工发出的指令也被提交后，甲的余额变成了150元，相当于甲网上消费的行为没有产生任何扣款。这显然是不正确的，更是要避免出现的。

 

如果这套系统采用的是悲观锁策略，那么在从银行员工查看甲当前余额的那一个时刻起（这时查询的指令就会是：

 

select 余额

 

   from 存款余额表

 

where 储户帐号=储户甲的银行帐号 for update;)

 

该记录就已经被锁定了，这时甲网上消费的行为导致的交易系统从甲的帐户中扣减的操作就会处于等待状态。直至银行员工提交了相关指令，交易系统才能去扣减甲的钱款。这样，就可以确保甲的帐户余额是正确的。

 

悲观锁的策略显然可以保证业务的正确性和完整性。但再设想一下，如果甲在存款时，银行员工内急，或者储户甲说等一等，我要考虑一下是否再多存一些。那么，银行员工的操作就不会提交，这时网上交易系统对甲帐户的扣款操作就会一直处于等待状态，或者在等待一定时间后，返回一个扣款失败的提示。这对于系统的效率和客户来说，都不是一个好的体验。

 

5、因为考虑到悲观锁策略可以产生的这种问题，所以，我们在设计应用时，可以采取一些其它方法来避免上述情况的发生。其思想就是在真正提交时，确认要修改的数据没有变化过。主要的方法如下：

 

（1）、更新时带入原始的数据。

 

     update 存款余额表

 

      set 余额=150

 

    where 储户帐号=储户甲的银行帐号 and 余额=100;

 

(2)、在记录上增加修改的时间戳（也可利用ora_rowscn伪列）。即在事务开始时，获取该记录的时间戳，修改时，校验该时间戳，若一致则修改。

 

6、其实，我上面举的这个例子，如果在业务设计时，选择更新指令为

 

update 存款余额表

 

      set 余额=余额+50

 

    where 储户帐号=储户甲的银行帐号;

 

那么，即使是在乐观锁策略的情况下，依然可以保证数据的正确性和完整性。

 

 

 

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

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

典型的冲突有：

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

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

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

并发控制机制

    最常用的处理多用户并发访问的方法是加锁。当一个用户锁住数据库中的某个对象时，其他用户就不能再访问该对象。加锁对并发访问的影响体现在锁的粒度上。比如，放在一个表上的锁限制对整个表的并发访问；放在数据页上的锁限制了对整个数据页的访问；放在行上的锁只限制对该行的并发访问。可见行锁粒度最小，并发访问最好，页锁粒度最大，表锁介于2者之间。

 

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

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

 

     从数据库厂商的角度看，使用乐观的页锁是比较好的，尤其在影响很多行的批量操作中可以放比较少的锁，从而降低对资源的需求提高数据库的性能。再考虑聚集索引。在数据库中记录是按照聚集索引的物理顺序存放的。如果使用页锁，当两个用户同时访问更改位于同一数据页上的相邻两行时，其中一个用户必须等待另一个用户释放锁，这会明显地降低系统的性能。interbase和大多数关系数据库一样，采用的是乐观锁，而且读锁是共享的，写锁是排他的。可以在一个读锁上再放置读锁，但不能再放置写锁；你不能在写锁上再放置任何锁。锁是目前解决多用户并发访问的有效手段。  

乐观锁应用

1.      使用自增长的整数表示数据版本号。更新时检查版本号是否一致，比如数据库中数据版本为6，更新提交时version=6+1,使用该version值(=7)与数据库version+1(=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
         where T_NO=@TrainNo
commit

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

结论

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

 

 

https://www.cnblogs.com/jinlinFighting/p/5933724.html