乐观锁和悲观锁

1.悲观锁（Pessimistic Lock）：

（1）每次拿数据的时候都会担心会被别人修改（疑心重很悲观），所以每次在拿数据的时候都会上锁。确保自己使用的过程中不会被别人访问，自己使用完后再解锁。期间需要访问该数据的都会等待。

2.乐观锁（Optimistic Lock）：
（1）每次拿数据的时候都完全不担心会被别人修改（心态好很乐观），所以每次在拿数据的时候都不会上锁。但是在更新数据的时候去判断该期间是否被别人修改过（使用版本号等机制），期间该数据可以随便被其他人读取

（2）冲突检测和数据更新(版本号机制实现)在数据表中加上一个数据版本号version字段，表示数据被修改的次数，数据被修改时version值会加1，当更新数据时，刚才读到的version值和数据库中的version值相等才可以更新。

3.乐观锁及悲观锁的应用场景
（1）什么时候使用悲观锁？
**写入频繁使用悲观锁，**如果出现大量的读取操作，每次读取的时候都会进行加锁，这样会增加大量的锁的开销，降低了系统的吞吐量。 一旦通过悲观锁锁定一个资源，那么其他需要操作该资源的使用方，只能等待直到锁被释放，好处在于可以减少并发，但是当并发量非常大的时候，由于锁消耗资源，并且可能锁定时间过长，容易导致系统性能下降，资源消耗严重。

（2）什么时候使用乐观锁？
**读取频繁使用乐观锁，**一般乐观锁只用在高并发、多读少写的场景。比如，GIT,SVN等代码版本控制管理器。

例如：A、B，同时从SVN服务器上下载了文件，当A完成提交后，此时B再提交，那么会报版本冲突，此时需要B进行版本处理合并后，再提交到服务器。这其实就是乐观锁的实现全过程。如果此时使用的是悲观锁，那么意味者所有程序员都必须一个一个等待操作提交完，才能访问文件，这是难以接受的。

总结：

锁 使用场景：乐观锁适用于写比较少的情况下，即冲突真的很少发生的时候，这样可以省去了锁的开销，加大了系统的整个吞吐量。但如果经常产生冲突，上层应用会不断的进行retry，这样反倒是降低了性能，所以这种情况下用悲观锁就比较合适。