一、锁（locking），为什么需要锁？

? ?业务逻辑的实现过程中，往往需要保证数据访问的排他性。如在金融系统的日终结算处理中，我们希望针对某个?cut-off?时间点的数据进行处理，而不希望在结算进行过程中可能是几秒种，也可能是几个小时），数据再发生变化。此时，我们就需要通过一些机制来保证这些数据在某个操作过程中不会被外界修改，这样的机制，在这里，也就是所谓的“?锁?”，即给我们选定的目标数据上锁，使其无法被其他程序修改。

?

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

? ?典型的冲突有：

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

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

?

?

二、悲观锁（Pessimistic Locking）和?乐观锁（Optimistic Locking）

? ? ?悲观锁，正如其名，它指的是对数据被外界（包括本系统当前的其他事务，以及来自?

外部系统的事务处理）修改持保守态度，因此，在整个数据处理过程中，将数据处于锁定?
状态。悲观锁的实现，往往依靠数据库提供的锁机制（也只有数据库层提供的锁机制才能?
真正保证数据访问的排他性，否则，即使在本系统中实现了加锁机制，也无法保证外部系?
统不会修改数据）

? ? ?乐观锁，相对悲观锁而言，乐观锁机制采取了更加宽松的加锁机制。悲观锁大多数情况下依靠数据库的锁机制实现，以保证操作最大程度的独占性。但随之而来的就是数据库?

性能的大量开销，特别是对长事务而言，这样的开销往往无法承受。

?

? ? 并发控制机制

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

乐观锁：假设不会发生并发冲突，只在提交操作时检查是否违反数据完整性。

乐观锁不能解决脏读的问题。

?

三、悲观锁?和?乐观锁 应用

? ??乐观锁应用

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