乐观锁与悲观锁——解决并发问题

引言

为何须要锁（并发控制）？

　　在多用户环境中，在同一时间可能会有多个用户更新相同的记录，这会产生冲突。这就是著名的并发性问题。

典型的冲突有：

• 丢失更新：一个事务的更新覆盖了其它事务的更新结果，就是所谓的更新丢失。例如：用户A把值从6改成2，用户B把值从2改成6，则用户A丢失了他的更新。
• 脏读：当一个事务读取其它完成一半事务的记录时，就会发生脏读取。例如：用户A,B看到的值都是6，用户B把值改成2，用户A读到的值仍为6。

为了解决这些并发带来的问题。 咱们须要引入并发控制机制。

并发控制机制

　　悲观锁：假定会发生并发冲突，屏蔽一切可能违反数据完整性的操做。[1]

　　乐观锁：假设不会发生并发冲突，只在提交操做时检查是否违反数据完整性。[1] 乐观锁不能解决脏读的问题。

 

乐观锁应用

乐观锁介绍：

　　乐观锁（ Optimistic Locking ） 相对悲观锁而言，乐观锁假设认为数据通常状况下不会形成冲突，因此在数据进行提交更新的时候，才会正式对数据的冲突与否进行检测，若是发现冲突了，则让返回用户错误的信息，让用户决定如何去作。那么咱们如何实现乐观锁呢，通常来讲有如下2种方式：

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

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

 

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

 

使用举例：以MySQL InnoDB为例

仍是拿以前的实例来举：商品goods表中有一个字段status，status为1表明商品未被下单，status为2表明商品已经被下单，那么咱们对某个商品下单时必须确保该商品status为1。假设商品的id为1。

 

下单操做包括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表初始数据以下：

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

mysql>

 

　　对于乐观锁的实现，我使用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
    goods1.setStatus(2);//修改status为2
    int updateResult2 = this.goodsDao.updateGoodsUseCAS(goods1);
    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};

　　这样咱们就实现了乐观锁

 

悲观锁应用

须要使用数据库的锁机制，好比SQL SERVER 的TABLOCKX（排它表锁） 此选项被选中时，SQL  Server  将在整个表上置排它锁直至该命令或事务结束。这将防止其余进程读取或修改表中的数据。

SqlServer中使用

Begin Tran
select top 1 @TrainNo=T_NO
         from Train_ticket   with (UPDLOCK)   where S_Flag=0

      update Train_ticket
         set T_Name=user,
             T_Time=getdate(),
             S_Flag=1
         where T_NO=@TrainNo
commit

咱们在查询的时候使用了with (UPDLOCK)选项,在查询记录的时候咱们就对记录加上了更新锁,表示咱们即将对此记录进行更新. 注意更新锁和共享锁是不冲突的,也就是其余用户还能够查询此表的内容,可是和更新锁和排它锁是冲突的.因此其余的更新用户就会阻塞.

结论

　　在实际生产环境里边,若是并发量不大且不容许脏读，可使用悲观锁解决并发问题；但若是系统的并发很是大的话,悲观锁定会带来很是大的性能问题,因此咱们就要选择乐观锁定的方法.

 

 　　 致谢：感谢您的耐心阅读！