乐观锁和悲观锁的原理及应用场景

1.乐观锁和悲观锁概念

1.1 悲观锁

每次去拿数据都会认为别人会修改，所以每次拿数据的时候都会上锁。比如：行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁。再比如Java里面的同步原语synchronized关键字的实现也是悲观锁。

1.2 乐观锁

1. 每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，如果发生冲突了，则返回用户的错误信息，让用户决定如何去做。（适用于多读的类型，并发大的情况。一般基于数据版本号实现）
2. 冲突检测和数据更新(版本号机制实现)
   在数据表中加上一个数据版本号version字段，表示数据被修改的次数，数据被修改时version值会加1，当更新数据时，刚才读到的version值和数据库中的version值相等才可以更新。

3. CAS（compare and swap）实现
   多个线程尝试使用CAS同时更新同一个变量时，只有其中一个线程能更新值，其他的线程失败，但不会被挂起，而是被告知这次竞争失败，并可以再次尝试。

   CAS 操作原理:
   CAS 操作中包含三个操作数 —— 需要读写的内存位置（V）、进行比较的预期原值（A）和拟写入的新值(B)。如果内存位置V的值与预期原值A相匹配，那么处理器会自动将该位置值更新为新值B。否则处理器不做任何操作。无论哪种情况，它都会在 CAS 指令之前返回该位置的值。
    

2.乐观锁和悲观锁的应用场景

2.1 悲观锁应用场景

写入频繁使用悲观锁，如果出现大量的读取操作，每次读取的时候都会进行加锁，这样会增加大量的锁的开销，降低了系统的吞吐量。

一旦通过悲观锁锁定一个资源，那么其他需要操作该资源的使用方，只能等待直到锁被释放，好处在于可以减少并发，但是当并发量非常大的时候，由于锁消耗资源，并且可能锁定时间过长，容易导致系统性能下降，资源消耗严重。

2.2 乐观锁应用场景

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

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