面試再被問到 Java 多線程安全問題,就這麼回答他!

公衆號後臺回覆“學習”,免費獲取精品學習資料

掃描下方海報 試聽

本文來源:

51CTO技術棧

談到 Java 的多線程編程,一定繞不開線程的安全性,線程安全又包括原子性,可見性和有序性等特性。今天,我們就來看看他們之間的關聯和實現原理。

線程與競態

開發的應用程序會在一個進程中運行,換句話說進程就是程序的運行實例。運行一個 Java 程序的實質就是運行了一個 Java 虛擬機進程。

如果說一個進程可以包括多個線程,並且這些線程會共享進程中的資源。任何一段代碼會運行在一個線程中,也運行在多個線程中。線程所要完成的計算被稱爲任務。

爲了提高程序的效率,我們會生成多個任務一起工作,這種工作模式有可能是並行的,A 任務在執行的時候,B 任務也在執行。

如果多個任務(線程)在執行過程中,操作相同的資源(變量),這個資源(變量)被稱爲共享資源(變量)。

當多個線程同時對共享資源進行操作時,例如:寫資源,就會出現競態,它會導致被操作的資源在不同時間看到的結果不同。

來看看多個線程訪問相同的資源/變量的例子如下:

當線程 A 和 B 同時執行 Counter 對象中的 add() 方法時,在無法知道兩個線程如何切換的情況下,JVM 會按照下面的順序來執行代碼:

  • 從內存獲取 this.count 的值放到寄存器。

  • 將寄存器中的值增加 value。

  • 將寄存器中的值寫回內存。

上面操作在線程 A 和 B 交錯執行時,會出現以下情況:

兩個線程分別加 2 和 3 到 count 變量上,我們希望的結果是,兩個線程執行後 count 的值等於 5。

但是,兩個線程交叉執行,即使兩個線程從內存中讀出的初始值都是 0,之後各自加了 2 和 3,並分別寫回內存。

然而,最終的值並不是期望的 5,而是最後寫回內存的那個線程(A 線程)的值(3)。

最後寫回內存的是線程 A 所以結果是 3,但也有可能是線程 B 最後寫回內存,所以結果是不可知的。

因此,如果沒有采用同步機制,線程間的交叉寫資源/變量,結果是不可控的。

我們把這種一個計算結果的正確性與時間有關的現象稱作競態(Race Condition)。

線程安全

前面我們談到,當多線程同時寫一個資源/變量的時候會出現競態的情況。這種情況的發生會造成,最終結果的不確定性。

如果把這個被寫的資源看成 Java 中的一個類的話,這個類不是線程安全的。

即便這個類在單線程環境下運作正常,但在多線程環境下就無法正常運行。例如:ArrayList,HashMap,SimpledateFormat。

那麼,爲了做到線程安全,需要從以下三個方面考慮,分別是:

  • 原子性

  • 可見性

  • 有序性

原子性

原子性是指某個操作或者多個操作,要麼全部執行,要麼就都不執行,不會出現中間過程。換成線程執行也一樣,線程中執行的操作要麼不執行,要麼全部執行。

例如,在 Java 中,基本數據類型讀取操作就是原子性操作,來看下面的語句:

  • x = 10

  • x = x + 1

第一句是原子性操作,因爲其直接將數值 10 賦值給 x,線程執行這個語句時直接將 10 寫到內存中。

第二句包含三個操作,讀取 x 的值,進行加 1 操作,寫入新的值。這三個操作合起來就不是原子性操作了。

Java 中的原子包括:

  • lock(鎖定)

  • unlock(解鎖)

  • read(讀取)

  • load(載入)

  • use(使用)

  • assign(賦值)

  • store(存儲)

  • write(寫入)

假設 A,B 兩個線程一起執行語句 2,同時對 x 變量進行寫操作,由於不滿足原子性操作,因此得到的結果也是不確定的。在 Java 中有兩種方式來實現原子性。一種是使用鎖(Lock)。

鎖具有排他性,在多線程訪問時,能夠保障一個共享變量在任意時刻都能夠被一個線程訪問,也就是排除了競態的可能。

另一種是利用處理器提供的 CAS(Compare-and-Swap)指令實現,它是直接在硬件(處理器和內存)這一層實現的,被稱爲“硬件鎖”。

可見性

說完了原子性,再來談談可見性。名如其意,在多線程訪問中,一個線程對某個共享變量進行更新以後,後續訪問的線程可以立即讀取更新的結果。

這種情況就稱作可見,對共享變量的更新對其他線程是可見的,否則就稱不可見。

來看看 Java 是如何實現可見性的。首先,假設線程 A 執行了一段指令,這個指令在 CPU A 中運行。

這個指令寫的共享變量會存放在 CPU A 的寄存器中。當指令執行完畢以後,會將共享變量從寄存器中寫入到內存中。

PS:實際上是通過寄存器到高速緩存,再到寫緩衝器和無序化隊列,最後寫到內存的。

