何谓悲观锁与乐观锁
乐观锁对应于生活中乐观的人总是想着事情往好的方向发展,悲观锁对应于生活中悲观的人总是想着事情往坏的方向发展。这两种人各有优缺点,不能不以场景而定说一种人好于另外一种人。
悲观锁
总是假设最坏的情况,每次去拿数据的时候都认为别人会修改,所以每次在拿数据的时候都会上锁,这样别人想拿这个数据就会阻塞直到它拿到锁(共享资源每次只给一个线程使用,其它线程阻塞,用完后再把资源转让给其它线程)。传统的关系型数据库里边就用到了很多这种锁机制,比如行锁,表锁等,读锁,写锁等,都是在做操作之前先上锁。Java中synchronized和ReentrantLock等独占锁就是悲观锁思想的实现。
乐观锁
总是假设最好的情况,每次去拿数据的时候都认为别人不会修改,所以不会上锁,但是在更新的时候会判断一下在此期间别人有没有去更新这个数据,可以使用版本号机制和CAS算法实现。乐观锁适用于多读的应用类型,这样可以提高吞吐量,像数据库提供的类似于write_condition机制,其实都是提供的乐观锁。在Java中java.util.concurrent.atomic包下面的原子变量类就是使用了乐观锁的一种实现方式CAS实现的。
两种锁的使用场景
从上面对两种锁的介绍,我们知道两种锁各有优缺点,不可认为一种好于另一种,像乐观锁适用于写比较少的情况下(多读场景),即冲突真的很少发生的时候,这样可以省去了锁的开销,加大了系统的整个吞吐量。但如果是多写的情况,一般会经常产生冲突,这就会导致上层应用会不断的进行retry,这样反倒是降低了性能,所以一般多写的场景下用悲观锁就比较合适。
---------------------
在高并发下,经常需要处理SELECT之后,在业务层处理逻辑,再执行UPDATE的情况。
若两个连接并发查询同一条数据,然后在执行一些逻辑判断或业务操作后,执行UPDATE,可能出现与预期不相符的结果。
在不使用悲观锁与复杂SQL的前提下,可以使用乐观锁处理该问题,同时兼顾性能。
场景模拟:
假设一张表两个字段,一个id,一个use_count。表里存了100个id,每个id对应自己的use_count。
当id每使用一次,use_count要加1。当use_count大于1000时,这个id就不能在被使用了(换句话说 无法从数据库中查出)。
在高并发情况下,会遇到一种问题:假设数据表中有一条记录为:id=123456, use_count=999 A与B两个连接并发查询这个id=123456,都执行下列SQL:
1 | SELECT * FROM table WHERE id=123456 and use_count < 1000; |
A先执行,得到id=123456的use_count是999,之后在程序里做了一些逻辑判断或业务操作后执行SQL:
1 | UPDATE table SET use_count + 1 WHERE id=123456; |
在A做判断且没有update之前,B也执行了查询SQL,发现use_count是999,之后它也会执行SQL:
1 | UPDATE table SET use_count + 1 WHERE id=123456; |
但是,事实上B不应该取得这个id,因为A已经是第1000个使用者。
处理步骤如下:
1、添加第3个字段version,int类型,default值为0。version值每次update时作加1处理。
1 | ALTER TABLE table ADD COLUMN version INT DEFAULT '0' NOT NULL AFTER use_count; |
2、SELECT时同时获取version值(例如为3)。
1 | SELECT use_count, version FROM table WHERE id=123456 AND use_count < 1000; |
3、UPDATE时检查version值是否为第2步获取到的值。
1 | UPDATE table SET version=4, use_count=use_count+1 WHERE id=123456 AND version=3; |
如果UPDATE的记录数为1,则表示成功。如果UPDATE的记录数为0,则表示已经被其他连接UPDATE过了,需作异常处理。
联系客服