hibernate的悲观锁和乐观锁

一、hibernate的锁机制

多个用户可能同时读取同一个数据。为了保证 数据的一致性，需要一种机制来保障其他的程序在这一时刻不能修改这一数据。即上锁。

hibernate中提供了 两种上锁机制，悲观锁和乐观锁。

二、悲观锁

悲观锁指的是线程对数据被外界修改持保守态度。假定任何时刻存取数据时，都可能有另一个客户也正在存取同一笔数据，为了保持数据被操作的一致性，于是对数据采取了数据库层次的锁定状态，依靠数据库提供的锁机制来实现。

jdbc实现的数据库加锁：

select * from account where name="Erica" for update

hibernate悲观锁的具体实现：

String hql="查询语句";
Query query=session.createQuery(sql);
query.setLockMode("对象"，LockModel.UPGRADE);

Criteria criteria = session.createCriteria(xxxx.class);
criteria.setLockMode(LockModel.UPGRADE);

hibernate的加锁模式：

LockMode.NONE：无锁机制。
LockMode.WRITE：Hibernate在Insert和Update记录的时候会自动获取。
LockMode.READ：Hibernate在读取记录的时候会自动获取。

这三种加锁模式是供hibernate内部使用的，与数据库加锁无关。

LockMode.UPGRADE：利用数据库的for update字句加锁。在这里我们要注意的是：只有在查询开始之前（也就是hiernate生成sql语句之前）加锁，才会真正通过数据库的锁机制加锁处理。否则，数据已经通过不包含for updata子句的sql语句加载进来，所谓的数据库加锁也就无从谈起。

从系统的性能上来考虑，对于单机或小系统而言，这并不成问题，然而如果是在网络上的系统，同时间会有许多联机，假设有数以百计或上千甚至更多的并发访问出现，我们该怎么办？如果等到数据库解锁我们再进行下面的操作，我们浪费的资源是多少？--这也就导致了乐观锁的产生。

三、乐观锁

乐观锁定（optimistic locking），乐观的认为资料的存取很少发生同时存取的问题，因而不作数据库层次上的锁定，为了维护正确的数据，乐观锁定采用应用程序上的逻辑实现版本控制的方法。

Hibernate 中透过版本号检查来实现后更新为主，这也是Hibernate所推荐的方式，在数据库中加入一个VERSON栏记录，在读取数据时连同版本号一同读取，并在更新数据时递增版本号，然后比对版本号与数据库中的版本号，如果大于数据库中的版本号则予以更新，否则就回报错误。

hibernate使用乐观锁的设置步骤：

1、在映像文件中，我们使用optimistic-lock属性设定version控制，<id>属性栏之后增加一个<version>标签

<class name="xxxxxx" talble="xxxxxx"
           optimistic-lock="version">
        <id...../>
        <version name="version" column="VERSION"/>

乐观锁不能解决的问题存在：乐观锁机制的实现往往基于系统中的数据存储逻辑，在我们的系统中实现，来自外部系统的用户余额更新不受我们系统的控制，有可能造成非法数据被更新至数据库。因此我们在做电子商务的时候，一定要小心的注意这项存在的问题，采用比较合理的逻辑验证，避免数据执行错误。

如果数据库不支持所指定的锁定模式，Hibernate会选择一个合适的锁定替换，而不是丢出一个例外。