【BAT面试题系列】面试官:你了解乐观锁和悲观锁吗?

前言乐观锁和悲观锁问题,是出现频率比较高的面试题。
本文将由浅入深,逐步介绍它们的基本概念、实现方式(含实例)、适用场景,以及可能遇到的面试官追问,希望能够帮助你打动面试官。
目录一、基本概念二、实现方式(含实例)      1、CAS(Compare And Swap)      2、版本号机制三、优缺点和适用场景四、面试官追问:乐观锁加锁吗?五、面试官追问:CAS有哪些缺点?六、总结一、基本概念乐观锁和悲观锁是两种思想,用于解决并发场景下的数据竞争问题。
乐观锁:乐观锁在操作数据时非常乐观,认为别人不会同时修改数据。
因此乐观锁不会上锁,只是在执行更新的时候判断一下在此期间别人是否修改了数据:如果别人修改了数据则放弃操作,否则执行操作。
悲观锁:悲观锁在操作数据时比较悲观,认为别人会同时修改数据。
因此操作数据时直接把数据锁住,直到操作完成后才会释放锁;上锁期间其他人不能修改数据。
二、实现方式(含实例)在说明实现方式之前,需要明确:乐观锁和悲观锁是两种思想,它们的使用是非常广泛的,不局限于某种编程语言或数据库。
悲观锁的实现方式是加锁,加锁既可以是对代码块加锁(如Java的synchronized关键字),也可以是对数据加锁(如MySQL中的排它锁)。
乐观锁的实现方式主要有两种:CAS机制和版本号机制,下面详细介绍。
1、CAS(Compare And Swap)CAS操作包括了3个操作数:需要读写的内存位置(V)进行比较的预期值(A)拟写入的新值(B)CAS操作逻辑如下:如果内存位置V的值等于预期的A值,则将该位置更新为新值B,否则不进行任何操作。
许多CAS的操作是自旋的:如果操作不成功,会一直重试,直到操作成功为止。
这里引出一个新的问题,既然CAS包含了Compare和Swap两个操作,它又如何保证原子性呢?答案是:CAS是由CPU支持的原子操作,其原子性是在硬件层面进行保证的。
2、版本号机制除了CAS,版本号机制也可以用来实现乐观锁。
版本号机制的基本思路是在数据中增加一个字段version,表示该数据的版本号,每当数据被修改,版本号加1。
当某个线程查询数据时,将该数据的版本号一起查出来;当该线程更新数据时,判断当前版本号与之前读取的版本号是否一致,如果一致才进行操作。
需要注意的是,这里使用了版本号作为判断数据变化的标记,实际上可以根据实际情况选用其他能够标记数据版本的字段,如时间戳等。
下面以“更新玩家金币数”为例(数据库为MySQL,其他数据库同理),看看悲观锁和版本号机制是如何应对并发问题的。
考虑这样一种场景:游戏系统需要更新玩家的金币数,更新后的金币数依赖于当前状态(如金币数、等级等),因此更新前需要先查询玩家当前状态。
下面的实现方式,没有进行任何线程安全方面的保护。
如果有其他线程在query和update之间更新了玩家的信息,会导致玩家金币数的不准确。
@Transactionalpublic void updateCoins(Integer playerId){    //根据player_id查询玩家信息    Player player = query("select coins, level from player where player_id = {0}", playerId);    //根据玩家当前信息及其他信息,计算新的金币数    Long newCoins = ……;    //更新金币数    update("update player set coins = {0} where player_id = {1}", newCoins, playerId);}为了避免这个问题,悲观锁通过加锁解决这个问题,代码如下所示。
在查询玩家信息时,使用select …… for update进行查询;该查询语句会为该玩家数据加上排它锁,直到事务提交或回滚时才会释放排它锁;在此期间,如果其他线程试图更新该玩家信息或者执行select for update,会被阻塞。
@Transactionalpublic void updateCoins(Integer playerId){    //根据player_id查询玩家信息(加排它锁)    Player player = queryForUpdate("select coins, level from player where player_id = {0} for update", playerId);    //根据玩家当前信息及其他信息,计算新的金币数    Long newCoins = ……;    //更新金币数    update("update player set coins = {0} where player_id = {1}", newCoins, playerId);}版本号机制则是另一种思路,它为玩家信息增加一个字段:version。
在初次查询玩家信息时,同时查询出version信息;在执行update操作时,校验version是否发生了变化,如果version变化,则不进行更新。
@Transactionalpublic void updateCoins(Integer playerId){    //根据player_id查询玩家信息,包含version信息    Player player = query("select coins, level, version from player where player_id = {0}", playerId);    //根据玩家当前信息及其他信息,计算新的金币数    Long newCoins = ……;    //更新金币数,条件中增加对version的校验    update("update player set coins = {0}, version = version + 1 where player_id = {1} and version = {2}", newCoins, playerId, player.version);}三、优缺点和适用场景乐观锁和悲观锁并没有优劣之分,它们有各自适合的场景;下面从两个方面进行说明。
1、功能限制与悲观锁相比,乐观锁适用的场景受到了更多的限制,无论是CAS还是版本号机制。
例如,CAS只能保证单个变量操作的原子性,当涉及到多个变量时,CAS是无能为力的,而synchronized则可以通过对整个代码块加锁来处理。
再比如版本号机制,如果query的时候是针对表1,而update的时候是针对表2,也很难通过简单的版本号来实现乐观锁。
2、竞争激烈程度如果悲观锁和乐观锁都可以使用,那么选择就要考虑竞争的激烈程度:当竞争不激烈 (出现并发冲突的概率小)时,乐观锁更有优势,因为悲观锁会锁住代码块或数据,其他线程无法同时访问,影响并发,而且加锁和释放锁都需要消耗额外的资源。
当竞争激烈(出现并发冲突的概率大)时,悲观锁更有优势,因为乐观锁在执行更新时频繁失败,需要不断重试,浪费CPU资源。
四、面试官追问:乐观锁加锁吗?笔者在面试时,曾遇到面试官如此追问。
下面是我对这个问题的理解:(1)乐观锁本身是不加锁的,只是在更新时判断一下数据是否被其他线程更新了;AtomicInteger便是一个例子。
(2)有时乐观锁可能与加锁操作合作,例如,在前述updateCoins()的例子中,MySQL在执行update时会加排它锁。
但这只是乐观锁与加锁操作合作的例子,不能改变“乐观锁本身不加锁”这一事实。
五、面试官追问:CAS有哪些缺点?面试到这里,面试官可能已经中意你了。
不过面试官准备对你发起最后的进攻:你知道CAS这种实现方式有什么缺点吗?下面是CAS一些不那么完美的地方:1、ABA问题假设有两个线程——线程1和线程2,两个线程按照顺序进行以下操作:(1)线程1读取内存中数据为A;(2)线程2将该数据修改为B;(3)线程2将该数据修改为A;(4)线程1对数据进行CAS操作在第(4)步中,由于内存中数据仍然为A,因此CAS操作成功,但实际上该数据已经被线程2修改过了。
这就是ABA问题。
在AtomicInteger的例子中,ABA似乎没有什么危害。
但是在某些场景下,ABA却会带来隐患,例如栈顶问题:一个栈的栈顶经过两次(或多次)变化又恢复了原值,但是栈可能已发生了变化。
对于ABA问题,比较有效的方案是引入版本号,内存中的值每发生一次变化,版本号都+1;在进行CAS操作时,不仅比较内存中的值,也会比较版本号,只有当二者都没有变化时,CAS才能执行成功。
Java中的AtomicStampedReference类便是使用版本号来解决ABA问题的。
2、高竞争下的开销问题在并发冲突概率大的高竞争环境下,如果CAS一直失败,会一直重试,CPU开销较大。
针对这个问题的一个思路是引入退出机制,如重试次数超过一定阈值后失败退出。
当然,更重要的是避免在高竞争环境下使用乐观锁。
3、功能限制CAS的功能是比较受限的,例如CAS只能保证单个变量(或者说单个内存值)操作的原子性,这意味着:(1)原子性不一定能保证线程安全,例如在Java中需要与volatile配合来保证线程安全;(2)当涉及到多个变量(内存值)时,CAS也无能为力。
除此之外,CAS的实现需要硬件层面处理器的支持,在Java中普通用户无法直接使用,只能借助atomic包下的原子类使用,灵活性受到限制。
六、总结本文介绍了乐观锁和悲观锁的基本概念、实现方式(含实例)、适用场景,以及可能遇到的面试官追问,希望能够对你面试有帮助。
最后,祝大家都拿到心仪的offer!

返回列表
上一篇:
下一篇: