并发控制

在多用户环境中，在同一时间可能会有多个用户更新相同的记录，这会产生冲突。这就是并发性。典型的冲突有：
** 1、丢失更新（Lost updates）**
一个事务的更新覆盖了其它事务的更新结果，就是所谓的更新丢失。例如：用户A把值从6改为2，用户B把值从2改为6，则用户A丢失了他的更新。
** 2、脏读（Dirty reads）**
当一个事务读取其它完成一半事务的记录时，就会发生脏读取。例如：用户A,B看到的值都是6，用户B把值改为2，用户A读到的值仍为6。
3、不可重复读（Non-repeatable reads） 当一个进程读取了一笔数据后，另一个进程更新了同一笔数据，然后第一个进程再次读取同一笔数据，却得到了与第一次读取不同的结果。
在事务A更新记录之后（update Customers set Name = 'B' where Name = 'A'），事务B读取相同记录（select Name form Customers where Name = 'A'），但事务B拿到的是事务A更新之后的数据（Customers.Name的值为'B'），在事务B读取记录之后，事务A进行了事务回滚（Customers.Name的值为'A'），导致事务B的数据是不真实的。 4、幻读（Phantoms）幻读与脏读的相似之处在于：两者都是两次读取的结果不一致。不同之处在于：幻读是两次读取的记录数量不一致，而脏读是两次读取的记录的数据不一致。事务A读取记录之后（select * from Customers where Name like 'A%'），事务B又插入了符合事务A读取条件的新记录（insert into Customers(Name) values('AAA')），那么当事务A再用相同条件读取记录时，得到的集合却与上一次读取不同（多了记录）。

解决方案：线程同步和加锁

通常我们解决并发问题使用同步和加锁两种方式。同步中，我们通过Java中的synchronized关键字来实现，但这样通常会带来性能和效率上的一些问题。这次，我们主要讲解锁。锁机制中，我们可以根据不同情况使用悲观锁或乐观锁。

悲观锁(Pessimistic Lock), 顾名思义，就是很悲观，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会block直到它拿到锁。传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁。对于悲观锁，我们可以提供一个值作为锁的参数。比如一个键默认会被锁定15秒。15秒过后，如果你还没有手动的释放锁，那么使程序自动的为你释放。悲观锁的实现，往往依靠数据库提供的锁机制（也只有数据库层提供的锁机制才能真正保证数据访问的排他性，否则，即使在本系统中实现了加锁机制，也无法保证外部系统不会修改数据）。但随之而来的就是数据库性能的大量开销，特别是对长事务而言，这样的开销往往无法承受。
乐观锁：乐观锁(Optimistic Lock), 就是很乐观，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据。而乐观锁机制在一定程度上解决了数据库性能开销这个问题。它大多是基于数据版本（ Version ）记录机制实现。可以使用版本号、时间戳等机制。乐观锁适用于多读的应用类型，这样可以提高吞吐量，像数据库如果提供类似于write_condition机制的其实都是提供的乐观锁。

比较

两种锁各有优缺点，不可认为一种好于另一种，像乐观锁适用于写比较少的情况下，即冲突真的很少发生的时候，这样可以省去了锁的开销，加大了系统的整个吞吐量。但如果经常产生冲突，上层应用会不断的进行retry，这样反倒是降低了性能，所以这种情况下用悲观锁就比较合适。
悲观锁和乐观锁最大的区别是是否一直锁定资源，悲观锁在事物的全流程锁定数据，乐观锁不锁定数据（用读写锁是阻塞事物，而用乐观锁则会导致回滚，这个是一种事物冲突后的不同锁的表象）。
悲观锁和乐观锁都是为了解决丢失更新问题或者是脏读。悲观锁和乐观锁的重点就是是否在读取记录的时候直接上锁。悲观锁的缺点很明显，需要一个持续的数据库连接，这在web应用中已经不适合了。

注：转http://www.cnblogs.com/soundcode/p/6571447.html