1.1、定义

锁是计算机协调多个进程或线程并发访问某一资源的机制。
在数据库中，除传统的计算资源（如CPU、RAM、I/O等）的争用以外，数据也是一种供许多用户共享的资源。如何保证资源并发访问的一致性、有效性是所有数据库必须解决的一个问题，锁冲突也是影响数据库并发访问性能的一个重要因素。从这个角度来说，锁对数据库而言显得尤其重要，也更加复杂。

1.2、锁的分类

1. 从对数据操作的类型（读/写分）

读锁（共享锁）：针对同一份数据，多个读操作可以同时进行而不会互相影响。
写锁（排它锁）：当前写操作没有完成前，它会阻断其它写锁和读锁。

2. 从对数据操作的粒度分

表锁
行锁

1.3、表锁（偏读）

特点：偏向MyISAM存储引擎，开销小，加锁快；无死锁；锁定粒度大，发生锁冲突的概率最高，并发度最低。

1.3.1、案例一（加读锁）

1. 建表和插入数据的sql语句

create table mylock (
id int not null primary key auto_increment,
name varchar(20) default ''
) engine myisam;
insert into mylock(name) values('a');
insert into mylock(name) values('b');
insert into mylock(name) values('c');
insert into mylock(name) values('d');
insert into mylock(name) values('e');
select * from mylock;

2. 手动在表上增加读锁

-- 加锁的sql语句
lock tables 表名字 read(write),表名字2 read(write),其它;
-- 示例(在表上添加读锁)
lock table mylock read
-- 查看表上加过的锁
show open tables;
-- 对表上加过锁的进行解锁
unlock tables;

3. session_1和session_2操作对比

1. session_1

# 对mylock表上读锁
lock table mylock read;
# 1. 对自己锁住的表的读操作
mysql> select * from mylock;
+----+------+
| id | name |
+----+------+
|  1 | a    |
|  2 | b    |
|  3 | c    |
|  4 | d    |
|  5 | e    |
+----+------+
5 rows in set (0.00 sec)
# 2. 对其它表的读操作
mysql> select * from tbl_emp;
ERROR 1100 (HY000): Table 'tbl_emp' was not locked with LOCK TABLES
# 3. 对自己锁住的表的写操作
mysql> update mylock set name = 'a1' where id = 1;
ERROR 1099 (HY000): Table 'mylock' was locked with a READ lock and can't be updated

当前session可以查询该表记录。
当前session不能查询其它没有锁定的表。
当前session插入或者更新锁定的表都会提示错误。

2. session_2

#session_2并未对mylock上锁
#1. 其对mylock表的读操作
mysql> select * from mylock;
+----+------+
| id | name |
+----+------+
|  1 | a    |
|  2 | b    |
|  3 | c    |
|  4 | d    |
|  5 | e    |
+----+------+
5 rows in set (0.00 sec)
#2. 其对非mylock的其他表的读操作
mysql> select * from tbl_emp;
+----+------+--------+
| id | name | deptId |
+----+------+--------+
|  1 | z3   |      1 |
|  2 | z4   |      1 |
|  3 | z5   |      1 |
|  4 | w5   |      2 |
|  5 | w6   |      2 |
|  6 | s7   |      3 |
|  7 | s8   |      4 |
|  8 | s9   |     51 |
+----+------+--------+
8 rows in set (0.01 sec)
#3. 其对mylock表的写操作
mysql> update mylock set name = 'a1' where id = 1;
#此时其会阻塞在这里,只有当session_1对其进行解锁后
mysql> update mylock set name = 'a1' where id = 1;
Query OK, 1 row affected (10.76 sec)
Rows matched: 1  Changed: 1  Warnings: 0

其它session可以查询该表记录。
其它session可以查询或者更新其它没有锁定的表。
其它session插入或者更新锁定的表都会一直等待获得锁（就是被阻塞了）。

1.3.2、案例二（加写锁）

session_1和session_2操作对比

1. session_1

