这两个名词的概念
首先要区分锁跟事务是两回事。业务上到时会结合使用处理问题。
事务是保证一系列操作要么全部完成，要么回滚全部没做。而锁是处理并发问题，保证没有覆盖脏读等问题。
悲观锁和乐观锁，是概念上的名字，并不是数据库才有的功能。除了数据库，一些组件和Java语言都是有对应的概念功能的。比如Java中的cas概念是乐观锁，synchronized关键字是悲观锁。
Mysql中使用悲观锁和乐观锁
在DBMS系统中都有类似的功能，以mysql为例子看下：
mysql的存储引擎MyISAM默认是表锁，InnoDB默认是行锁
行锁又分为共享锁和排他锁，了解悲观锁还要先了解下两个锁的概念
共享锁&排他锁
共享锁
sql用法：
SELECT ... LOCK IN SHARE MODE;
- 共享锁又称读锁，使用上述语句可以获取到行的共享锁，一个事务获取共享锁后，其他事务可以并发读取数据（此事务再次加上共享锁，可重入），但任何事务都不能对数据进行修改（需获取数据上的排他锁才行）。
- 一个事务想要获取到排他锁，需要操作的所在行上，所有的共享锁都已释放才行。否则，就要等待或者抛出异常（由用户去选择）。
排他锁
sql用法：
SELECT ... FOR UPDATE;
- 使用这样方式，可以显示的给select语句，加上排他锁。
对于update，insert，delete数据库会直接给加上排他锁。 - 排他锁是写锁，获取排他锁的事务，既可以读数据，也可以写数据。
- 其他事务想要申请获取排他锁，需要数据所在的行，所有的共享锁和排他锁都被释放才可以。否则需要等待或者抛出异常（由用户选择）
数据库的悲观锁就是使用的排他锁控制的，过程如下：
- 在对任意记录进行修改前，先尝试为该记录加上排他锁。
- 如果加锁失败，说明该记录正在被修改，那么当前查询可能要等待或者抛出异常。 具体响应方式由开发者根据实际需要决定。
- 如果成功加锁，那么就可以对记录做修改，事务完成后就会解锁了。
- 其间如果有其他对该记录做修改或加排他锁的操作，都会等待我们解锁或直接抛出异常。
以下一些情况（记录的不完全），会到锁表
相较于锁行，锁表的性能肯定会差不少，所以使用中应该尽量避免这种情况。
InnoDB默认是锁行，但是由于其加锁的原理，有些操作会导致锁表。加锁的原理是：
InnoDB行锁是通过给索引上的索引项加锁来实现的，这一点MySQL与Oracle不同，后者是通过在数据块中对相应数据行加锁来实现的。InnoDB这种行锁实现特点意味着：只有通过索引条件检索数据，InnoDB才使用行级锁，否则，InnoDB将使用表锁！
说白了，就是where后的条件，字段要命中索引，并且唯一。不然就会锁表。以下举些例子：
假设kid是表table的一个索引字段，且值不唯一
1.如果kid 有多个值为12的记录那么：
update table set name=’lxqn’ where kid=12;
会锁表（不唯一）
2.如果kid有唯一的值为1的记录那么：
update table set name=’lxqn’ where kid=1;
不会锁
如果where后的条件字段，不是索引，则锁表（待确认）
总结：用索引字段做为条件进行修改时， 是否表锁的取决于这个索引字段能否确定记录唯一，当索引值对应记录不唯一，会进行锁表，相反则行锁。
如果有两个delete，kid1与kid2是索引字段
delete from table where kid1=1 and kid2=2;
delete from table where kid1=1 and kid2=3;
这样的两个delete 是不会锁表的
delete from table where kid1=1 and kid2=2;
delete from table where kid1=1 ;
这样的两个delete 会锁表
总结：同一个表，如果进行删除操作时，尽量让删除条件统一，否则会相互影响造成锁表
处理日常业务中通用的一类问题
select+update业务，代表者一类问题。
比如用户充值的业务，细分的步骤应该是，
- 先查余额表，查到用户的余额数
- 然后加上请求来的充值金额
- update余额表
有三种方案可以处理这类问题，会在最后一段里，比较三者的优缺点，以及总结各自适用场景。
- 方案一
update tb_user_balance set total_amount = total_amount+?,last_update_time=now() where user_guid=?;
直接使用update获取排他锁，在一条sql里完成。具体的业务金额相加操作放到sql语句里。
场景。
- 方案二
trancation begin
select total_amount from tb_user_balance where user_guid = ? for update;
//具体的业务操作
total_amount = total_amount + xxx
update tb_user_balance set total_amount = total_amount where user_guid = ?;
trancation end
使用for update语法，给查询余额语句，获取排他锁；具体的充值相加业务独立出来，放到sql外边，去操作；然后更新余额。
这个方案需要加上事务，需要把autocommit属性设置为false，默认是自动提交的。
3.方案三
select total_amount,version from tb_user_balance where user_guid =?;
//具体的业务操作
total_amount = total_amount + xxx
update tb_user_balance set total_amount = total_amount and version=version+1 where user_guid =? and version = #{version};
使用的是类cas操作，乐观锁。在表中添加一个版本号的概念， 一开始初始化一个值，每次更新操作都对版本号version加1。
有没有发现这个思想，跟版本控制工具svn的设计很像。
先查出来用户的金额和版本值；处理金额充值业务；更新余额，更新的条件，加上版本号要等于之前查到的版本号。因为如果不等的话，说明已经有别的事务请求，对这个用户的余额记录进行变动了。就放弃这次操作，再来一次。
悲观锁和乐观锁的适用场景
先比较下
方案一
优点：简单直接
缺点：业务操作放到了sql里，如果是比较复杂的业务，甚至是查到结果，然后需要再操作几条sql语句，再去update金额，就不适合了，因为sql里边的业务复杂的话，后续修改会非常晦涩，不宜维护，并且可能会改的更为复杂。
方案二
优点：避免的方案一的缺点。
缺点：这个操作，在查询的时候会有加锁的动作（排他锁）。性能是会有所损失。
方案三
优点：避免了方案一和方案二的缺点。并发能力强
缺点：在一些要求必须操作成功的（must done）场景，比如运营后台操作，有概率操作不成功。在一些写很多的场景，并发冲突多的场景，不适合。应该会导致更新不成功，需要重试。
结合以上的分析，总结三种方案的使用场景。
方案一适合业务操作简单的，比如就是充值的余额增加。
业务操作复杂的需要使用方案二方案三。
而根据业务的读写量场景多少，可选择是方案二还是方案三
如果写操作频繁并且冲突比例很高，那么适合用悲观写独占锁
如果对读的相应速度要求比较高，适合用乐观锁，因为悲观锁会阻塞。
如果是读多写少的场景，因为大量的读会被少量的写阻塞。
参考博文
http://www.hollischuang.com/archives/934
http://www.topthink.com/topic/815.html
http://blog.csdn.net/yonghumingbuzhidao/article/details/8330795
