数据库乐观锁和悲观锁的理解和实现（转载&总结）

数据的锁定分为两种，第一种叫做悲观锁，第二种叫做乐观锁。

一、悲观锁，就是对数据的冲突采起一种悲观的态度，也就是说假设数据确定会冲突，因此在数据开始读取的时候就把数据锁定住。【数据锁定：数据将暂时不会获得修改】

二、乐观锁，认为数据通常状况下不会形成冲突，因此在数据进行提交更新的时候，才会正式对数据的冲突与否进行检测，若是发现冲突了，则让用户返回错误的信息。让用户决定如何去作。

理解：

1. 乐观锁是一种思想，具体实现是，表中有一个版本字段，第一次读的时候，获取到这个字段。处理完业务逻辑开始更新的时候，须要再次查看该字段的值是否和第一次的同样。若是同样更新，反之拒绝。

之因此叫乐观，由于这个模式没有从数据库加锁。

2. 悲观锁是读取的时候为后面的更新加锁，以后再来的读操做都会等待。这种是数据库锁

乐观锁优势程序实现，不会存在死锁等问题。他的适用场景也相对乐观。阻止不了除了程序以外的数据库操做。

悲观锁是数据库实现，他阻止一切数据库操做。

再来讲更新数据丢失，全部的读锁都是为了保持数据一致性。乐观锁若是有人在你以前更新了，你的更新应当是被拒绝的，可让用户重新操做。悲观锁则会等待前一个更新完成。这也是区别。具体业务具体分析

实现：

1、悲观锁
    一、排它锁，当事务在操做数据时把这部分数据进行锁定，直到操做完毕后再解锁，其余事务操做才可操做该部分数据。这将防止其余进程读取或修改表中的数据。

    二、实现：大多数状况下依靠数据库的锁机制实现

     通常使用 select ...for update 对所选择的数据进行加锁处理，例如select * from account where name=”Max” for update， 这条sql 语句锁定了account 表中全部符合检索条件（name=”Max”）的记录。本次事务提交以前（事务提交时会释放事务过程当中的锁），外界没法修改这些记录。

2、乐观锁
    一、若是有人在你以前更新了，你的更新应当是被拒绝的，可让用户从新操做。

    二、实现：大多数基于数据版本（Version）记录机制实现

     具体可经过给表加一个版本号或时间戳字段实现，当读取数据时，将version字段的值一同读出，数据每更新一次，对此version值加一。当咱们提交更新的时候，判断当前版本信息与第一次取出来的版本值大小，若是数据库表当前版本号与第一次取出来的version值相等，则予以更新，不然认为是过时数据，拒绝更新，让用户从新操做。

3、ORM框架中悲观锁乐观锁的应用

     通常悲观锁、乐观锁都须要都经过sql语句的设定、数据的设计结合代码来实现，例如乐观锁中的版本号字段，单纯面向数据库操做，是须要本身来实现乐观锁的，简言之，也就是版本号或时间戳字段的维护是程序本身维护的，自增、判断大小肯定是否更新都经过代码判断实现。数据库进提供了乐观、悲观两个思路进行并发控制。

     对于经常使用java 持久化框架，对于数据库的这一机制都有本身的实现，以Hibernate为例，总结一下ORM框架中悲观锁乐观锁的应用

一、Hibernate的悲观锁：

     基于数据库的锁机制实现。以下查询语句：

String hqlStr ="from TUser as user where user.name=Max";
Query query = session.createQuery(hqlStr);
query.setLockMode("user",LockMode.UPGRADE); //加锁
List userList = query.list();//执行查询，获取数据

     观察运行期Hibernate生成的SQL语句：

select tuser0_.id as id, tuser0_.name as name, tuser0_.group_id as group_id, tuser0_.user_type as user_type, tuser0_.sex as sex from t_user tuser0_ where (tuser0_.name='Erica' ) for update

     这里Hibernate经过使用数据库的for update子句实现了悲观锁机制。对返回的全部user记录进行加锁。
二、Hibernate的加锁模式有：
     Ø LockMode.NONE ： 无锁机制。
     Ø LockMode.WRITE ：Hibernate在写操做（Insert和Update）时会自动 获取写锁。
     Ø LockMode.READ ： Hibernate在读取记录的时候会自动获取。
     这三种锁机制通常由Hibernate内部使用，如Hibernate为了保证Update 过程当中对象不会被外界修改，会在save方法实现中自动为目标对象加上WRITE锁。
     Ø LockMode.UPGRADE ：利用数据库的for update子句加锁。
     Ø LockMode. UPGRADE_NOWAIT ：Oracle的特定实现，利用Oracle的for update nowait子句实现加锁。
     注意，只有在查询开始以前（也就是Hiberate 生成SQL 以前）设定加锁，才会 真正经过数据库的锁机制进行加锁处理，不然，数据已经经过不包含for update 子句的Select SQL加载进来，所谓数据库加锁也就无从谈起。