# 其对mylock加写锁
lock table mylock write;
# 1. 其对自己锁定的表进行查询操作
mysql> select * from mylock;
+----+------+
| id | name |
+----+------+
|  1 | a1   |
|  2 | b    |
|  3 | c    |
|  4 | d    |
|  5 | e    |
+----+------+
5 rows in set (0.00 sec)
# 2. 其对自己锁定的表进行更新操作
mysql> update mylock set name = 'a' where id = 1;
Query OK, 1 row affected (0.00 sec)
Rows matched: 1  Changed: 1  Warnings: 0
# 3. 其对其它未锁定的表的查询操作
mysql> select * from tbl_emp;
ERROR 1100 (HY000): Table 'tbl_emp' was not locked with LOCK TABLES

2. session_2

# 其对session_1加了写锁的表进行查询和更新还有插入操作都会被阻塞
mysql> select * from mylock;
# 上面的sql语句会被阻塞在这里，当session_1进行解锁之后,其查询操作才能被完成。
mysql> select * from mylock;
+----+------+
| id | name |
+----+------+
|  1 | a    |
|  2 | b    |
|  3 | c    |
|  4 | d    |
|  5 | e    |
+----+------+
5 rows in set (10.21 sec)
#由时间可以看出这里被阻塞了好久。

1.3.3、案例结论

MyISAM在执行查询语句（SELECT）前，会自动给涉及的所有表加读锁，在执行增删改操作前，会自动给涉及的表加写锁。
MySQL的表级锁有两种模式

表共享读锁
表独占写锁

锁类型	可否兼容	读锁	写锁
读锁	是	是	否
写锁	是	否	否

结论

所以对MyISAM表进行操作，会有以下情况：

对MyISAM表的读操作（加读锁），不会阻塞其他进程对同一表的读请求，但会阻塞对同一表的写请求。只有当读锁释放后，才会执行其他进程的写操作。
对MyISAM表的写操作（加写锁），会阻塞其他进程对同一表的读和写操作，只有当写锁释放后，才会执行其它进程的读写操作。
简而言之，就是读锁会阻塞写，但是不会阻塞读，而写锁则会把读和写都阻塞

1.3.4、表锁分析

1. 看看哪些表被加锁了

show open tables;

2. 如何分析表锁定

可以通过table_locks_waited和table_locks_immediate状态变量来分析系统上的表锁定。

# 展示相关状态变量的SQL语句
show status like 'table%';
# 加写锁之后的状态变量的分析
mysql> show status like 'table%';
+----------------------------+-------+
| Variable_name              | Value |
+----------------------------+-------+
| Table_locks_immediate      | 247   |
| Table_locks_waited         | 0     |
| Table_open_cache_hits      | 15    |
| Table_open_cache_misses    | 4     |
| Table_open_cache_overflows | 0     |
+----------------------------+-------+
5 rows in set (0.00 sec)

table_locks_immediate：产生表级锁的次数，表示可以立即获得锁的查询次数，每立即获取锁值加1。
table_locks_waited：出现表级锁顶争用而发生等待的次数（不能立即获取锁的次数，没等待一次锁值加1），此值高说明存在较严重的表级锁争用情况。
此外，MyISAM的读写锁调度是写优先，这也是MyISAM不适合做写为主表的引擎。因为写锁后，其他线程不能做任何操作，大量的更新会使查询很难得到锁，从而造成永远阻塞。

1.4、行锁

1.4.1、行锁简介

1. 特点

偏向InnoDB存储引擎，开销大，加锁慢；会出现死锁；锁粒度最小，发生锁冲突的概率最低，并发度也最高。
InnoDB与MyISAM的最大不同有两点：一是支持事务；二是采用了行级锁。

2. 事务复习

事务及其ACID属性

事务是由一组SQL语句组成的逻辑处理单元，事务具有以下4个属性，通常简称事务的ACID属性。

原子性（Atomicity）：事务是一个原子操作单元，其对数据的修改，要么全都执行，要么全都不执行。
一致性（Consistent）：在事务开始和完成时，数据都必须保持一致状态。这意味着所有相关的数据规则都必须应用于事务的修改，以保持数据的完整性；事务结束时，所有的内部数据结构（如B树索引或双向链表）也都必须是正确的。
隔离性（Isolation）：数据库系统提供一定的隔离机制，保证事务在不受外部并发操作影响的“独立”环境执行。这意味着事务处理过程中的中间状态对外部是不可见的，反之亦然。
持久性（Durable）：事务完成之后，它对与数据的修改是永久性的，即使出现系统故障也能够保持。

