乐观锁与悲观锁

悲观锁: 简称PCC

运用环境:主要用于数据争用激烈的环境，以及发生并发冲突时使用锁保护数据的成本要低于回滚事务的成本的环境中。

运用实例:主要运用数据库自带的锁机制,进行悲观锁。

例子：

<select id="selectByBaseidForUpdate" resultType="com.ganjiangps.huochetou.model.UserAccount">
select u.* from user_account u where u.baseid=#{id} for update

</select>

悲观锁的有点和不足：

悲观并发控制实际上是“先取锁再访问”的保守策略，为数据处理的安全提供了保证。但是在效率方面，处理加锁的机制会让数据库产生额外的开销，还有增加产生死锁的机会；另外，在只读型事务处理中由于不会产生冲突，也没必要使用锁，这样做只能增加系统负载；还有会降低了并行性，一个事务如果锁定了某行数据，其他事务就必须等待该事务处理完才可以处理那行数。

乐观锁:简称OCC

运用环境:它假设多用户并发的事务在处理时不会彼此互相影响，各事务能够在不产生锁的情况下处理各自影响的那部分数据。在提交数据更新之前，每个事务会先检查在该事务读取数据后，有没有其他事务又修改了该数据。如果其他事务有更新的话，正在提交的事务会进行回滚。

运用实例:乐观锁并不会使用数据库提供的锁机制。一般的实现乐观锁的方式就是记录数据版本。

乐观锁的实现有两种方式,但都异曲同工;

1、使用数据版本（Version）记录机制实现，这是乐观锁最常用的一种实现方式。何谓数据版本？即为数据增加一个版本标识，一般是通过为数据库表增加一个数字类型的 “version” 字段来实现。当读取数据时，将version字段的值一同读出，数据每更新一次，对此version值加一。当我们提交更新的时候，判断数据库表对应记录的当前版本信息与第一次取出来的version值进行比对，如果数据库表当前版本号与第一次取出来的version值相等，则予以更新，否则认为是过期数据。用下面的一张图来说明：乐观锁与悲观锁

如上图所示，如果更新操作顺序执行，则数据的版本（version）依次递增，不会产生冲突。但是如果发生有不同的业务操作对同一版本的数据进行修改，那么，先提交的操作（图中B）会把数据version更新为2，当A在B之后提交更新时发现数据的version已经被修改了，那么A的更新操作会失败。

2、乐观锁定的第二种实现方式和第一种差不多，同样是在需要乐观锁控制的table中增加一个字段，名称无所谓，字段类型使用时间戳（timestamp）, 和上面的version类似，也是在更新提交的时候检查当前数据库中数据的时间戳和自己更新前取到的时间戳进行对比，如果一致则OK，否则就是版本冲突。

乐观锁应用举例：

下单操作包括3步骤：

1.查询出商品信息

select (status,status,version) from t_goods where id=#{id}

2.根据商品信息生成订单

3.修改商品status为2

update t_goods 

set status=2,version=version+1

where id=#{id} and version=#{version};

　　那么为了使用乐观锁，我们首先修改t_goods表，增加一个version字段，数据默认version值为1。

　　t_goods表初始数据如下：

　　对于乐观锁的实现，我使用MyBatis来进行实践，具体如下：

Goods实体类：

/**
 * ClassName: Goods <br/>
 * Function: 商品实体. <br/>*/
public class Goods implements Serializable {

    /**
     * serialVersionUID:序列化ID.
     */
    private static final long serialVersionUID = 6803791908148880587L;
    
    /**
     * id:主键id.
     */
    private int id;
    
    /**
     * status:商品状态：1未下单、2已下单.
     */
    private int status;
    
    /**
     * name:商品名称.
     */
    private String name;
    
    /**
     * version:商品数据版本号.
     */
    private int version;
    
    @Override
    public String toString(){
        return "good id:"+id+",goods status:"+status+",goods name:"+name+",goods version:"+version;
    }

    //setter and getter

}

GoodsDao

/**
 * updateGoodsUseCAS:使用CAS(Compare and set)更新商品信息

 * @param goods 商品对象
 * @return 影响的行数
 */
int updateGoodsUseCAS(Goods goods);

mapper.xml

<update id="updateGoodsUseCAS" parameterType="Goods">
    <![CDATA[
        update t_goods
        set status=#{status},name=#{name},version=version+1
        where id=#{id} and version=#{version}
    ]]>
</update>

GoodsDaoTest测试类

@Test
public void goodsDaoTest(){
    int goodsId = 1;
    //根据相同的id查询出商品信息，赋给2个对象
    Goods goods1 = this.goodsDao.getGoodsById(goodsId);
    Goods goods2 = this.goodsDao.getGoodsById(goodsId);
    
    //打印当前商品信息
    System.out.println(goods1);
    System.out.println(goods2);
    
    //更新商品信息1
    goods1.setStatus(2);//修改status为2
    int updateResult1 = this.goodsDao.updateGoodsUseCAS(goods1);
    System.out.println("修改商品信息1"+(updateResult1==1?"成功":"失败"));
    
    //更新商品信息2
    goods2.setStatus(2);//修改status为2
    int updateResult2 = this.goodsDao.updateGoodsUseCAS(goods2);
    System.out.println("修改商品信息2"+(updateResult2==1?"成功":"失败"));
}

输出结果：

good id:1,goods status:1,goods name:道具,goods version:1  
good id:1,goods status:1,goods name:道具,goods version:1  
修改商品信息1成功  
修改商品信息2失败

说明：

　　在GoodsDaoTest测试方法中，我们同时查出同一个版本的数据，赋给不同的goods对象，然后先修改good1对象然后执行更新操作，执行成功。然后我们修改goods2，执行更新操作时提示操作失败。此时t_goods表中数据如下：

mysql> select * from t_goods;
+----+--------+------+---------+
| id | status | name | version |
+----+--------+------+---------+
|  1 |      2 | 道具 |       2 |
|  2 |      2 | 装备 |       2 |
+----+--------+------+---------+
2 rows in set

mysql>

　　我们可以看到 id为1的数据version已经在第一次更新时修改为2了。所以我们更新good2时update where条件已经不匹配了，所以更新不会成功，具体sql如下：

update t_goods 
set status=2,version=version+1
where id=#{id} and version=#{version};

　　这样我们就实现了乐观锁

相关推荐