悲观锁

悲观锁一般都是基于数据库的锁机制来实现。

数据库提供了共享锁（S锁）和排它锁（X锁）

共享锁（S）：SELECT * FROM table_name WHERE … LOCK IN SHARE MODE。

排他锁（X)：SELECT * FROM table_name WHERE … FOR UPDATE。

以下mysql innodb 对上述锁的一个测试
打开两个数据库连接
一个连接做如下代码

set autocommit=0;
select  * from message where id=1   for update ;
另一个连接的代码执行完毕，进入等待之后，执行提交代码，会发现等待瞬间结束
commit;

另一个连接做如下操作

    select  * from message where id=1 LOCK IN SHARE MODE

用SELECT … IN SHARE MODE获得共享锁，主要用在需要数据依存关系时来确认某行记录是否存在，并确保没有人对这个记录进行UPDATE或者DELETE操作。但是如果当前事务也需要对该记录进行更新操作，则很有可能造成死锁，对于锁定行记录后需要进行更新操作的应用，应该使用SELECT… FOR UPDATE方式获得排他锁

InnoDB行锁实现方式
InnoDB行锁是通过给索引上的索引项加锁来实现的，这一点MySQL与Oracle不同，后者是通过在数据块中对相应数据行加锁来实现的。InnoDB这种行锁实现特点意味着：只有通过索引条件检索数据，InnoDB才使用行级锁，否则，InnoDB将使用表锁！

在实际应用中，要特别注意InnoDB行锁的这一特性，不然的话，可能导致大量的锁冲突，从而影响并发性能。下面通过一些实际例子来加以说明。

（1）在不通过索引条件查询的时候，InnoDB确实使用的是表锁，而不是行锁。

（2）由于MySQL的行锁是针对索引加的锁，不是针对记录加的锁，所以虽然是访问不同行的记录，但是如果是使用相同的索引键，是会出现锁冲突的。应用设计的时候要注意这一点。

（3）当表有多个索引的时候，不同的事务可以使用不同的索引锁定不同的行，另外，不论是使用主键索引、唯一索引或普通索引，InnoDB都会使用行锁来对数据加锁

（4）即便在条件中使用了索引字段，但是否使用索引来检索数据是由MySQL通过判断不同执行计划的代价来决定的，如果MySQL认为全表扫描效率更高，比如对一些很小的表，它就不会使用索引，这种情况下InnoDB将使用表锁，而不是行锁。因此，在分析锁冲突时，别忘了检查SQL的执行计划，以确认是否真正使用了索引。

使用情景描述
A和B同时需要获取C，并开始进展下一步的工作，然而C的库存目前只剩下了1份了，那这个时候可以考虑在查询的时候使用排它锁

参考

http://lib.csdn.net/article/mysql/4360