本文共 4089 字，大约阅读时间需要 13 分钟。

一、并发控制

当程序中可能出现并发的情况时，就需要通过一定的手段来保证在并发情况下数据的准确性，通过这种手段保证了当前用户和其他用户一起操作时，所得到的结果和他单独操作时的结果是一样的。这种手段就叫做并发控制。并发控制的目的是保证一个用户的工作不会对另一个用户的工作产生不合理的影响。

没有做好并发控制，就可能导致脏读、幻读和不可重复读等问题。

常说的并发控制，一般都和数据库管理系统（DBMS）有关。在DBMS中的并发控制的任务，是确保在多个事务同时存取数据库中同一数据时，不破坏事务的隔离性和统一性以及数据库的统一性。

实现并发控制的主要手段大致可以分为乐观并发控制和悲观并发控制两种。

首先要明确：无论是悲观锁还是乐观锁，都是人们定义出来的概念，可以认为是一种思想。其实不仅仅是关系型数据库系统中有乐观锁和悲观锁的概念，像hibernate、tair、memcache等都有类似的概念。所以，不应该拿乐观锁、悲观锁和其他的数据库锁等进行对比。

二、悲观锁(Pessimistic Lock)

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

百度百科：

悲观锁，正如其名，具有强烈的独占和排他特性。它指的是对数据被外界(包括本系统当前的其他事务，以及来自外部系统的事务处理)修改持保守态度。因此，在整个数据处理过程中，将数据处于锁定状态。悲观锁的实现，往往依靠数据库提供的锁机制(也只有数据库层提供的锁机制才能真正保证数据访问的排他性，否则，即使在本系统中实现了加锁机制，也无法保证外部系统不会修改数据)。

之所以叫做悲观锁，是因为这是一种对数据的修改抱有悲观态度的并发控制方式。我们一般认为数据被并发修改的概率比较大，所以需要在修改之前先加锁。

悲观锁主要分为共享锁或排他锁

共享锁【Shared lock】又称为读锁，简称S锁。顾名思义，共享锁就是多个事务对于同一数据可以共享一把锁，都能访问到数据，但是只能读不能修改。

排他锁【Exclusive lock】又称为写锁，简称X锁。顾名思义，排他锁就是不能与其他锁并存，如果一个事务获取了一个数据行的排他锁，其他事务就不能再获取该行的其他锁，包括共享锁和排他锁，但是获取排他锁的事务是可以对数据行读取和修改。

悲观并发控制实际上是“先取锁再访问”的保守策略，为数据处理的安全提供了保证。 但是在效率方面，处理加锁的机制会让数据库产生额外的开销，还有增加产生死锁的机会。另外还会降低并行性，一个事务如果锁定了某行数据，其他事务就必须等待该事务处理完才可以处理那行数据。

三、乐观锁(Optimistic Locking)

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

百度百科：

乐观锁机制采取了更加宽松的加锁机制。乐观锁是相对悲观锁而言，也是为了避免数据库幻读、业务处理时间过长等原因引起数据处理错误的一种机制，但乐观锁不会刻意使用数据库本身的锁机制，而是依据数据本身来保证数据的正确性。

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

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

四、实现方式

1、悲观锁实现方式

悲观锁的实现，通常依靠数据库提供的锁机制实现，比如mysql的排他锁，select … 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 '更新时间',  PRIMARY KEY (`id`),  UNIQUE KEY `goods_id` (`goods_id`)) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='商品库存表';

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

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

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

1、开启事务，查询要卖的商品，并对该记录加锁。

begin;select nums from tb_goods_stock where goods_id = {$goods_id} for update;

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

3、如果满足条件，则减少库存，并提交事务。

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

事务提交时会释放事务过程中的锁。

悲观锁在并发控制上采取的是先上锁然后再处理数据的保守策略，虽然保证了数据处理的安全性，但也降低了效率

2、乐观锁实现方式

乐观锁的实现不依靠数据库提供的锁机制，需要我们自已实现，实现方式一般是记录数据版本，一种是通过版本号，一种是通过时间戳。

给表加一个版本号或时间戳的字段，读取数据时，将版本号一同读出，数据更新时，将版本号加1。

当我们提交数据更新时，判断当前的版本号与第一次读取出来的版本号是否相等。如果相等，则予以更新，否则认为数据过期，拒绝更新，让用户重新操作。

例子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+1where id=#{id} and version=#{version};

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

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='商品库存表';

1、查询要卖的商品，并获取版本号。

begin;select nums, version from tb_goods_stock where goods_id = {$goods_id};

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

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、判断更新操作是否成功执行，如果成功，则提交，否则就回滚。

乐观锁是基于程序实现的，所以不存在死锁的情况，适用于读多的应用场景。如果经常发生冲突，上层应用不断的让用户进行重新操作，这反而降低了性能，这种情况下悲观锁就比较适用。

五、如何选择

在乐观锁与悲观锁的选择上面，主要看下两者的区别以及适用场景就可以了。

乐观锁并未真正加锁，效率高。一旦锁的粒度掌握不好，更新失败的概率就会比较高，容易发生业务失败。

悲观锁依赖数据库锁，效率低。更新失败的概率比较低。 随着互联网三高架构（高并发、高性能、高可用）的提出，悲观锁已经越来越少的被应用到生产环境中了，尤其是并发量比较大的业务场景。

转载地址：http://swamb.baihongyu.com/