一、乐观锁和悲观锁的策略
1.悲观锁(一般都是通过锁机制来实现的)
(1)每次去拿数据都会认为别人会修改,所以每次拿数据的时候都会上锁。比如:行锁,表锁等,读锁,写锁等,都是在做操作之前先上锁。再比如Java里面的同步原语synchronized关键字的实现也是悲观锁。
2.乐观锁
(1)每次去拿数据的时候都认为别人不会修改,所以不会上锁,但是在更新的时候会判断一下在此期间别人有没有去更新这个数据,如果发生冲突了,则返回用户的错误信息,让用户决定如何去做。(适用于多读的类型,并发大的情况。一般基于数据版本号实现)
(2)冲突检测和数据更新(版本号机制实现)
在数据表中加上一个数据版本号version字段,表示数据被修改的次数,数据被修改时version值会加1,当更新数据时,刚才读到的version值和数据库中的version值相等才可以更新。
update table set x=x+1, version=version+1 where id=#{id} and version=#{version};
(3)CAS(compare and swap)实现
多个线程尝试使用CAS同时更新同一个变量时,只有其中一个线程能更新值,其他的线程失败,但不会被挂起,而是被告知这次竞争失败,并可以再次尝试。
CAS 操作原理:
CAS 操作中包含三个操作数 —— 需要读写的内存位置(V)、进行比较的预期原值(A)和拟写入的新值(B)。如果内存位置V的值与预期原值A相匹配,那么处理器会自动将该位置值更新为新值B。否则处理器不做任何操作。无论哪种情况,它都会在 CAS 指令之前返回该位置的值。
二、乐观锁及悲观锁的应用场景
1.什么时候使用悲观锁?
写入频繁使用悲观锁,如果出现大量的读取操作,每次读取的时候都会进行加锁,这样会增加大量的锁的开销,降低了系统的吞吐量。
一旦通过悲观锁锁定一个资源,那么其他需要操作该资源的使用方,只能等待直到锁被释放,好处在于可以减少并发,但是当并发量非常大的时候,由于锁消耗资源,并且可能锁定时间过长,容易导致系统性能下降,资源消耗严重。
2.什么时候使用乐观锁?
读取频繁使用乐观锁,一般乐观锁只用在高并发、多读少写的场景。比如,GIT,SVN,CVS等代码版本控制管理器。
例如:A、B,同时从SVN服务器上下载了hello.java文件,当A完成提交后,此时B再提交,那么会报版本冲突,此时需要B进行版本处理合并后,再提交到服务器。这其实就是乐观锁的实现全过程。如果此时使用的是悲观锁,那么意味者所有程序员都必须一个一个等待操作提交完,才能访问文件,这是难以接受的。