数据库中的悲观锁和乐观锁

为了得到最大的性能，一般数据库都有并发机制，不过带来的问题就是数据访问的冲突。为了解决这个问题，大多数数据库用的方法就是数据的锁定。

1、悲观锁，正如其名，它指的是对数据被外界（包括本系统当前的其他事务，以及来自外部系统的事务处理）修改持保守态度，因此，在整个数据处理过程中，将数据处于锁定状态。悲观锁的实现，往往依靠数据库提供的锁机制（也只有数据库层提供的锁机制才能真正保证数据访问的排他性，否则，即使在本系统中实现了加锁机制，也无法保证外部系统不会修改数据）。

2、乐观锁（ Optimistic Locking ） 
相对悲观锁而言，乐观锁机制采取了更加宽松的加锁机制。悲观锁大多数情况下依靠数据库的锁机制实现，以保证操作最大程度的独占性。但随之而来的就是数据库性能的大量开销，特别是对长事务而言，这样的开销往往无法承受。
而乐观锁机制在一定程度上解决了这个问题。乐观锁，大多是基于数据版本（ Version ）记录机制实现。何谓数据版本？即为数据增加一个版本标识，在基于数据库表的版本解决方案中，一般是通过为数据库表增加一个 “version” 字段来实现。读取出数据时，将此版本号一同读出，之后更新时，对此版本号加一。此时，将提交数据的版本数据与数据库表对应记录的当前版本信息进行比对，如果提交的数据版本号大于数据库表当前版本号，则予以更新，否则认为是过期数据。

考虑下面的情况：如果我们先查询到数据，然后更新数据，这样会出现这样的情况。
A线程查询的时候，B线程也在查询，当A线程准备更新的时候，B线程先获得 了更新锁，将这些行锁定了。A只能等待B更新完。当B线程更新完释放锁的时候，A获得锁，这时A会识别出字段已经修改，所以会重新查询数据，然后开始更新。

 

这在数据库中本来是没什么问题的，但应用程序中会出现一个问题。

假如有一个修改商品信息的页面 

A，打开这个页面，得到商品数据。有编号 ，名称 ，价格。 

B，也打开这个页面，得到商品数据。有编号 ，名称 ，价格。 

然后A修改商品的价格，然后点保存。 

B修改商品的名称，点保存。 

这里有一个问题是，当A保存修改后的商品价格时，他实际上保存了原编号，原名称，修改后价格。 

然后B再点保存的时候，他实际上保存了原编号，修改后的名称，原价格。 

这样，B的修改就将A的修改覆盖了，导致A的修改无效。

 

那么，怎么解决这种问题呢？

 

这里有两种方法解决这个问题，也就是所谓的乐观锁和悲观锁。

 

悲观锁

悲观锁是这样实现的。

当查询到商品信息，并试图更新数据时，在查询的语句后加上for update nowait

这表示当A从准备更新这个数据（查询这个数据并显示到页面上）开始，这个数据就被锁定了，当你更新完成，才释放锁。

当B也准备更新这个数据时，因为有for update nowait,查询这个数据时并显示到页面上就会出错。所以不会更新。

这样就能保证每次只有一个准备更新的连接。从而就保证了数据不会出现丢失更新

 

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

也就是说，当我们找到需要更改的对象时，就把这些行锁定，只能让我修改。当我修改完成时，再释放这个锁，别人才能修改。这样就能防止我找到需要更改的对象到我开始更新数据这段时间内，其他线程获得锁先更新数据的情况。

 

乐观锁

乐观锁是这样实现的。

每次更新时都和旧版本的数据比较。具体如下：

A，打开这个页面，得到商品数据。有编号 ，名称 ，价格。 

B，也打开这个页面，得到商品数据。有编号 ，名称 ，价格。 

然后A修改商品的价格，然后点保存。这时更新语句是这样的 

set 编号 = 原编号 ,名称 = 原名称 ,价格 =新价格 where 编号 = 原编号 ,名称 = 原名称 ,价格 =原价格 

因为A更新时满足WHERE后条件，所以更新成功。 

当B修改商品的名称，点保存。语句是这样的 

set 编号 = 原编号 ,名称 = 新名称 ,价格 =原价格 where 编号 = 原编号 ,名称 = 原名称 ,价格 =原价格 

此时价格已经是新的价格，所以价格（新价格） = 原价格 条件不满足，所以更新不成功。 

这样就避免了丢失更新。 

每个数据都和旧数据比较，可能比较麻烦，可以专门建一列，用作版本列。 

当更新一次时，版本列数据加1。这样然后A修改商品的价格，然后点保存。这时更新语句是这样的 

set 编号 = 原编号 ,名称 = 原名称 ,价格 =新价格 ,版本 = 版本 + 1 where 编号 = 原编号 ,版本 = 版本  

因为A更新时满足WHERE后条件，所以更新成功。 

当B修改商品的名称，点保存。语句是这样的 

set 编号 = 原编号 ,名称 = 新名称 ,价格 =原价格 ,版本 = 版本 + 1 where 编号 = 原编号 ,版本 = 版本  

此时价格已经是新的版本 ，所以版本 （新版本 ） = 原版本  条件不满足，所以更新不成功。 

这里的版本号也可以采用时间戳类型，这样可以顺便看到该行最后更新的时间。

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

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/9399028/viewspace-1814949/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/9399028/viewspace-1814949/