這裏爲了舉例,採用了簡化的說法。這樣做的目的是,讓共享變量能夠被另外一個 CPU 中的線程訪問到。

因此,共享變量寫入到內存的行爲稱爲“沖刷處理器緩存”。也就是把共享變量從處理器緩存,沖刷到內存中。

沖刷處理器緩存

此時,線程 B 剛好運行在 CPU B 上,指令爲了獲取共享變量,需要從內存中的共享變量進行同步。

這個緩存同步的過程被稱爲,“刷新處理器緩存”。也就是從內存中刷新緩存到處理器的寄存器中。

經過這兩個步驟以後,運行在 CPU B 上的線程就能夠同步到,CPU A 上線程處理的共享變量來。也保證了共享變量的可見性。

刷新處理器緩存

有序性

說完了可見性,再來聊聊有序性。Java 編譯器針對代碼執行的順序會有調整。

它有可能改變兩個操作執行的先後順序,另外一個處理器上執行的多個操作,從其他處理器的角度來看,指令的執行順序有可能也是不一致的。

在 Java 內存模型中,允許編譯器和處理器對指令進行重排序,但是重排序過程不會影響到單線程程序的執行,卻會影響到多線程併發執行的正確性。

究其原因,編譯器出於性能的考慮,在不影響程序(單線程程序)正確性的情況下,對源代碼順序進行調整。

在 Java 中,可以通過 Volatile 關鍵字來保證“有序性”。還可以通過 Synchronized 和 Lock 來保證有序性。後面還會介紹通過內存屏障來實現有序性。

多線程同步與鎖

前面講到了線程競態和線程安全,都是圍繞多線程訪問共享變量來討論的。正因爲有這種情況出現,在進行多線程開發的時候需要解決這個問題。

爲了保障線程安全,會將多線程的併發訪問轉化成串行的訪問。鎖(Lock)就是利用這種思路來保證多線程同步的。

鎖就好像是共享數據訪問的許可證,任何線程需要訪問共享數據之前都需要獲得這個鎖。

當一個線程獲取鎖的時候,其他申請鎖的線程需要等待。獲取鎖的線程會根據線程上的任務執行代碼,執行代碼以後纔會釋放掉鎖。

在獲得鎖與釋放鎖之間執行的代碼區域被稱爲臨界區,在臨界區中訪問的數據,被稱爲共享數據。

在該線程釋放鎖以後,其他的線程才能獲得該鎖,再對共享數據進行操作。

多線程訪問臨界區,訪問共享數據

上面描述的操作也被稱爲互斥操作,鎖通過這種互斥操作來保障競態的原子性。

記得前面談到的原子性嗎?一個或者多個對共享數據的操作,要麼完成,要麼不完成,不能出現中間狀態。

假設臨界區中的代碼,並不是原子性的。例如前文提到的“x=x+1”,其中就包括了三個操作,讀取 x 的值,進行加 1 操作,寫入新的值。

如果在多線程訪問的時候,隨着運行時間的不同會得到不同的結果。如果對這個操作加上鎖,就可以使之具有“原子性”,也就是在一個線程訪問的時候其他線程無法訪問。

說完了多線程開發中鎖的重要性,再來看看 Java 有那幾種鎖。

內部鎖

內部鎖也稱作監視器(Monitor),它是通過 Synchronized 關鍵字來修飾方法及代碼塊,來製造臨界區的。

Synchronized 關鍵字可以用來修飾同步方法,同步靜態方法,同步實例方法,同步代碼塊。

Synchronized 引導的代碼塊就是上面提到的臨界區。鎖句柄就是一個對象的引用,例如:它可以寫成 this 關鍵字,就表示當前對象。

鎖句柄對應的監視器被稱爲相應同步塊的引導鎖,相應的我們稱呼相應的同步塊爲該鎖引導的同步塊。

內部鎖示意圖

鎖句柄通常採用 final 修飾(private final)。因爲鎖句柄一旦改變,會導致同一個代碼塊的多個線程使用不同的鎖,而導致競態。

同步靜態方法相當於當前類爲引導鎖的同步塊。線程在執行臨界區代碼的時候,必須持有該臨界區的引導鎖。

一旦執行完臨界區代碼,引導該臨界區的鎖就會被釋放。內部鎖申請和釋放的過程由 Java 虛擬機負責完成。

所以 Synchronized 實現的鎖被稱爲內部鎖。因此不會導致鎖泄露,Java 編譯器在將代碼塊編譯成字節碼的時候,對臨界區拋出的異常進行了處理。

Java 虛擬機會給每個內部鎖分配一個入口集(Entry Set),用於記錄等待獲取鎖的線程。申請鎖失敗的線程會在入口集中等待再次申請鎖的機會。

當等待的鎖被其他線程釋放時,入口集中的等待線程會被喚醒,獲得申請鎖的機會。

內部鎖的機制會在等待的線程中進行選擇,選擇的規則會根據線程活躍度和優先級來進行,被選中的線程會持有鎖進行後續操作。

