背景
考虑下面两个并发带来的问题：
1、丢失更新：一个事务的更新结果覆盖了其它事务的更新结果，即所谓的更新丢失。
2、脏读：当一个事务读取其它完成一半事务的记录时，就会发生脏读取。
例如：
两个用户同时修改商品库存表，A、B同时进入，看到的库存都是100，A购买一件把库存修改为99(100-1)。此时B购买两件把库存修改为98(100-2)，因为A、B同时读到的库存都是100，B并不能看到A做的库存更新，所以造成B脏读，造成A丢失更新。
所以为了解决这些并发带来的问题。 我们需要引入并发控制机制--锁。
锁分类
悲观锁
悲观锁就是用户修改数据时看起来很悲观，保守态度，担心别的用户会同时修改这条数据，所以每次修改时会提前把这条数据锁定起来，只有自己可修改（但别的用户可以读），等自己修改完了再释放锁。
乐观锁
乐观锁就是用户修改数据时心态很乐观，不管别人修改不修改数据，我都不上锁，我修改的时候判断下数据有没有发生变化，没发生变化我就会更新成功，发生变化了就不会更新成功我再去重试之前的动作直到更新成功。
锁应用
悲观锁
使用悲观锁的时候我们首先必须关闭mysql数据库的自动提交属性，因为MySQL默认使用autocommit模式，也就是说，当你执行一个更新操作后，MySQL会立刻将结果进行提交。
关闭命令为：set autocommit=0;
悲观锁一般使用select…for update实现，在执行的时候会锁定数据，虽然会锁定数据，但是不影响其他事务的普通查询使用。
在我们使用悲观锁的时候事务中的语句例如：
//开始事务
begin;/begin work;/start transaction; (三选一)
//查询信息
select * from order where id=1 for update;
//修改信息
update order set name='names';
//提交事务
commit;/commit work;(二选一)
此处的查询语句for update关键字，在事务中只有SELECT ... FOR UPDATE 或LOCK IN SHARE MODE 同一条数据时会等待其它事务结束后才执行，一般的SELECT查询则不受影响。
注意事项
执行事务时关键字select…for update会锁定数据，防止其他事务更改数据。但是锁定数据也是有规则的。
查询条件与锁定范围：
1、具体的主键值为查询条件
比如查询条件为主键ID=1等等，如果此条数据存在，则锁定当前行数据，如果不存在，则不锁定。
2、不具体的主键值为查询条件
比如查询条件为主键ID>1等等，此时会锁定整张数据表。
3、查询条件中无主键
会锁定整张数据表。
4、如果查询条件中使用了索引为查询条件
明确指定索引并且查到，则锁定整条数据。如果找不到指定索引数据，则不加锁。
乐观锁
1、使用自增长的整数表示数据版本号，更新时检查版本号是否一致，比如数据库中数据版本为666，更新提交时version=666+1,使用该version值(=667)与数据库version+1(=667)作比较，如果相等，则可以更新，如果不等则有可能其他程序已更新该记录，所以返回错误或者发起重试动作。
例如表
student(id,name,version)
1 a 1
当事务一进行更新操作：update student set name='txt' where id = #{id} and version = #{version};
此时操作完后数据会变为id = 1,name = txt,version = 2，当另外一个事务二同样执行更新操作的时候，却发现version != 1，此时事务二就会操作失败，从而保证了数据的正确性。
2、使用时间戳来实现，原理同上。
3、使用其他数据库字段，如：金额，更新时添加条件判断金额是否变化，原理同上。
乐观锁图示
结论
两种锁各有优缺点，不能单纯的定义哪个好于哪个。乐观锁比较适合数据修改比较少，读取比较频繁的场景，即使出现了少量的冲突，这样也省去了大量的锁的开销，故而提高了系统的吞吐量。但是如果经常发生冲突（写数据比较多的情况下），上层应用不不断的retry，这样反而降低了性能，对于这种情况使用悲观锁就更合适。
