乐观锁与悲观锁

　　为了得到最大的性能，一般数据库都有并发机制，既然是并发，不可避免的将带来数据访问的冲突。为了解决这个问题，大多数数据库采取了并发控制。乐观锁和悲观锁是并发控制常用的技术手段。下面来看看吧。

　　乐观锁，顾名思义，就是保持一种乐观精神，它假设多用户并发的事务在处理时不会彼此互相影响，各事务能够在不产生锁的情况下处理各自影响的那部分数据。在提交数据更新之前，每个事务会先检查在该事务读取数据后，有没有其他事务又修改了该数据。如果其他事务有更新的话，正在提交的事务会进行回滚。

　　

　　总结起来说，乐观锁就是一开始假设不会造成数据冲突，在最后提交的时候再进行数据冲突检测。

　　乐观锁多数用于数据争用不大、冲突较少的环境中，这种环境中，偶尔回滚事务的成本会低于读取数据时锁定数据的成本，因此可以获得比其他并发控制方法更高的吞吐量。

　　乐观锁一般可以采取版本号的方式实现，比如类似下面的一个过程：

　　1）读取需要更新的记录。

　　2）对记录进行修改，并记录下此时的版本号（version）。

　　3）提交数据更新前，再次读取该记录的版本号，与之前读取的版本号进行对比。

　　　　如果版本号不同，说明在用户更新过程中，该记录已被其他事务更新过。那么， 需要回滚或提示。

　　　　如果版本号相同，说明该记录未被更新过过。此时提交此次事务，并将版本号加1。

优点与不足：

　　乐观并发控制相信事务之间的数据竞争(data race)的概率是比较小的，因此尽可能直接做下去，直到提交的时候才去锁定，所以不会产生任何锁和死锁。但如果直接简单这么做，还是有可能会遇到不可预期的结果，例如两个事务都读取了数据库的某一行，经过修改以后写回数据库，这时就遇到了问题。

　　悲观锁，顾名思义，就是认为其他事务肯定和它存在数据竞争，所以才进行数据操作前会先上锁。

　　悲观锁可以阻止一个事务以影响其他用户的方式来修改数据。如果一个事务执行的操作都某行数据应用了锁，那只有当这个事务把锁释放，其他事务才能够执行与该锁冲突的操作。

　　悲观锁主要用于数据争用激烈的环境，以及发生并发冲突时使用锁保护数据的成本要低于回滚事务的成本的环境中。

优点与不足：

　　悲观锁实际上是“先取锁再访问”的保守策略，为数据处理的安全提供了保证。但是在效率方面，处理加锁的机制会让数据库产生额外的开销，还有增加产生死锁的机会；另外，在只读型事务处理中由于不会产生冲突，也没必要使用锁，这样做只能增加系统负载；还有会降低了并行性，一个事务如果锁定了某行数据，其他事务就必须等待该事务处理完才可以处理那行数据。

参考：

https://zh.wikipedia.org/wiki/%E4%B9%90%E8%A7%82%E5%B9%B6%E5%8F%91%E6%8E%A7%E5%88%B6

https://zh.wikipedia.org/wiki/%E6%82%B2%E8%A7%82%E5%B9%B6%E5%8F%91%E6%8E%A7%E5%88%B6