并发事务处理带来的问题

更新丢失：当两个事务或多个事务选择同一行，然后基于最初选定的值更新改行时，由于每个事务都不知道其他事务的存在，就会发生丢失更新问题。最后导致最后的更新覆盖了由其他事务所做的更新。如果在一个程序员完成并提交事务之前，另一个程序员不能访问同一文件，则可避免此问题。
脏读：一个事务正在对一条记录做修改，在这个事务完成并提交前，这条记录就处于不一致状态；这时，另一个事务也来读取同一条记录，如果不加以控制，第二个事务读取了这些脏数据，并对其做了进一步的处理，就会产生未提交的数据依赖关系。这种现象被形象的叫做脏读。就是事务A读取到了事务B已修改但尚未提交的数据，还在这个数据基础上做了操作。
不可重复读：一个事务在读取某些数据后的某个时间，再次读取以前读过的数据，却发现其读过的数据已经发生了改变、或某些记录已经被删除了。这种现象就叫做“不可重复读”。就是事务A读取到了事务B已经提交的修改数据，不符合隔离性。
幻读：一个事务按相同的查询条件重新读取到以前检索过的数据，却发现其他事务插入了满足其查询条件的新数据，这种现象就被称为幻读。就是事务A读取到了事务B提交的新增数据。

事务隔离级别

脏读、不可重复读和幻读，其实都是数据库读一致性问题，必须由数据库提供一定的事务隔离机制来解决。

Read uncommitted(读未提交)：如果一个事务已经开始写数据，则另外一个事务不允许同时进行写操作，但允许其他事务读此行数据。
Read uncommitted(读未提交)：如果一个事务已经开始写数据，则另外一个事务不允许同时进行写操作，但允许其他事务读此行数据。
Repeatable read(可重复读取)：可重复读取是指在一个事务内，多次读同一个数据。
Serializable(可序化)：提供严格的事务隔离，它要求事务序列化执行，事务只能一个接着一个地执行，但不能并发执行，如果仅仅通过“行级锁”是无法实现序列化的，必须通过其他机制保证新插入的数据不会被执行查询操作的事务访问到。序列化是最高的事务隔离级别，同时代价也是最高的，性能很低，一般很少使用。

读数据一致性及允许的并发副作用	读数据一致性	脏读	不可重复度	幻读
未提交读	最低级别，只能保证不读取物理上损坏的数据	是	是	是
已提交读	语句级	否	是	是
可重复读	事务级	否	否	是
可序列化	最高级别，事务级	否	否	否

数据库的事务隔离越严格，并发副作用越小，但付出的代价也就越大，因为事务隔离实质上就是使事务在一定程度上“串行化”进行，这显然与“并发”是矛盾的。同时，不同的应用对读一致性和事务隔离程度的要求也是不同的，比如许多应用对“不可重复读”和“幻读”并不敏感，可能更关心并发访问的能力。

show variables like 'tx_isolation' -- 查看当前数据库的事务隔离级别

1.4.2、行锁案例

1. 建表和插入数据以及建索引的sql语句

CREATE TABLE test_innodb_lock (a INT(11),b VARCHAR(16))ENGINE=INNODB;
INSERT INTO test_innodb_lock VALUES(1,'b2');
INSERT INTO test_innodb_lock VALUES(3,'3');
INSERT INTO test_innodb_lock VALUES(4, '4000');
INSERT INTO test_innodb_lock VALUES(5,'5000');
INSERT INTO test_innodb_lock VALUES(6, '6000');
INSERT INTO test_innodb_lock VALUES(7,'7000');
INSERT INTO test_innodb_lock VALUES(8, '8000');
INSERT INTO test_innodb_lock VALUES(9,'9000');
INSERT INTO test_innodb_lock VALUES(1,'b1');
CREATE INDEX test_innodb_a_ind ON test_innodb_lock(a);
CREATE INDEX test_innodb_lock_b_ind ON test_innodb_lock(b);
SET autocommit=0; # 关闭事务的自动提交

2. session_1和session_2的操作对比

session_1修改数据后session_2查看

