關於樂觀鎖和悲觀鎖面試官會問些什麼？

時間 2019-11-07

標籤關於樂觀悲觀面試什麼欄目快樂工作简体版

原文原文鏈接

前言

樂觀鎖和悲觀鎖問題，是出現頻率比較高的面試題。本文將由淺入深，逐步介紹它們的基本概念、實現方式(含實例)、適用場景，以及可能遇到的面試官追問，但願可以幫助你打動面試官。java

1、基本概念

樂觀鎖和悲觀鎖是兩種思想，用於解決併發場景下的數據競爭問題。面試

樂觀鎖：樂觀鎖在操做數據時很是樂觀，認爲別人不會同時修改數據。所以樂觀鎖不會上鎖，只是在執行更新的時候判斷一下在此期間別人是否修改了數據：若是別人修改了數據則放棄操做，不然執行操做。數據庫

悲觀鎖：悲觀鎖在操做數據時比較悲觀，認爲別人會同時修改數據。所以操做數據時直接把數據鎖住，直到操做完成後纔會釋放鎖；上鎖期間其餘人不能修改數據。編程

2、實現方式(含實例)

在說明實現方式以前，須要明確：樂觀鎖和悲觀鎖是兩種思想，它們的使用是很是普遍的，不侷限於某種編程語言或數據庫。安全

悲觀鎖的實現方式是加鎖，加鎖既能夠是對代碼塊加鎖（如Java的synchronized關鍵字），也能夠是對數據加鎖（如MySQL中的排它鎖）。併發

樂觀鎖的實現方式主要有兩種：CAS機制和版本號機制，下面詳細介紹。編程語言

一、CAS（Compare And Swap）

CAS操做包括了3個操做數：ide

須要讀寫的內存位置(V)源碼分析
進行比較的預期值(A)性能
擬寫入的新值(B)

CAS操做邏輯以下：若是內存位置V的值等於預期的A值，則將該位置更新爲新值B，不然不進行任何操做。許多CAS的操做是自旋的：若是操做不成功，會一直重試，直到操做成功爲止。

這裏引出一個新的問題，既然CAS包含了Compare和Swap兩個操做，它又如何保證原子性呢？答案是：CAS是由CPU支持的原子操做，其原子性是在硬件層面進行保證的。

下面以Java中的自增操做(i++)爲例，看一下悲觀鎖和CAS分別是如何保證線程安全的。咱們知道，在Java中自增操做不是原子操做，它實際上包含三個獨立的操做：

讀取i值；
加1；
將新值寫回i

所以，若是併發執行自增操做，可能致使計算結果的不許確。在下面的代碼示例中：value1沒有進行任何線程安全方面的保護，value2使用了樂觀鎖(CAS)，value3使用了悲觀鎖(synchronized)。

運行程序，使用1000個線程同時對value一、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;
        }
    }
}
複製代碼

源碼分析說明以下：

getAndIncrement()實現的自增操做是自旋CAS操做：在循環中進行compareAndSet，若是執行成功則退出，不然一直執行。
其中compareAndSet是CAS操做的核心，它是利用Unsafe對象實現的。
Unsafe又是何許人也呢？Unsafe是用來幫助Java訪問操做系統底層資源的類（如能夠分配內存、釋放內存），經過Unsafe，Java具備了底層操做能力，能夠提高運行效率；強大的底層資源操做能力也帶來了安全隱患(類的名字Unsafe也在提醒咱們這一點)，所以正常狀況下用戶沒法使用。AtomicInteger在這裏使用了Unsafe提供的CAS功能。
valueOffset能夠理解爲value在內存中的偏移量，對應了CAS三個操做數(V/A/B)中的V；偏移量的得到也是經過Unsafe實現的。
value域的volatile修飾符：Java併發編程要保證線程安全，須要保證原子性、可視性和有序性；CAS操做能夠保證原子性，而volatile能夠保證可視性和必定程度的有序性；在AtomicInteger中，volatile和CAS一塊兒保證了線程安全性。關於volatile做用原理的說明涉及到Java內存模型(JMM)，這裏不詳細展開。

說完了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);
}
複製代碼