三、Hibernate的乐观锁

     Hibernate 在其数据访问引擎中内置了乐观锁实现。若是不用考虑外部系统对数据库的更新操做，利用Hibernate提供的透明化乐观锁实现，将大大提高咱们的生产力。Hibernate中能够经过class描述符的optimistic-lock属性结合version描述符指定。具体实现方式以下：
     如今，咱们为以前示例中的TUser加上乐观锁机制。
实现1、 配置optimistic-lock属性：

<hibernate-mapping>
     <class name="org.hibernate.sample.TUser" table="t_user" dynamic-update="true" dynamic-insert="true" optimistic-lock="version">
           ……
     </class>
</hibernate-mapping>

optimistic-lock属性有以下可选取值：
     Ø none： 无乐观锁
     Ø version： 经过版本机制实现乐观锁
     Ø dirty： 经过检查发生变更过的属性实现乐观锁
     Ø all： 经过检查全部属性实现乐观锁

     经过version实现的乐观锁机制是Hibernate官方推荐的乐观锁实现，同时也是Hibernate中，目前惟一在数据对象脱离Session发生修改的状况下依然有效的锁机制。所以，通常状况下，咱们都选择version方式做为Hibernate乐观锁实现机制。
实现2、添加一个Version属性描述符

<hibernate-mapping>
     <class name="org.hibernate.sample.TUser" table="t_user"   dynamic-update="true" dynamic-insert="true" optimistic-lock="version">
    <id name="id" column="id" type="java.lang.Integer">
        <generator class="native"/>
    </id>
    <version column="version" name="version" type="java.lang.Integer"/>
……
     </class>
</hibernate-mapping>

     注意version 节点必须出如今ID 节点以后。 这里声明了一个version属性，用于存放用户的版本信息，保存在TUser表的 version字段中。

测试：

     此时若是咱们尝试编写一段代码，更新TUser表中记录数据，如：

Criteria criteria = session.createCriteria(TUser.class);
criteria.add(Expression.eq("name","Max"));
List userList = criteria.list();
TUser user =(TUser)userList.get(0);
Transaction tx = session.beginTransaction();
user.setUserType(1); //更新UserType字段
tx.commit();

     每次对TUser进行更新的时候，咱们能够发现，数据库中的version都在递增。 而若是咱们尝试在tx.commit 以前，启动另一个Session，对名为Max的用 户进行操做，下面模拟并发更新时的状况：

Session session= getSession();
Criteria criteria = session.createCriteria(TUser.class);
criteria.add(Expression.eq("name","Max"));
Session session2 = getSession();
Criteria criteria2 = session2.createCriteria(TUser.class);
criteria2.add(Expression.eq("name","Max"));
List userList = criteria.list();
List userList2 = criteria2.list();TUser user =(TUser)userList.get(0);
TUser user2 =(TUser)userList2.get(0);
Transaction tx = session.beginTransaction();
Transaction tx2 = session2.beginTransaction();
user2.setUserType(99);
tx2.commit();
user.setUserType(1);
tx.commit();

     执行并发更新的代码，在tx.commit()处抛出StaleObjectStateException异 常，并指出版本检查失败，当前事务正在试图提交一个过时数据。经过捕捉这个异常，我 们就能够在乐观锁校验失败时进行相应处理。

     这就是hibernate实现悲观锁和乐观锁的主要方式。

4、总结

     悲观锁相对比较谨慎，设想现实状况应该很容易就发生冲突，因此我仍是独占数据资源吧。

     乐观锁就想得开并且很是聪明，应该是不会有什么冲突的，我对表使用一个时间戳或者版本号，每次读、更新操做都对这个字段进行比对，若是在我以前已经有人对数据进行更新了，那就让它更新，大不了我再读一次或者再更新一次。

     乐观锁的管理跟SVN管理代码版本的原理很像，若是在我提交代码以前用本地代码的版本号与服务器作对比，若是本地版本号小于服务器上最新版本号，则提交失败，产生冲突代码，让用户决定选择哪一个版本继续使用。
     在实际生产环境里边,若是并发量不大且不容许脏读，可使用悲观锁；但若是系统的并发很是大的话,悲观锁定会带来很是大的性能问题,因此咱们就要选择乐观锁定的方法        另外，Mysql在处理并发访问数据上，还有添加 读锁（共享锁）、写锁（排它锁），控制 锁粒度【表锁（table lock）、行级锁（row lock）】等实现，有兴趣能够继续研究。