# 自动提交关闭之后
# session_1
mysql> update test_innodb_lock set b = '4001' where a = 4;
Query OK, 1 row affected (0.00 sec)
Rows matched: 1  Changed: 1  Warnings: 0
mysql> select * from test_innodb_lock;
+------+------+
| a    | b    |
+------+------+
|    1 | b2   |
|    3 | 3    |
|    4 | 4001 |
|    5 | 5000 |
|    6 | 6000 |
|    7 | 7000 |
|    8 | 8000 |
|    9 | 9000 |
|    1 | b1   |
+------+------+
9 rows in set (0.00 sec)
# session_2
mysql> select * from test_innodb_lock;
+------+------+
| a    | b    |
+------+------+
|    1 | b2   |
|    3 | 3    |
|    4 | 4000 |
|    5 | 5000 |
|    6 | 6000 |
|    7 | 7000 |
|    8 | 8000 |
|    9 | 9000 |
|    1 | b1   |
+------+------+
9 rows in set (0.00 sec)
# session_2在session_1修改数据之后是无法查看到数据的变化，但session_1自己可以看到。
# 只有当双方都commit之后session_2才可以看到。
# 这并不是什么误操作，是因为自动提交被关闭了。

session_1和session_2修改同一行数据

# session_1
mysql> update test_innodb_lock set b = '4002' where a = 4;
Query OK, 1 row affected (0.00 sec)
Rows matched: 1  Changed: 1  Warnings: 0
# session_2
mysql> update test_innodb_lock set b = '4003' where a = 4;
# 此时session_2会陷入阻塞，当session_1提交事务之后，session_2才能修改成功。
#并且session_2提交事务之后，它的修改才能生效。
#查询出来的结果
mysql> select * from test_innodb_lock;
+------+------+
| a    | b    |
+------+------+
|    1 | b2   |
|    3 | 3    |
|    4 | 4003 |
|    5 | 5000 |
|    6 | 6000 |
|    7 | 7000 |
|    8 | 8000 |
|    9 | 9000 |
|    1 | b1   |
+------+------+
9 rows in set (0.00 sec)

session_1和session_2修改不同行数据

# session_1
# 修改第九行数据
mysql> update test_innodb_lock set b = '9001' where a = 9;
Query OK, 1 row affected (0.00 sec)
Rows matched: 1  Changed: 1  Warnings: 0
# session_2
# 修改第四行数据
mysql> update test_innodb_lock set b = '4003' where a = 4;
Query OK, 1 row affected (0.00 sec)
Rows matched: 1  Changed: 1  Warnings: 0
# 当双方多次提交事务之后的查询结果，双方互不影响。
mysql> select * from test_innodb_lock;
+------+------+
| a    | b    |
+------+------+
|    1 | b2   |
|    3 | 3    |
|    4 | 4003 |
|    5 | 5000 |
|    6 | 6000 |
|    7 | 7000 |
|    8 | 8000 |
|    9 | 9001 |
|    1 | b1   |
+------+------+
9 rows in set (0.00 sec)

1.4.3、索引失效行锁升级为表锁

# session_1
# 我们都知道varchar类型的数据在使用的时候不加单引号会导致索引失效 b字段的类型是varchar
mysql> update test_innodb_lock set a = 9 where b = 9001;
Query OK, 1 row affected (0.04 sec)
Rows matched: 1  Changed: 1  Warnings: 0
# session_2
mysql> update test_innodb_lock set b = '4001' where a = 4;
# session_2会被上述语句阻塞，当session_1进行提交之后它才会执行自己的语句
# session_2也commit之后的执行结果
mysql> select * from test_innodb_lock;
+------+------+
| a    | b    |
+------+------+
|    1 | b2   |
|    3 | 3    |
|    4 | 4001 |
|    5 | 5000 |
|    6 | 6000 |
|    7 | 7000 |
|    8 | 8000 |
|    9 | 9001 |
|    1 | b1   |
+------+------+
9 rows in set (0.00 sec)

1.4.4、间隙锁

1. 什么是间隙锁？

当我们使用范围条件而不是相等条件检索数据，并请求共享或排它锁时，InnoDB会给符合条件的已有数据记录的索引加锁；对于键值在条件范围但并不存在的记录——间隙，InnoDB也会对这个间隙加锁，这种锁机制就是所谓的间隙锁。

2. 间隙锁的危害

