乐观锁和悲观锁能够解决什么问题?
并发场景下,有序地更新某条记录。
什么是乐观锁,什么是悲观锁?
乐观锁:乐观锁在操作数据时非常乐观,认为别人不会同时修改数据。
因此乐观锁不会上锁,只是在执行更新的时候判断一下在此期间别人是否修改了数据:如果别人修改了数据则放弃操作,否则执行操作。
悲观锁:悲观锁在操作数据时比较悲观,认为别人会同时修改数据。
因此操作数据时直接把数据锁住,直到操作完成后才会释放锁;上锁期间其他人不能修改数据。
两种锁的应该如何实现?
乐观锁的实现方式主要有两种:CAS机制和版本号机制
CAS:(Compare And Swap)
CAS操作包括了3个操作数:
1) 需要读写的内存位置(V)
2) 进行比较的预期值(A)
3) 拟写入的新值(B)
操作逻辑如下:
如果内存位置V的值等于预期的A值,则将该位置更新为新值B,否则不进行任何操作。
许多CAS的操作是自旋的:如果操作不成功,会一直重试,直到操作成功为止。
这里引出一个新的问题,既然CAS包含了Compare和Swap两个操作,它又如何保证原子性呢?
答案是:CAS是由CPU支持的原子操作,其原子性是在硬件层面进行保证的。
注意:Java中的自增操作
(i++)
在并发场景下就不能百分百得到准确的结果,因为它并不是原子操作。在并发场景下应该使用
AtomicInteger
进行自增操作,其内部也是靠CAS乐观锁实现的顺序自增。
版本号机制(Version)
版本号机制的基本思路是在数据中增加一个字段version,表示该数据的版本号,每当数据被修改,版本号加1。
- 当某个线程查询数据时,将该数据的版本号一起查出来;
- 当该线程更新数据时,判断当前版本号与之前读取的版本号是否一致,如果一致才进行操作。
需要注意的是,这里使用了版本号作为判断数据变化的标记,实际上可以根据实际情况选用其他能够标记数据版本的字段,如时间戳等。
悲观锁的两种实现:synchronized和select…for update
代码实现悲观锁:synchronized
synchronized通过对代码块加锁来保证线程安全:在同一时刻,只能有一个线程可以执行代码块中的代码。
synchronized是一个重量级的操作,不仅是因为加锁需要消耗额外的资源,还因为线程状态的切换会涉及操作系统核心态和用户态的转换;
不过随着JVM对锁进行的一系列优化(如自旋锁、轻量级锁、锁粗化等),synchronized的性能表现已经越来越好。
sql实现悲观锁select…for update
该查询语句会为该行记录加上排它锁,直到事务提交或回滚时才会释放排它锁;
在此期间,如果其他事务只能对该行记录执行查询操作,如果更新该行记录信息或者执行select for update,会被阻塞。
ps:用select for update一定要跟上where id = ? 的条件,id字段一定是主键或者唯一索引,不然会导致锁全表,后果很严重!
分析一下两种锁的优劣势?
乐观锁
优势:
- 轻量级锁,避免了线程切换的开销。
劣势:
- 会有ABA问题
假设有两个线程——线程1和线程2,两个线程按照顺序进行以下操作
(1)线程1读取内存中数据为A;
(2)线程2将该数据修改为B;
(3)线程2将该数据修改为A;
(4)线程1对数据进行CAS操作
在第(4)步中,由于内存中数据仍然为A,因此CAS操作成功,但实际上该数据已经被线程2修改过了。这就是ABA问题。
-
只能对单一变量加锁
-
自旋操作导致额外开销
悲观锁
优势:
- 因为锁的是代码块,可以锁住多个变量。
劣势:
- 重量级锁,加锁、释放锁操作会有开销,而且操作系统层面的上下文切换和线程调度也会引起很大的开销。
- 一个线程持有锁会导致其它所有需要此锁的线程挂起。
不同场景如何选型乐观锁和悲观锁?
高并发高竞争下,为了避免重试开销,直接选用悲观锁。
比如火车票订票,在屏幕上显示有票,而真正进行出票时,需要重新确定一下这个数据没有被其他客户端修改。所以,在这个确认过程中,可以使用for update。
并发情况不激烈,偶尔解决并发问题,选择性能消耗小的乐观锁。