hibernate之乐观锁（Optimistic Locking）

相对于悲观锁，乐观锁采取了更加宽松的加锁机制，悲观锁大多数是依赖于数据库，如果对于一个长事务来说，这样的开销会很大！

 

如：在银行系统中，一个人想从银行取钱，他的公司正好在这个时候往他的卡里打钱，如果使用悲观锁的话，会将它的帐号暂时锁死，一个人还好，如果要是有成千上万个巧合呢？这样的话，银行的数据库的压力会很大；

 

乐观锁机制在一定程度上解决了这个问题，乐观锁，大多是基于数据版本（version）记录机制实现，何为数据版本？即为数据增加一个版本标识，在基于数据库表的版本解决方案中，一般是通过为数据库表增加一个“version”字段来实现；

读取数据时，将版本号一同读出，之后更新时，对此版本号加1。此时，将提交数据的版本数据与数据库表对应记录的当前版本信息化时，如果提交的数据版本号大于数据库表当前版本号，则予更新，否则认为是过期数据；

 

回到银行的例子中：那个人取了2000；当取钱的操作执行完后将数据版本号＋1（version＝2）；公司也往里打了3000，将版本号＋1（version=2）；公司打钱的操作提交时发现有相同的版本号，那么这个操作被驳回；

 

从例子中可以看出，乐观锁机制避免了长事务中的数据库加锁开销，大大提升了并发量下的系统整体性能表现；

 

需要注意的是：乐观锁机制往往基于系统中的数据存储逻辑，因此也具备一定的局限性，如银行的例子，由于乐观锁机制在我们系统中实现，来自系统外部的用户余额更新操作不受我们影响，因此可能会造成非法数据被更新到数据库中；

 

Hibernate在其数据访问引擎上内置了乐观锁实现，如果不用考虑外部系统对数据库更新操作，利用hibernate提供的透明化乐观锁实现，会简洁！

 

Hibernate中使用乐观锁：

<class name="TUser" table="t_user" optimistic-lock="version">	

 optimistic-lock有如下可选取值：

• none 无乐观锁
• version 通过版本机制实现乐观锁
• dirty 通过检查发生变动过的属性实现乐观锁
• all 通过检查所有属性实现乐观锁

其中Version实现的乐观锁机制是Hibernate官方推荐的乐观锁实现，也是Hibernate中，目前唯一在实体对象脱离Session发生修改的情况下依然有效的锁机制。这种方法使用较多！

		<version name="version" column="version" type="integer"></version>

 version节点必须出现id节点后；