数据库的乐观锁与悲观锁

本文导读：在金融系统的日终结算处理中，我们希望针对某个时间点的数据进行处理，而不希望在结算进行过程中，数据再发生变化。此时，我们就需要通过一些机 制来保证这些数据在某个操作过程中不会被外界修改，这样的机制，在这里，也就是所谓的 锁 ，即给我们选定的目标数据上锁，使其无法被其他程序修改。数据库支持两种锁机制：即通常所说的悲观锁 和 乐观锁

在实际的多用户并发访问的生产环境里边，我们经常要尽可能的保持数据的一致性。而其中最典型的例子就是我们从表里边读取数据，检查验证后对数据进行修改，然后写回到数据库中。在读取和写入的过程中，如果在多用户并发的环境里边，其他用户已经把你要修改的数据进行了修改是非常有可能发生的情况，这样就造成了数据的不一致性。解决这样的办法，SQL SERVER提出了乐观锁定和悲观锁定的概念。

 

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

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

典型的冲突有：

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

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

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

 

 

悲观锁

顾名思义就是采用一种悲观的态度来对待事务并发问题，我们认为系统中的并发更新会非常频繁，并且事务失败了以后重来的开销很大，这样以来，我们就需要采用真正意义上的锁来进行实现。悲观锁的基本思想就是每次一个事务读取某一条记录后，就会把这条记录锁住，这样
其它的事务要想更新，必须等以前的事务提交或者回滚解除锁。

 

假如我们数据库事务的隔离级别设置为读取已提交或者更低，那么通过悲观锁，我们控制了不可重复读的问题，但是不能避免幻影读的问题，因为要想避免我们就需要设置数据库隔离级别为Serializable,而一般情况下我们都会采取读取已提交或者更低隔离级别，并配合乐观或者悲观锁来实现并发控制，所以幻影读问题是不能避免的，如果想避免幻影读问题，那么你只能依靠数据库的serializable隔离级别（幸运的是幻影读问题一般情况下不严重）

 

悲观锁的实现，往往依靠数据库提供的锁机制（也只有数据库层提供的锁机制才能 真正保证数据访问的排他性，否则，即使在本系统中实现了加锁机制，也无法保证外部系统不会修改数据）。

 

实现方式：

JDBC方式：在JDBC中使用悲观锁，需要使用select for update语句，假如我们系统中有一个Account的类，我们可以采用如下的方式来进行：

　　Select * from Account where ...(where condition).. for update.

 

当使用了for update语句后，每次在读取或者加载一条记录的时候，都会锁住被加载的记录，那么当其他事务如果要更新或者是加载此条记录就会因为不能获得锁而阻塞，这样就避免了不可重复读以及脏读的问题，但是其他事务还是可以插入和删除记录，这样也许同一个事务中的两次读取会得到不同的结果集，但是这不是悲观锁锁造成的问题，这是我们数据库隔离级别所造成的问题。

最后还需要注意的一点就是每个冲突的事务中，我们必须使用select for update 语句来进行数据库的访问，如果一些事务没有使用select for update语句，那么就会很容易造成错误，这也是采用JDBC进行悲观控制的缺点。

 

 

乐观锁

乐观锁是在同一个数据库事务中我们常采取的策略，因为它能使得我们的系统保持高的性能的情况下，提高很好的并发访问控制。乐观锁，顾名思义就是保持一种乐观的态度，我们认为系统中的事务并发更新不会很频繁，即使冲突了也没事，大不了重新再来一次。它的基本思想就是每次提交一个事务更新时，我们想看看要修改的东西从上次读取以后有没有被其它事务修改过，如果修改过，那么更新就会失败。（因此能够解决第二类丢失修改问题）

因为乐观锁其实并不会锁定任何记录，所以如果我们数据库的事务隔离级别设置为读取已提交或者更低的隔离界别，那么是不能避免不可重复读问题的（因为此时读事务不会阻塞其它事务），所以采用乐观锁的时候，系统应该要容许不可重复读问题的出现。

需要注意的是，乐观锁机制往往基于系统中的数据存储逻辑，因此也具备一定的局限性，由于乐观锁机制是在我们的系统中实现，来自外部系统的用户更新操作不受我们系统的控制，因此可能会造成脏数据被更新到数据库中。在 系统设计阶段，我们应该充分考虑到这些情况出现的可能性，并进行相应调整（如将乐观锁策略在数据库存储过程中实现，对外只开放基于此存储过程的数据更新途径，而不是将数据库表直接对外公开）。

 

实现方式：

大多是基于数据版本 （ Version ）记录机制实现。何谓数据版本？即为数据增加一个版本标识，在基于数据库表的版本解决方案中，一般是通过为数据库表增加一个 “version” 字段来实现。
读取出数据时，将此版本号一同读出，之后更新时，对此版本号加一。此时，将提 交数据的版本数据与数据库表对应记录的当前版本信息进行比对，如果提交的数据 版本号大于数据库表当前版本号，则予以更新，否则认为是过期数据。

 

假如系统中有一个Account的实体类，我们在Account中多加一个version字段，那么我们JDBC Sql语句将如下写：

　　Select a.version....from Account as a where (where condition..)

　　Update Account set version = version+1.....(another field) where version =?...(another contidition)

 

这样以来我们就可以通过更新结果的行数来进行判断，如果更新结果的行数为0，那么说明实体从加载以来已经被其它事务更改了，所以就抛出自定义的乐观锁定异常（或者也可以采用Spring封装的异常体系）。具体实例如下：

　　.......

　　int rowsUpdated = statement.executeUpdate(sql);

　　If(rowsUpdated= =0){

　　throws new OptimisticLockingFailureException();

　　}

　　........

 

在使用JDBC API的情况下，我们需要在每个update语句中，都要进行版本字段的更新以及判断，因此如果稍不小心就会出现版本字段没有更新的问题，相反当前的 ORM框架却为我们做好了一切，我们仅仅需要做的就是在每个实体中都增加version或者是Date字段。

 

 

那么究竟该选用什么类型的锁？

这里是没有确切的答案的，因为使用什么样的锁该由具体情况决定。你需要根据你应用程序的需求选择相应类型的锁。

除非你认为一个文档会存在重度的竞争，乐观锁的开销要远低于悲观锁—— 夺取你需要的，迅速做出修改并保存。如果被系统中其他人抢夺，你只能继续尝试直到成功。

使用了悲观锁，你可以对一个指定的项目进行互斥存取 —— 当它被锁定时，其它的线程都不可以访问。这里的关键在于悲观锁在操作失败后必须得到释放。想象一下：你已经获得了对象A，但获得对象B之前你不想放弃对象A；但是另一个已经获得了对象B的用户，在获得对象A之前也不想放弃对象B。那么这时候就需要用到超时设置，它可以打破死锁和处理释放锁失败的情况。

简而起见，用户通常会在整个应用程序中使用相同的锁策略。如果在整个应用程序中都有着同样的需求，这么做也无可非议。事实上，情况不是这样的 —— 不同的应用程序对象有着不同的访问需求。

 

最终的见解

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

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