顯示鎖

顯示鎖是 JDK 1.5 開始引入的排他鎖,作爲一種線程同步機制存在,其作用與內部鎖相同,但它提供了一些內部鎖不具備的特性。顯示鎖是 java.util.concurrent.locks.Lock 接口的實例。

顯示鎖實現的幾個步驟分別是:

  • 創建 Lock 接口實例

  • 申請顯示鎖 Lock

  • 對共享數據進行訪問

  • 在 finally 中釋放鎖,避免鎖泄漏

顯示鎖使用實例圖

顯示鎖支持非公平鎖也支持公平鎖。公平鎖中, 線程嚴格先進先出(FIFO)的順序,獲取鎖資源。

如果有“當前線程”需要獲取共享變量,需要進行排隊。當鎖被釋放,由隊列中排第一個的線程(Node1)獲取,依次類推。

公平鎖示意圖

非公平鎖中,在線程釋放鎖的時候, “當前線程“和等待隊列中的第一個線程(Node1)競爭鎖資源。通過線程活躍度和優先級來確定那個線程持有鎖資源。

非公平鎖示意圖

公平鎖保證鎖調度的公平性,但是增加了線程暫停和喚醒的可能性,即增加了上下文切換的代價。非公平鎖加入了競爭機制,會有更好的性能,能夠承載更大的吞吐量。

當然,非公平鎖讓獲取鎖的時間變得更加不確定,可能會導致在阻塞隊列中的線程長期處於飢餓狀態。

線程同步機制:內存屏障

說了多線程訪問共享變量,存在的競態問題,然後引入鎖的機制來解決這個問題。

上文提到內部鎖和顯示鎖來解決線程同步的問題,而且提到了解決了競態中“原子性”的問題。

那麼接下來,通過介紹內存屏障機制,來理解如何實現“可見性”和“有序性”的。

這裏就引出了內存屏障的概念,內存屏障是被插入兩個 CPU 指令之間執行的,它是用來禁止編譯器,處理器重排序從而保證有序性和可見性的。

對於可見性來說,我們提到了線程獲得和釋放鎖時分別執行的兩個動作:“刷新處理器緩存”和“沖刷處理器緩存”。

前一個動作保證了,持有鎖的線程讀取共享變量,後一個動作保證了,持有鎖的線程對共享變量更新之後,對於後續線程可見。

另外,爲了達到屏障的效果,它也會使處理器寫入、讀取值之前,將主內存的值寫入高速緩存,清空無效隊列,從而保障可見性。

對於有序性來說。下面來舉個例子說明,假設有一組 CPU 指令:

  • Store 表示“存儲指令”

  • Load 表示“讀取指令”

  • StoreLoad 代表“寫讀內存屏障”

StoreLoad 內存屏障示意圖

StoreLoad 屏障之前的 Store 指令,無法與 StoreLoad 屏障之後的 Load 指令進行交換位置,即重排序。

但是 StoreLoad 屏障之前和之後的指令是可以互換位置的,即 Store1 可以和 Store2 互換,Load2 可以和 Load3 互換。

常見有 4 種屏障:

  • LoadLoad 屏障:指令順序如:Load1→LoadLoad→Load2。 需要保證 Load1 指令先完成,才能執行 Load2 及後續指令。

  • StoreStore 屏障:指令順序如:Store1→StoreStore→Store2。需要保證 Store1 指令對其他處理器可見,才能執行 Store2 及後續指令。

  • LoadStore 屏障:指令順序如:Load1→LoadStore→Store2。需要保證 Load1 指令執行完成,才能執行 Store2 及後續指令。

  • StoreLoad 屏障:指令順序如:Store1→StoreLoad→Load2。需要保證 Store1 指令對所有處理器可見,才能執行 Load2 及後續指令。

    這種內存屏障的開銷是四種中最大的(沖刷寫緩衝器,刷新處理器緩存)。它也是個萬能屏障,兼具其他三種內存屏障的功能。

一般在 Java 常用 Volatile 和 Synchronized 關鍵字實現內存屏障,也可以通過 Unsafe 來實現。

總結

從線程的定義和多線程訪問共享變量開始,出現了線程對資源的競態現象。競態會使多線程訪問資源的時候,隨着時間的推移,資源結果不可控制。

這個給我們的多線程編程提出了挑戰。於是,我們需要通過原子性,可見性,有序性來解決線程安全的問題。

對於共享資源的同步可以解決這些問題,Java 提供內部鎖和顯示鎖作爲解決方案的最佳實踐。

在最後,又介紹了線程同步的底層機制:內存屏障。它通過組織 CPU 指令的重排序解決了可見性和有序性的問題。

END

如有收穫,請劃至底部,點擊“在看”,謝

歡迎長按下圖關注公衆號石杉的架構筆記

BAT架構經驗傾囊相授

發佈了76 篇原創文章 · 獲贊 482 · 訪問量 9萬+
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章