乐观锁和悲观锁的原理与应用

乐观锁和悲观锁的原理与使用

名称	描述	应用场景
乐观锁	每次拿数据都认为不会修改,不上锁,但是更新的时候会判断在此期间别人有没有去更新这个数据	版本号或时间戳控制,适用于高并发,读多写少的场景
悲观锁	每次拿数据都认为会修改,所以每次拿数据的时候都会上锁,只有等待锁标记释放,之后才能拿到数据	DDB的行锁,表锁等,适用于数据一致性比较高的场景，能够减少并发

什么时候使用乐观锁?

​ 资源提交冲突，其他使用方需要重新读取资源，会增加读的次数，但是可以面对高并发场景，前提是如果出现提交失败，用户是可以接受的。因此一般乐观锁只用在高并发、读多写少的场景。
​ 其中：GIT,SVN,CVS等代码版本控制管理器，就是一个乐观锁使用很好的场景，例如：A、B程序员，同时从SVN服务器上下载了code.html文件，当A完成提交后，此时B再提交，那么会报版本冲突，此时需要B进行版本处理合并后，再提交到服务器。这其实就是乐观锁的实现全过程。如果此时使用的是悲观锁，那么意味者所有程序员都必须一个一个等待操作提交完，才能访问文件，这是难以接受的。

什么时候使用悲观锁?

​ 一旦通过悲观锁锁定一个资源，那么其他需要操作该资源的使用方，只能等待直到锁被释放，好处在于可以减少并发，但是当并发量非常大的时候，由于锁消耗资源，并且可能锁定时间过长。容易导致系统性能下降，资源消耗严重。因此一般我们可以在并发量不是很大，并且出现并发情况导致的异常用户和系统都很难以接受的情况下，会选择悲观锁进行。

	优点	缺点
乐观锁	提高了吞吐量,性能和效率高，适用于并发量高，多读少写的场景	资源提交冲突，其他使用方需要重新读取资源，会增加读的次数。
悲观锁	提高数据处理的安全性，适用于多写场景，	会让数据库产生额外的开销，还有增加产生死锁的机会，降低并行性。

总结

1.乐观锁

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

2.悲观锁

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