乐观锁vs悲观锁

引言

为何须要锁（并发控制）

在并发的环境中，会存在多个用户同时更新同一条数据，这时就会产生冲突。

冲突结果：

• 丢失更新：一个事务的更新覆盖了其它事务的更新结果，就是所谓的更新丢失。
• 脏读：当一个事务读取其它完成一半事务的记录时，就会发生脏读取。

所以为了解决上述问题，引入了并发控制机制。

乐观锁(乐观并发控制)和悲观锁(悲观并发控制)是并发控制的主要手段， 其实不只关系型数据库中有乐观锁和悲观锁的概念，像redis，memcached等都有相似的概念。因此，不要把乐观锁和悲观锁狭隘的理解为DBMS中的概念，更不能把他们和数据库中提供的锁机制混为一谈。其实，在DBMS中悲观锁正是利用了数据库提供的锁机制实现的。 

所以咱们针对不一样的业务场景，应该选择不一样的并发控制方式。

1、悲观锁                                                                                                                         

悲观锁指的是外界对数据修改持保守态度(悲观)，所以，在整个数据处理过程当中，将数据处于锁定状态。 悲观锁的实现，每每依靠数据库提供的锁机制 （也只有数据库层提供的锁机制才能真正保证数据访问的排他性，不然，即便在本系统中实现了加锁机制，也没法保证外部系统不会修改数据）。 

DBMS悲观锁是阻止一个事务以影响其余用户的方式来修改数据。若是一个事务执行的操做 某行数据应用了锁，那只有当这个事务把锁释放，其余事务才可以执行与该锁冲突的操做。 

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

   

数据库中，悲观锁的流程： 

对任意记录进行修改前，先尝试为该记录加上排他锁（exclusive locking）。若是加锁失败，说明该记录正在被修改，那么当前查询可能要等待或者抛出异常。 具体响应方式由开发者根据实际须要决定。 若是成功加锁，那么就能够对记录作修改，事务完成后就会释放锁了。 其间若是有其余对该记录作修改或加排他锁的操做，都会等待咱们解锁或直接抛出异常。

   

使用悲观锁

要使用悲观锁，咱们必须关闭mysql数据库的自动提交属性，由于MySQL默认使用auto commit模式，也就是说，当你执行一个更新操做后，MySQL会马上将结果进行提交。set autocommit=0; 

//0.开始事务 

begin;/begin work;/start transaction; (三者选一就能够) 

//1.查询出商品信息 

select status from t_goods where id=1 for update; 

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

insert into t_orders (id,goods_id) values (null,1); 

//3.修改商品status为2 

update t_goods set status=2; 

//4.提交事务 

commit;/commit work;

   

上面的查询语句中，咱们使用了select…for update的方式， 这样就经过开启排他锁的方式实现了悲观锁。此时在t_goods表中，id为1的 那条数据就被咱们锁定了，其它的事务必须等本次事务提交以后才能执行。这样咱们能够保证当前的数据不会被其它事务修改。

注意点  

咱们须要注意一些锁的级别，MySQL InnoDB默认行级锁。 行级锁都是基于索引的，若是一条SQL语句用不到索引是不会使用行级锁的，会使用表级锁把整张表锁住。上面咱们使用select…for update会把数据给锁住（id上有主键索引)，所以不会使用表级锁。

若是查询语句中有表关联，只是用for update会锁住全部表的相关记录，建议使用for update of t.id。若是你不想让你的事务等待其余事务的锁，能够在for update 后加上 nowait，这样当赶上冲突时数据库会抛出异常。

优点劣势

悲观并发控制其实是"先取锁再访问"的保守策略，为数据处理的安全提供了保证。可是在效率方面，处理加锁的机制会让数据库产生额外的开销，还有增长产生死锁的机会；另外，在只读型事务处理中因为不会产生冲突，也不必使用锁，这样作只能增长系统负载；还有会下降了并行性，一个事务若是锁定了某行数据，其余事务就必须等待该事务处理完才能够处理那行数。

   

2、乐观锁                                                                                                                        

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

相对于悲观锁，在对数据库进行处理的时候，乐观锁并不会使用数据库提供的锁机制。通常的实现乐观锁的方式就是记录数据版本。

实现数据版本有两种方式：

第一种是使用版本号version，

第二种是使用时间戳timestamp（时间戳精度）。 

数据版本,为数据增长的一个版本标识。当读取数据时，将版本标识的值一同读出，数据每更新一次，同时对版本标识进行更新。当咱们提交更新的时候，判断数据库表对应记录的当前版本信息与第一次取出来的版本标识进行比对，若是数据库表当前版本号与第一次取出来的版本标识值相等，则予以更新，不然认为是过时数据。 

DBMS会假设多用户并发的事务在处理时不会彼此互相影响，各事务可以在不产生锁的状况下处理各自影响的那部分数据。在提交数据更新以前，每一个事务会先检查在该事务读取数据后，有没有其余事务又修改了该数据（修改该数据的事务已提交，或未提交；事务未提交会带来数据丢失）。若是其余事务有更新的话，正在提交的事务会进行回滚。

注：对于以上两种方式,Hibernate自带实现方式：在使用乐观锁的字段前加annotation: @Version, Hibernate在更新时自动校验该字段。

使用版本号实现乐观锁

使用版本号时，能够在数据初始化时指定一个版本号，每次对数据的更新操做都对版本号执行+1操做。并判断当前版本号是否是该数据的最新的版本号。 

//1.查询出商品信息 

select 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};

 

注意第二个事务执行update时，第一个事务已经提交了，因此第二个事务可以读取到第一个事务修改的version。

下面这种极端的状况：

咱们知道MySQL数据库引擎InnoDB，事务的隔离级别是Repeatable Read，所以是不会出现脏读、不可重复读。

在这种极端状况下，第二个事务的update因为不能读取第一个事务未提交的数据（第一个事务已经对这一条数据加了排他锁，第二个事务须要等待获取锁），第二个事务获取了排他锁后，会发现version已经发生了改变从而提交失败。  

优点劣势

乐观并发控制相信事务之间的数据竞争(datarace)的几率是比较小的， 所以尽量直接作下去，直到提交的时候才去锁定，因此不会产生任何锁和死锁。

乐观锁虽然没有依赖数据库提供的锁机制，也能够保证数据一致性。