因为Query执行过程中通过范围查找的话，他会锁定整个范围内所有的索引键值，即使这个键值不存在。间隙锁有一个致命的弱点，就是当锁定一个范围键值之后，即使某些不存在的键值也会被锁定，而造成锁定的时候无法插入锁定范围内的任何数据。在某些场景下这可能会对性能造成很大的危害。

3. 案例演示

#session_1
mysql> update test_innodb_lock set b = '0629' where a > 1 and a < 6;
Query OK, 3 rows affected (0.00 sec)
Rows matched: 3  Changed: 3  Warnings: 0
# 他这是范围更新，但是a = 2不存在，所以我们使用session_2进行插入。
# session_2
mysql> insert into test_innodb_lock values(2,'2000');
#session_2会阻塞在这里
# 当session_1进行commit操作之后session_2才会执行自己的sql语句
# 当session_2也进行commit之后的查询结果
mysql> select * from test_innodb_lock;
+------+------+
| a    | b    |
+------+------+
|    1 | b2   |
|    3 | 0629 |
|    4 | 0629 |
|    5 | 0629 |
|    6 | 6000 |
|    7 | 7000 |
|    8 | 8000 |
|    9 | 9001 |
|    1 | b1   |
|    2 | 2000 |
+------+------+
10 rows in set (0.00 sec)

1.4.5、如何锁定一行

select xxx... for update锁定某一行后，其它的操作会被阻塞，直到锁定行的会话提交commit。

案例演示

# session_1
mysql> begin;
Query OK, 0 rows affected (0.00 sec)
mysql> select * from test_innodb_lock where a = 8 for update;
+------+------+
| a    | b    |
+------+------+
|    8 | 8000 |
+------+------+
1 row in set (0.00 sec)
# 上述sql语句对 a = 8 的这一行进行了锁定
# session_2
mysql> update test_innodb_lock set b = '8001' where a = 8;
# 此时session_2会被阻塞，直到session_1进行了commit操作
# 双方都进行了commit操作之后的查询结果
mysql> select * from test_innodb_lock;
+------+------+
| a    | b    |
+------+------+
|    1 | b2   |
|    3 | 0629 |
|    4 | 0629 |
|    5 | 0629 |
|    6 | 6000 |
|    7 | 7000 |
|    8 | 8001 |
|    9 | 9001 |
|    1 | b1   |
|    2 | 2000 |
+------+------+
10 rows in set (0.00 sec)

1.4.6、案例总结

InnoDB 存储引擎由于实现了行级锁定，虽然在锁定机制实现方面所带来的性能损耗比表级锁更多，但是在整体并发处理能力方面要远优于 MyISAM 的表级锁定的。当系统并发量比较高的时候，InnoDB 的整体性能和 MyISAM 相比会有比较明显的优势。
InnoDB 的行级锁同样也存在问题，当我们不当使用时，可能会使 InnoDB 的整体性能表现比 MyISAM 更差。

1.4.7、行锁分析

1. 怎样分析

通过检查 InnoDB_row_lock 状态变量来分析系统上的行锁争夺情况
查看命令 show status like '%innodb_row_lock%'

# 展示结果
mysql> show status like '%innodb_row_lock%';
+-------------------------------+--------+
| Variable_name                 | Value  |
+-------------------------------+--------+
| Innodb_row_lock_current_waits | 0      |
| Innodb_row_lock_time          | 143630 |
| Innodb_row_lock_time_avg      | 23938  |
| Innodb_row_lock_time_max      | 50403  |
| Innodb_row_lock_waits         | 6      |
+-------------------------------+--------+
5 rows in set (0.05 sec)

状态变量说明：

Innodb_row_lock_current_waits：当前正在等待锁定的数量；
Innodb_row_lock_time：从系统启动到现在锁定总时间；
Innodb_row_lock_time_avg：每次平均等待时间；
Innodb_row_lock_time_max：从系统启动到现在等待最长的一次所花的时间；
Innodb_row_lock_waits：系统启动后到现在总共等待的次数；

五个状态变量中比较重要的：

Innodb_row_lock_time_avg：每次平均等待时间；
Innodb_row_lock_waits：系统启动后到现在总共等待的次数；
Innodb_row_lock_time：从系统启动到现在锁定总时间；

