悲观锁和乐观锁定义

悲观锁和乐观锁的定义分别如下：

1.悲观锁：顾名思义，就是比较悲观的锁，总是假设最坏的情况，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会阻塞直到它拿到锁

特点：可以完全保证数据的独占性和正确性，因为每次请求都会先对数据进行加锁， 然后进行数据 *** 作，最后再解锁，而加锁释放锁的过程会造成消耗，所以性能不高

手动加悲观锁：读锁LOCK tables test_db read释放锁UNLOCK TABLES

写锁：LOCK tables test_db WRITE释放锁UNLOCK TABLES

2.乐观锁：反之，总是假设最好的情况，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号机制和CAS算法实现。

特点：乐观锁是一种并发类型的锁，其本身不对数据进行加锁通而是通过业务实现锁的功能，不对数据进行加锁就意味着允许多个请求同时访问数据，同时也省掉了对数据加锁和解锁的过程，这种方式因为节省了悲观锁加锁的 *** 作，所以可以一定程度的的提高 *** 作的性能

乐观锁与悲观锁不同的是，它是一种逻辑上的锁，而不需要数据库提供锁机制来支持

当数据很重要，回滚或重试一次需要很大的开销时，需要保证 *** 作的ACID性质，此时应该采用悲观锁

而当数据对即时的一致性要求不高，重试一次不太影响整体性能时，可以采用乐观锁来保证最终一致性，同时有利于提高并发性

通常，乐观锁采用版本号/时间戳的形式实现：给数据额外增加一个版本号字段进行控制；更新时，若提交的数据所带的版本号与当前记录的版本号一致，则允许变更执行并更新版本号；若不一致，则意味着产生冲突，根据业务需求直接丢弃并返回失败，或者尝试合并

在MySQL的实践中，常见的一种使用乐观锁的方法，是在需要使用乐观锁的表中，新增一个version字段

例如：

create table product_amount (

id int not null primary key auto_increment,

product_name varchar(64) not null,

selling_amount int not null,

storing_amount int not null,

version int not null

)

当需要更新销售中的商品数量（selling_amount）时，使用如下的SQL语句：

update product_amount set selling_amount = #{selling_amount}, version = #{new_version} where id=#{id} and version = #{old_version}

若该语句返回1，则表示更新成功；若返回0，则表示前后的version不一致，产生冲突，更新失败

对于更新仓库中的商品数据（storing_amount）时，也是同理

不过，这样为每行记录都统一设置一个version字段的乐观锁方式，存在一个问题：上例中，如果同时需要单独对selling_amount及storing_amount进行update（两条SQL语句分别单独执行），那么后执行的一条会因为先执行的一条更新了version字段而失败，而这种失败显然是没有必要的，白白浪费了开销

一种比较好的方式是为每个需要乐观锁的字段单独设置版本号，例如对上例的改造：

create table product_amount (

id int not null primary key auto_increment,

product_name varchar(64) not null,

selling_amount int not null,

selling_version int not null,

storing_amount int not null,

storing_version int not null

)

selling_amount和storing_amount分别拥有自己的乐观锁版本号（selling_version和storing_version），更新时分别只关注自己的版本号，这样就不会因为版本号被其它字段修改而失败，提高了并发性

---