一、并发控制
当程序中可能出现并发的情况时，就需要保证在并发情况下数据的准确性，以此确保当前用户和其他用户一起操作时，所得到的结果和他单独操作时的结果是一样的。这就叫做并发控制。并发控制的目的是保证一个用户的工作不会对另一个用户的工作产生不合理的影响。
没有做好并发控制，就可能导致脏读、幻读和不可重复读等问题。
实现并发控制的主要手段分为乐观并发控制和悲观并发控制两种。
无论是悲观锁还是乐观锁，都是人们定义出来的概念，可以认为是一种思想。乐观锁比较适用于读多写少的情况（多读场景），悲观锁比较适用于写多读少的情况（多写场景）。
二、案例说明
银行两操作员（甲/乙）同时操作同一账户。两人同时读取一余额为 1000 元的账户，甲为该账户增加 100 元，乙同时为该账户扣除 50 元，甲先提交，乙后提交。最后实际账户余额为 1000-50=950，但本该为 1000+100-50=1050。这就是典型的并发问题。
解释造成这样的原因：
甲和乙同时读取余额为1000，甲先增加100元，更新余额为1100，甲先提交。此时乙读取的余额还是原来的1000，乙扣除50元，更新余额为950，最后实际账户余额显示950。
三、悲观锁（Pessimistic lock）
1、理解
当要对数据库中的一条数据进行修改的时候，为了避免同时被其他人修改，最好的办法就是直接对该数据进行加锁以防止并发。这种借助数据库锁机制，在修改数据之前先锁定，再修改的方式被称之为悲观并发控制【Pessimistic Concurrency Control，缩写"PCC"，又名"悲观锁"】。
悲观锁，具有强烈的独占和排它特性。它指的是对数据被外界（包括本系统当前的其他事务，以及来自外部系统的事务处理）修改持保守态度。因此，在整个数据处理过程中，将数据处于锁定状态。悲观锁的实现，往往依靠数据库提供的锁机制（也只有数据库层提供的锁机制才能真正保证数据访问的排他性，否则，即使在本系统中实现了加锁机制，也无法保证外部系统不会修改数据）。
之所以叫做悲观锁，是因为这是一种对数据的修改持有悲观态度的并发控制方式。总是假设最坏的情况，每次读取数据的时候都默认其他线程会更改数据，因此需要进行加锁操作，当其他线程想要访问数据时，都需要阻塞挂起。悲观锁的实现：
- 传统的关系型数据库使用这种锁机制，比如行锁、表锁、读锁、写锁等，都是在操作之前先上锁。
- Java 里面的同步 synchorized 关键字的实现。
2、悲观锁主要分为共享锁和排他锁
- 共享锁【shared locks】又称为读锁，简称 S 锁。顾名思义，共享锁就是多个事务对于同一数据可以共享一把锁，都能访问到数据，但是只能读不能修改。
- 排他锁【exclusive locks】又称为写锁，简称 X 锁。顾名思义，排他锁就是不能与其他锁并存，如果一个事务获取了一个数据行的排他锁，其他事务就不能再获取该行的其他锁，包括共享锁和排他锁。获取排他锁的事务可以对数据行读取和修改。
3、说明
悲观并发控制实际上是"先取锁再访问"的保守策略，为数据处理的安全提供了保证。但是在效率方面，处理加锁的机制会让数据库产生额外的开销，还有增加产生死锁的机会。另外还会降低并行性，一个事务如果锁定了某行数据，其他事务就必须等待该事务处理完才可以处理那行数据。
四、乐观锁（Optimistic lock）
1、理解
乐观锁是相对悲观锁而言的，乐观锁假设数据一般情况不会造成冲突，所以在数据进行提交更新的时候，才会正式对数据的冲突与否进行检测，如果冲突，则返回给用户异常信息，让用户决定如何去做。乐观锁适用于读多写少的场景，这样可以提高程序的吞吐量。
乐观锁采取了更加宽松的加锁机制。也是为了避免数据库幻读、业务处理时间过长等原因引起数据处理错误的一种机制，但乐观锁不会刻意使用数据库本身的锁机制，而是依据数据本身来保证数据的正确性。乐观锁的实现：
- CAS 实现：Java 中java.util.concurrent.atomic包下面的原子变量使用了乐观锁的一种 CAS 实现方式。
- 版本号控制：一般是在数据表中加上一个数据版本号 version 字段，表示数据被修改的次数。当数据被修改时，version 值会 +1。当线程 A 要更新数据时，在读取数据的同时也会读取 version 值，在提交更新时，若刚才读取到的 version 值与当前数据库中的 version 值相等时才更新，否则重试更新操作，直到更新成功。
2、说明
乐观并发控制相信事务之间的数据竞争(data race)的概率是比较小的，因此尽可能直接做下去，直到提交的时候才去锁定，所以不会产生任何锁和死锁。
五、具体实现
1、悲观锁实现方式
悲观锁的实现，往往依靠数据数据库提供的锁机制。在数据库中，悲观锁的流程如下：
- 在对记录进行修改前，先尝试为该记录加上排他锁(exclusive locks)。
- 如果加锁失败，说明该记录正在被修改，那么当前查询可能要等待或者抛出异常。具体响应方式由开发者根据实际需要决定。
- 如果成功加锁，那么就可以对记录做修改，事务完成后就会解锁了。
- 期间如果有其他对该记录做修改或加排他锁的操作，都会等待解锁或直接抛出异常。
以 MySql Innodb 引擎举例，说明 SQL 中悲观锁的应用
要使用悲观锁，必须关闭 MySql 数据库的自动提交属性 set autocommit = 0。因为 MySql 默认使用 autocommit 模式，也就是说，当执行一个更新操作后，MySQL 会立刻将结果进行提交。
以电商下单扣减库存的过程说明一下悲观锁的使用：
sql
// 0、开始事务
begin
// 1、查询出商品库存信息
select quantity from items where id = 1 for update;
// 2、修改库存商品为2
update items set quantity = 2 where id = 1
// 3、提交事务
commit在对 id = 1 的记录修改前，先通过 for update 的方式进行加锁，然后再进行修改。这就是比较典型的悲观锁策略。
如果发生并发，同一时间只有一个线程可以开启事务并获得 id=1 的锁，其它的事务必须等本次事务提交之后才能执行。这样可以保证当前的数据不会被其它事务修改。
使用 select ... for update 锁数据，需要注意锁的级别，MySQL InnoDB 默认行级锁。行级锁都是基于索引的，如果一条 SQL 语句用不到索引是不会使用行级锁的，会使用表级锁把整张表锁住，这点需要注意。
2、乐观锁实现方式 （乐观锁不需要借助数据库的锁机制）
当要更新一条记录的时候，希望这条记录没有被别人更新
乐观锁实现方式：
- 取出记录时，获取当前 version
- 更新时，带上这个 version
- 执行更新时， set version = newVersion where version = oldVersion
- 如果 version 不对，就更新失败
主要就是两个步骤：冲突检测和数据更新。
比如前面的扣减库存问题，通过乐观锁可以实现如下：
sql
// 1、查询出商品库存信息，quantity = 3
select quantity from items where id = 1;
// 2、修改商品库存为 2
update items set quantity = 2 where id = 1 and quantity = 3在更新之前，先查询一下库存表中当前库存数(quantity)，然后在做 update 的时候，以库存数作为一个修改条件。当提交更新的时候，判断数据库表对应记录的当前库存数与第一次取出来的库存数进行比对，如果数据库表当前库存数与第一次取出来的库存数相等，则予以更新，否则认为是过期数据。
以上更新语句存在一个比较严重的问题，即 ABA 问题：
- 比如说线程1从数据库取出库存数为3，这时候线程2也从数据库中取出库存数3，并且线程2进行了一些操作变成了2。
- 然后线程2又将库存数变成3，这时候线程1进行CAS操作发现数据库中仍然是3，然后线程1操作成功。
- 尽管线程1 的CAS 操作成功，但是不代表这个过程就是没有问题的。
一个比较好的解决办法，就是通过一个单独的可以顺序递增的 version 字段。优化如下：
乐观锁每次在执行数据修改操作时，都会带上一个版本号，一旦版本号和数据的版本号一致就可以执行修改操作并对版本号执行 +1 操作，否则就执行失败。因为每次操作的版本号都会随之增加，所以不会出现 ABA 问题。除了 version 以外，还可以使用时间戳，因为时间戳天然具有顺序递增性。
以上 SQL 其实还是有一定的问题的，就是一旦遇上高并发的时候，就只有一个线程可以修改成功，那么就会存在大量的失败。对于像淘宝这样的电商网站，高并发是常有的事，总让用户感知到失败显然是不合理的。所以，还是要想办法减少乐观锁的粒度。一个比较好的建议，就是减小乐观锁力度，最大程度的提升吞吐率，提高并发能力！如下：
sql
// 修改商品库存
update items set quantity = quantity - 1 where id = 1 and quantity -1 > 0以上 SQL 语句中，如果用户下单数为 1，则通过 quantity -1 > 0 的方式进行乐观锁控制。在执行过程中，会在一次原子操作中查询一遍 quantity 的值，并将其扣减掉 1。
高并发环境下锁粒度把控是一门重要的学问。选择一个好的锁，在保证数据安全的情况下，可以大大提升吞吐率，进而提升性能。