乐观锁和悲观锁

并发冲突

在多用户的环境下，如果用户同时修改同一个文档，就会造成冲突。

典型的冲突有两种：

1、丢失更新：一个用户的更新记录覆盖了另一个人的更新。如： 

时间：     ------------------------------------------------>

用户一：读----------------------->写

用户二：           读------>写

那么用户一就把用户二的更新覆盖了。

2、脏读：一个用户更新数据未完成时，另一个用户就读取信息。

时间：     ------------------------------------------------>

用户一：读------------->写

用户二：           读------------------------>

那么用户二读取到的数据是旧的数据。

并发控制机制

既然存在这样的冲突，就需要一种机制来处理并发冲突。最常见的方法就是加锁，锁又分乐观锁和悲观锁。

1、悲观锁：假定其他用户企图访问或者改变你正在访问、更改的对象的概率是很高的，因此在悲观锁的环境中，在你开始改变此对象之前就将该对象锁住，并且直到你提交了所作的更改之后才释放锁。悲观的缺陷是不论是页锁还是行锁，加锁的时间可能会很长，这样可能会长时间的限制其他用户的访问，也就是说悲观锁的并发访问性不好。

2、乐观锁：则认为其他用户企图改变你正在更改的对象的概率是很小的，因此乐观锁直到你准备提交所作的更改时才将对象锁住，当你读取以及改变该对象时并不加锁。可见乐观锁加锁的时间要比悲观锁短，乐观锁可以用较大的锁粒度获得较好的并发访问性能。但是如果第二个用户恰好在第一个用户提交更改之前读取了该对象，那么当他完成了自己的更改进行提交时，数据库就会发现该对象已经变化了，这样，第二个用户不得不重新读取该对象并作出更改。这说明在乐观锁环境中，会增加并发用户读取对象的次数。

选择策略

在乐观锁和悲观锁之间进行选择的标准是：冲突的频率与严重性。如果冲突很少，或者冲突的后果不会很严重，那么通常情况下应该选择乐观锁，因为它能得到更好的并发性，而且更容易实现。但是，如果冲突的结果对于用户来说痛苦的，那么就需要使用悲观策略。

乐观锁的局限是：只能在提交数据时才发现业务事务将要失败，而且在某些情况下，发现失败太迟的代价会很大。用户可能花了一个小时的时间输入一份租约的详细信息，错误太多会让用户对系统失去信心。另一个方法是使用悲观锁，它可以尽早地发现错误，但理难以编程实现，而且会降低系统的灵活性。