尤其是当前等待次数很高，而且每次等待时长也很长的时候，需要分析系统中出现多次等待的原因，并根据分析结果指定优化计划。

2. 优化建议

尽可能让所有数据检索都通过索引完成，避免无索引行锁升级为表锁；
合理设计索引，尽量缩小锁的范围；
尽可能减少检索条件，避免间隙锁；
尽量控制事务大小，减少锁定资源量和时间长度；
尽可能使用低级别的事务隔离；

1.5、页锁

页锁的开销和加锁时间介于表锁和行锁之间，会出现死锁，锁定粒度介于表锁和行锁之间，并发度一般。了解一下即可。

2、乐观锁与悲观锁

2.1悲观锁

悲观锁（Pessimistic Lock），顾名思义，就是很悲观，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会block直到它拿到锁。

悲观锁：假定会发生并发冲突，屏蔽一切可能违反数据完整性的操作。

Java synchronized 就属于悲观锁的一种实现，每次线程要修改数据时都先获得锁，保证同一时刻只有一个线程能操作数据，其他线程则会被block。

2.2 乐观锁

乐观锁（Optimistic Lock），顾名思义，就是很乐观，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在提交更新的时候会判断一下在此期间别人有没有去更新这个数据。乐观锁适用于读多写少的应用场景，这样可以提高吞吐量。

乐观锁：假设不会发生并发冲突，只在提交操作时检查是否违反数据完整性。

乐观锁一般来说有以下2种方式：

使用数据版本（Version）记录机制实现，这是乐观锁最常用的一种实现方式。何谓数据版本？即为数据增加一个版本标识，一般是通过为数据库表增加一个数字类型的 “version” 字段来实现。当读取数据时，将version字段的值一同读出，数据每更新一次，对此version值加一。当我们提交更新的时候，判断数据库表对应记录的当前版本信息与第一次取出来的version值进行比对，如果数据库表当前版本号与第一次取出来的version值相等，则予以更新，否则认为是过期数据。
使用时间戳（timestamp）。乐观锁定的第二种实现方式和第一种差不多，同样是在需要乐观锁控制的table中增加一个字段，名称无所谓，字段类型使用时间戳（timestamp）, 和上面的version类似，也是在更新提交的时候检查当前数据库中数据的时间戳和自己更新前取到的时间戳进行对比，如果一致则OK，否则就是版本冲突。

Java JUC中的atomic包就是乐观锁的一种实现，AtomicInteger 通过CAS（Compare And Set）操作实现线程安全的自增。

MySQL隐式和显示锁定

MySQL InnoDB采用的是两阶段锁定协议（two-phase locking protocol）。在事务执行过程中，随时都可以执行锁定，锁只有在执行 COMMIT或者ROLLBACK的时候才会释放，并且所有的锁是在同一时刻被释放。前面描述的锁定都是隐式锁定，InnoDB会根据事务隔离级别在需要的时候自动加锁。

另外，InnoDB也支持通过特定的语句进行显示锁定，这些语句不属于SQL规范：

SELECT ... LOCK IN SHARE MODE
SELECT ... FOR UPDATE

实战

接下来，我们通过一个具体案例来进行分析：考虑电商系统中的下单流程，商品的库存量是固定的，如何保证商品数量不超卖？其实需要保证数据一致性：某个人点击秒杀后系统中查出来的库存量和实际扣减库存时库存量的一致性就可以。

假设，MySQL数据库中商品库存表tb_product_stock 结构定义如下：

