樂觀鎖和悲觀鎖問題,是出現頻率比較高的面試題。本文將由淺入深,逐步介紹它們的基本概念、實現方式(含實例)、適用場景,以及可能遇到的面試官追問,希望能夠幫助你打動面試官。
一、基本概念
四、面試官追問:樂觀鎖加鎖嗎?
樂觀鎖和悲觀鎖是兩種思想,用於解決並發場景下的數據競爭問題。
樂觀鎖:樂觀鎖在操作數據時非常樂觀,認為別人不會同時修改數據。因此樂觀鎖不會上鎖,只是在執行更新的時候判斷一下在此期間別人是否修改了數據:如果別人修改了數據則放棄操作,否則執行操作。
悲觀鎖:悲觀鎖在操作數據時比較悲觀,認為別人會同時修改數據。因此操作數據時直接把數據鎖住,直到操作完成後才會釋放鎖;上鎖期間其他人不能修改數據。
在說明實現方式之前,需要明確:樂觀鎖和悲觀鎖是兩種思想,它們的使用是非常廣泛的,不侷限於某種編程語言或資料庫。
悲觀鎖的實現方式是加鎖,加鎖既可以是對代碼塊加鎖(如Java的synchronized關鍵字),也可以是對數據加鎖(如MySQL中的排它鎖)。
樂觀鎖的實現方式主要有兩種:CAS機制和版本號機制,下面詳細介紹。
CAS操作包括了3個操作數:
CAS操作邏輯如下:如果內存位置V的值等於預期的A值,則將該位置更新為新值B,否則不進行任何操作。許多CAS的操作是自旋的:如果操作不成功,會一直重試,直到操作成功為止。
這裡引出一個新的問題,既然CAS包含了Compare和Swap兩個操作,它又如何保證原子性呢?答案是:CAS是由CPU支持的原子操作,其原子性是在硬體層面進行保證的。
下面以Java中的自增操作(i++)為例,看一下悲觀鎖和CAS分別是如何保證線程安全的。我們知道,在Java中自增操作不是原子操作,它實際上包含三個獨立的操作:
因此,如果並發執行自增操作,可能導致計算結果的不準確。在下面的代碼示例中:value1沒有進行任何線程安全方面的保護,value2使用了樂觀鎖(CAS),value3使用了悲觀鎖(synchronized)。
運行程序,使用1000個線程同時對value1、value2和value3進行自增操作,可以發現:value2和value3的值總是等於1000,而value1的值常常小於1000。
public class Test {
//value1:線程不安全 private static int value1 = 0; //value2:使用樂觀鎖 private static AtomicInteger value2 = new AtomicInteger(0); //value3:使用悲觀鎖 private static int value3 = 0; private static synchronized void increaseValue3(){ value3++; }
public static void main(String[] args) throws Exception { //開啟1000個線程,並執行自增操作 for(int i = 0; i < 1000; ++i){ new Thread(new Runnable() { @Override public void run() { try { Thread.sleep(100); } catch (InterruptedException e) { e.printStackTrace(); } value1++; value2.getAndIncrement(); increaseValue3(); } }).start(); } //列印結果 Thread.sleep(1000); System.out.println("線程不安全:" + value1); System.out.println("樂觀鎖(AtomicInteger):" + value2); System.out.println("悲觀鎖(synchronized):" + value3); } }
首先來介紹AtomicInteger。AtomicInteger是java.util.concurrent.atomic包提供的原子類,利用CPU提供的CAS操作來保證原子性;除了AtomicInteger外,還有AtomicBoolean、AtomicLong、AtomicReference等眾多原子類。
下面看一下AtomicInteger的源碼,瞭解下它的自增操作getAndIncrement()是如何實現的(源碼以Java7為例,Java8有所不同,但思想類似)。
public class AtomicInteger extends Number implements java.io.Serializable { //存儲整數值,volatile保證可視性 private volatile int value; //Unsafe用於實現對底層資源的訪問 private static final Unsafe unsafe = Unsafe.getUnsafe();
//valueOffset是value在內存中的偏移量 private static final long valueOffset; //通過Unsafe獲得valueOffset static { try { valueOffset = unsafe.objectFieldOffset(AtomicInteger.class.getDeclaredField("value")); } catch (Exception ex) { throw new Error(ex); } }
public final boolean compareAndSet(int expect, int update) { return unsafe.compareAndSwapInt(this, valueOffset, expect, update); }
public final int getAndIncrement() { for (;;) { int current = get(); int next = current + 1; if (compareAndSet(current, next)) return current; } } }
源碼分析說明如下:
說完了AtomicInteger,再說synchronized。synchronized通過對代碼塊加鎖來保證線程安全:在同一時刻,只能有一個線程可以執行代碼塊中的代碼。synchronized是一個重量級的操作,不僅是因為加鎖需要消耗額外的資源,還因為線程狀態的切換會涉及操作系統核心態和用戶態的轉換;不過隨著JVM對鎖進行的一系列優化(如自旋鎖、輕量級鎖、鎖粗化等),synchronized的性能表現已經越來越好。
除了CAS,版本號機制也可以用來實現樂觀鎖。版本號機制的基本思路是在數據中增加一個欄位version,表示該數據的版本號,每當數據被修改,版本號加1。當某個線程查詢數據時,將該數據的版本號一起查出來;當該線程更新數據時,判斷當前版本號與之前讀取的版本號是否一致,如果一致才進行操作。
需要注意的是,這裡使用了版本號作為判斷數據變化的標記,實際上可以根據實際情況選用其他能夠標記數據版本的欄位,如時間戳等。
下面以「更新玩家金幣數」為例(資料庫為MySQL,其他資料庫同理),看看悲觀鎖和版本號機制是如何應對並發問題的。
考慮這樣一種場景:遊戲系統需要更新玩家的金幣數,更新後的金幣數依賴於當前狀態(如金幣數、等級等),因此更新前需要先查詢玩家當前狀態。
下面的實現方式,沒有進行任何線程安全方面的保護。如果有其他線程在query和update之間更新了玩家的信息,會導致玩家金幣數的不準確。
@Transactional public 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,會被阻塞
@Transactional public 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變化,則不進行更新。
@Transactional public 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} where player_id = {1} and version = {2}", newCoins, playerId, player.version); }
樂觀鎖和悲觀鎖並沒有優劣之分,它們有各自適合的場景;下面從兩個方面進行說明。
與悲觀鎖相比,樂觀鎖適用的場景受到了更多的限制,無論是CAS還是版本號機制。
例如,CAS只能保證單個變數操作的原子性,當涉及到多個變數時,CAS是無能為力的,而synchronized則可以通過對整個代碼塊加鎖來處理。再比如版本號機制,如果query的時候是針對錶1,而update的時候是針對錶2,也很難通過簡單的版本號來實現樂觀鎖。
如果悲觀鎖和樂觀鎖都可以使用,那麼選擇就要考慮競爭的激烈程度:
筆者在面試時,曾遇到面試官如此追問。下面是我對這個問題的理解:
面試到這裡,面試官可能已經中意你了。不過面試官準備對你發起最後的進攻:你知道CAS這種實現方式有什麼缺點嗎?
下面是CAS一些不那麼完美的地方:
假設有兩個線程——線程1和線程2,兩個線程按照順序進行以下操作:
在第(4)步中,由於內存中數據仍然為A,因此CAS操作成功,但實際上該數據已經被線程2修改過了。這就是ABA問題。
在AtomicInteger的例子中,ABA似乎沒有什麼危害。但是在某些場景下,ABA卻會帶來隱患,例如棧頂問題:一個棧的棧頂經過兩次(或多次)變化又恢復了原值,但是棧可能已發生了變化。
對於ABA問題,比較有效的方案是引入版本號,內存中的值每發生一次變化,版本號都+1;在進行CAS操作時,不僅比較內存中的值,也會比較版本號,只有當二者都沒有變化時,CAS才能執行成功。Java中的AtomicStampedReference類便是使用版本號來解決ABA問題的。
在並發衝突概率大的高競爭環境下,如果CAS一直失敗,會一直重試,CPU開銷較大。針對這個問題的一個思路是引入退出機制,如重試次數超過一定閾值後失敗退出。當然,更重要的是避免在高競爭環境下使用樂觀鎖。
CAS的功能是比較受限的,例如CAS只能保證單個變數(或者說單個內存值)操作的原子性,這意味著:(1)原子性不一定能保證線程安全,例如在Java中需要與volatile配合來保證線程安全;(2)當涉及到多個變數(內存值)時,CAS也無能為力。
除此之外,CAS的實現需要硬體層面處理器的支持,在Java中普通用戶無法直接使用,只能藉助atomic包下的原子類使用,靈活性受到限制。
本文介紹了樂觀鎖和悲觀鎖的基本概念、實現方式(含實例)、適用場景,以及可能遇到的面試官追問,希望能夠對你面試有幫助。最後,祝大家都拿到心儀的offer!
以下最新總結的阿里P6資深Java必考題範圍和答案,包含最全MySQL、Redis、Java並發編程等等面試題和答案,用於參考~
資料獲取方式:點贊+關注後臺私信我【面試】即可免費獲取!
部分資料截圖