乐观锁与悲观锁 理解

悲观锁

当我们要对一个数据库中的一条数据进行修改的时候，为了避免同时被其他人修改，最好的办法就是直接对该数据进行加锁以防止并发，这种借助数据库锁机制在修改数据之前先锁定，再修改的方式被称之为悲观并发控制。

悲观锁，它指的是对数据被外界（包括本系统当前的其他事务，以及来自外部系统的事务处理）修改持保守态度(悲观)，因此，在整个数据处理过程中，将数据处于锁定状态。 悲观锁的实现，往往依靠数据库提供的锁机制 。

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

数据库中，悲观锁的流程如下
•在对任何记录进行修改之前，先尝试为该记录加上排他锁
•如果加锁失败，说明该记录正在被修改，那么当前查询可能要等待或抛出异常
•如果成功加锁，则就可以对记录做修改，事务完成后就会解锁
•其间如果有其他对该记录做修改或加排他锁的操作，都会等待我们解锁或直接抛出异常

悲观锁的使用

//开始事务
begin;
select status from t_goods where id=1 for update;
//根据商品信息生成订单
insert into t_orders (id,goods_id) values (null,1);
//修改商品status为2
update t_goods set status=2;
// 提交事务
commit；

以上查询语句中，使用了select…for update方式，通过开启排他锁的方式实现了悲观锁。则相应的记录被锁定，其他事务必须等本次事务提交之后才能够执行

我们使用select … for update会把数据给锁定，不过我们需要注意一些锁的级别，MySQL InnoDB默认行级锁。行级锁都是基于索引的，如果一条SQL用不到索引是不会使用行级锁的，会使用表级锁把整张表锁住。

注意：在不通过索引条件查询的时候，InnoDB使用的是表锁，而不是行锁。这点需要特别注意

特点

为数据处理的安全提供了保证
效率上，由于处理加锁的机制会让数据库产生额外开销，增加产生死锁机会
在只读型事务中由于不会产生冲突，也没必要使用锁，这样会增加系统负载，降低并行性

乐观锁

乐观锁相对悲观锁而言，它认为数据一般情况下不会造成冲突，所以在数据进行提交更新的时候，才会正式对数据的冲突与否进行检测，如果发现冲突了，则让返回错误信息，让用户决定如何去做。

利用数据版本号（version）机制是乐观锁最常用的一种实现方式。一般通过为数据库表增加一个数字类型的 “version” 字段，当读取数据时，将version字段的值一同读出，数据每更新一次，对此version值+1。当我们提交更新的时候，判断数据库表对应记录的当前版本信息与第一次取出来的version值进行比对，如果数据库表当前版本号与第一次取出来的version值相等，则予以更新，否则认为是过期数据，返回更新失败。

既然可以用version，那还可以使用时间戳字段，该方法同样是在表中增加一个时间戳字段，和上面的version类似，也是在更新提交的时候检查当前数据库中数据的时间戳和自己更新前取到的时间戳进行对比，如果一致则OK，否则就是版本冲突。

// 仍挑选以库存数作为乐观锁
//step1: 查询出商品信息
select (inventory) from items where id=100;
//step2: 根据商品信息生成订单
insert into orders(id,item_id) values(null,100);
//step3: 修改商品的库存
update items set inventory=inventory-1 where id=100 and inventory-1>0;

区分及场景

乐观锁：
读多写少的场景，如果出现大量的写入操作，数据发生冲突的可能性就会增大，为了保证数据的一致性，应用层需要不断的重新获取数据，这样会增加大量的查询操作，降低了系统的吞吐量。 比如 ：秒杀活动

悲观锁：
　　比较适合写入操作比较频繁的场景，如果出现大量的读取操作，每次读取的时候都会进行加锁，这样会增加大量的锁的开销，降低了系统的吞吐量。 比如 ：下单操作

乐观锁：
　　乐观锁的特点先进行业务操作，不到万不得已不去拿锁。即“乐观”的认为拿锁多半是会成功的，因此在进行完业务操作需要实际更新数据的最后一步再去拿一下锁就好。
悲观锁：
　　悲观锁的特点是先获取锁，再进行业务操作，即“悲观”的认为获取锁是非常有可能失败的，因此要先确保获取锁成功再进行业务操作。通常所说的“一锁二查三更新”即指的是使用悲观锁。

文章拜读了：https://www.jianshu.com/p/ed896335b3b4 请参考