CREATE TABLE `tb_product_stock` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT '自增ID',
  `product_id` bigint(32) NOT NULL COMMENT '商品ID',
  `number` INT(8) NOT NULL DEFAULT 0 COMMENT '库存数量',
  `create_time` DATETIME NOT NULL COMMENT '创建时间',
  `modify_time` DATETIME NOT NULL COMMENT '更新时间',
  PRIMARY KEY (`id`),
  UNIQUE KEY `index_pid` (`product_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='商品库存表';

对应的POJO类：

class ProductStock {
    private Long productId; //商品id
    private Integer number; //库存量
    public Long getProductId() {
        return productId;
    }
    public void setProductId(Long productId) {
        this.productId = productId;
    }
    public Integer getNumber() {
        return number;
    }
    public void setNumber(Integer number) {
        this.number = number;
    }
}

不考虑并发的情况下，更新库存代码如下：

/**
     * 更新库存(不考虑并发)
     * @param productId
     * @return
     */
    public boolean updateStockRaw(Long productId){
        ProductStock product = query("SELECT * FROM tb_product_stock WHERE product_id=#{productId}", productId);
        if (product.getNumber() > 0) {
            int updateCnt = update("UPDATE tb_product_stock SET number=number-1 WHERE product_id=#{productId}", productId);
            if(updateCnt > 0){    //更新库存成功
                return true;
            }
        }
        return false;
    }

多线程并发情况下，会存在超卖的可能。

悲观锁

/**
     * 更新库存(使用悲观锁)
     * @param productId
     * @return
     */
    public boolean updateStock(Long productId){
        //先锁定商品库存记录
        ProductStock product = query("SELECT * FROM tb_product_stock WHERE product_id=#{productId} FOR UPDATE", productId);
        if (product.getNumber() > 0) {
            int updateCnt = update("UPDATE tb_product_stock SET number=number-1 WHERE product_id=#{productId}", productId);
            if(updateCnt > 0){    //更新库存成功
                return true;
            }
        }
        return false;
    }

乐观锁

/**
     * 下单减库存
     * @param productId
     * @return
     */
    public boolean updateStock(Long productId){
        int updateCnt = 0;
        while (updateCnt == 0) {
            ProductStock product = query("SELECT * FROM tb_product_stock WHERE product_id=#{productId}", productId);
            if (product.getNumber() > 0) {
                updateCnt = update("UPDATE tb_product_stock SET number=number-1 WHERE product_id=#{productId} AND number=#{number}", productId, product.getNumber());
                if(updateCnt > 0){    //更新库存成功
                    return true;
                }
            } else {    //卖完啦
                return false;
            }
        }
        return false;
    }

使用乐观锁更新库存的时候不加锁，当提交更新时需要判断数据是否已经被修改（AND number=#{number}），只有在 number等于上一次查询到的number时才提交更新。

注意：UPDATE 语句的WHERE 条件字句上需要建索引

2.3 乐观锁与悲观锁的区别

乐观锁的思路一般是表中增加版本字段，更新时where语句中增加版本的判断，算是一种CAS（Compare And Swep）操作，商品库存场景中number起到了版本控制（相当于version）的作用（ AND number=#{number}）。

悲观锁之所以是悲观，在于他认为本次操作会发生并发冲突，所以一开始就对商品加上锁（SELECT ... FOR UPDATE），然后就可以安心的做判断和更新，因为这时候不会有别人更新这条商品库存。

五、锁机制概述

1.1、定义

1.2、锁的分类

1.3、表锁（偏读）

1.3.1、案例一（加读锁）

1.3.2、案例二（加写锁）

1.3.3、案例结论

1.3.4、表锁分析

1.4、行锁

1.4.1、行锁简介

1.4.2、行锁案例

1.4.3、索引失效行锁升级为表锁

1.4.4、间隙锁

1.4.5、如何锁定一行

1.4.6、案例总结

1.4.7、行锁分析

1.5、页锁

2、乐观锁与悲观锁

2.1悲观锁

2.2 乐观锁

MySQL隐式和显示锁定

实战

悲观锁

乐观锁

2.3 乐观锁与悲观锁的区别

热门文章

最新文章

相关电子书

五、锁机制概述

1.1、定义

1.2、锁的分类

1.3、表锁（偏读）

1.3.1、案例一（加读锁）

1.3.2、案例二（加写锁）

1.3.3、案例结论

1.3.4、表锁分析

1.4、行锁

1.4.1、行锁简介

1.4.2、行锁案例

1.4.3、索引失效行锁升级为表锁

1.4.4、间隙锁

1.4.5、如何锁定一行

1.4.6、案例总结

1.4.7、行锁分析

1.5、页锁

2、 乐观锁与悲观锁

2.1悲观锁

2.2 乐观锁

MySQL隐式和显示锁定

实战

悲观锁

乐观锁

2.3 乐观锁与悲观锁的区别

热门文章

最新文章

相关电子书

2、乐观锁与悲观锁