悲观锁与乐观锁是人们定义出来的概念，你可以理解为一种思想，是处理并发资源的常用手段。其与mysql中提供的锁机制(表锁，行锁，排他锁，共享锁)并不同，后者可以成为前者的实现手段。

悲观锁

顾名思义，就是对于数据的处理持悲观态度，总认为会发生并发冲突，获取和修改数据时，别人会修改数据。所以在整个数据处理过程中，需要将数据锁定。悲观锁的实现，通常依靠数据库提供的锁机制实现，比如mysql的排他锁，for update来实现悲观锁。

例子：商品秒杀过程中，库存数量的减少$num，避免出现超卖的情况。

CREATE TABLE `tb_goods_stock` (
  `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT COMMENT 'ID',
  `goods_id` bigint(20) unsigned DEFAULT '0' COMMENT '商品ID',
  `nums` int(11) unsigned DEFAULT '0' COMMENT '商品库存数量',
  `create_time` datetime DEFAULT NULL COMMENT '创建时间',
  `modify_time` datetime DEFAULT NULL COMMENT '更新时间',
  PRIMARY KEY (`id`),
  UNIQUE KEY `goods_id` (`goods_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='商品库存表';

将商品库存数量nums字段类型设为unsigned，保证在数据库层面不会发生负数的情况。

注意，使用悲观锁，需要关闭mysql的自动提交功能，将 set autocommit = 0;

注意，mysql中的行级锁是基于索引的，如果sql没有走索引，那将使用表级锁把整张表锁住。

# 开启事务，查询要卖的商品，并对该记录加锁。
begin;
select nums from tb_goods_stock where goods_id = {$goods_id} for update;

# 判断商品数量是否大于购买数量。如果不满足，就回滚事务。

# 如果满足条件，生成订单，减少库存，并提交事务。
insert into ----

update tb_goods_stock set nums = nums - {$num} where goods_id = {$goods_id} and nums >= {$num};

commit;

悲观锁在并发控制上采取的是先上锁然后再处理数据的保守策略，虽然保证了数据处理的独占性，但也降低了效率，尤其是for update查询的时候会锁定所有扫描的行（该列信息上没有索引，则锁定全表），这种情况在高并发情况下绝对是不能接受的。

乐观锁

乐观锁相对悲观锁而言，就是对数据的处理持乐观态度，它认为数据一般情况下不会造成冲突，所以在数据进行提交更新的时候，才会正式对数据的冲突与否进行检测，一般是利用版本号来操作。如果发现冲突了，则返回错误信息，让用户决定如何去做。接下来我们看一下乐观锁在数据表和缓存中的实现。

CREATE TABLE `tb_goods_stock` (
  `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT COMMENT 'ID',
  `goods_id` bigint(20) unsigned DEFAULT '0' COMMENT '商品ID',
  `nums` int(11) unsigned DEFAULT '0' COMMENT '商品库存数量',
  `create_time` datetime DEFAULT NULL COMMENT '创建时间',
  `modify_time` datetime DEFAULT NULL COMMENT '更新时间',
  `version` bigint(20) unsigned DEFAULT '0' COMMENT '版本号',
  PRIMARY KEY (`id`),
  UNIQUE KEY `goods_id` (`goods_id`)
) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=utf8mb4 COMMENT='商品库存表';

进行如下操作

begin;
#1.判断库存是否够用，但是这里只是为了看是不是有库存，如果没有将会尽快返回错误，但是不决定最终是否成功
select nums, version from tb_goods_stock where goods_id = {$goods_id};

#2.生成订单
insert into ----

#3.如果满足条件，则减少库存。(更新时判断当前version与第1步中获取的version是否相同)

update tb_goods_stock set nums = nums - {$num}, version = version + 1 where goods_id = {$goods_id} and version = {$version} and nums >= {$num};


#4.判断更新操作是否成功执行，如果成功，则提交，否则就回滚。

乐观锁适用于读多的应用场景。但是对于版本号这种情况，如果并发量起来了，将会经常发生冲突，上层应用不断的让用户进行重新操作，这反而降低了性能，对于库存的情况还有另一种方案来解决

begin;
select (inventory) from items where id=100;
#1.判断库存是否够用，但是这里只是为了看是不是有库存，如果没有将会尽快返回错误，但是不决定最终是否成功

#2.如果上面判断库存还有，生成订单
insert into ----

#3.如果满足条件，则减少库存。(更新时判断库存是否大于当前库存，不在加入版本号)

update tb_goods_stock set nums = nums - {$num} where goods_id = {$goods_id} and nums >= {$num};


#4.判断更新操作是否成功执行，如果成功，则提交，否则就回滚。

这种情况下就基本解决的并发时候的问题。

注意：在更新数据的时候不要用预先计算出库存再更新数值的方式，一定要把计算和更新写在一条语句中变成原子操作。