悲观锁和乐观锁的一点学习

悲观锁和乐观锁的一点学习
参考地址：http://hi.baidu.com/mageshuai/blog/item/20685b517c23d66884352459.html


锁（ locking ）
业务逻辑的实现过程中，往往需要保证数据访问的排他性。

锁机制是在处理并发的时候所必须的一个东西，当不存在并发的时候根本就不用考虑锁机制

悲观锁【Pessimistic Locking】

顾名思义就是采用一种悲观的态度来对待事务并发问题，我们认为系统中的并发更新会非常频繁，并且事务失败了以后重来的开销很大，这样以来，我们就需要采用真正意义上的锁来进行实现。悲观锁的基本思想就是每次一个事务读取某一条记录后，就会把这条记录锁住，这样
其它的事务要想更新，必须等以前的事务提交或者回滚解除锁。
在应用程序中显式为数据资源加锁。悲观锁假定当前事务操纵数据资源时，肯定还会有其他事务访问该资源，为了避免当前事务的操作受干扰，先锁定资源，它能防止丢失更新和不可重复读等并发问题，但会影响并发性能。
悲观锁的实现，往往依靠数据库提供的锁机制（也只有数据库层提供的锁机制才能 真正保证数据访问的排他性，否则，即使在本系统中实现了加锁机制，也无法保证外部系统不会修改数据）。


实现方式：

JDBC方式：在JDBC中使用悲观锁，需要使用select for update语句，假如我们系统中有一个Account的类，我们可以采用如下的方式来进行：
　　Select * from Account where ...(where condition).. for update.
　　当使用了for update语句后，每次在读取或者加载一条记录的时候，都会锁住被加载的记录，那么当其他事务如果要更新或者是加载此条记录就会因为不能获得锁而阻塞，这样就避免了不可重复读以及脏读的问题，但是其他事务还是可以插入和删除记录，这样也许同一个事务中的两次读取会得到不同的结果集，但是这不是悲观锁锁造成的问题，这是我们数据库隔离级别所造成的问题。


乐观锁【Optimistic Locking】

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


实现方式：

大多是基于数据版本 （ 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，那么说明实体从加载以来已经被其它事务更改了，所以就抛出自定义的乐观锁定异常