【51CTO.com原創稿件】應用開發隨著業務量的增加，數據量也在不斷增加，為了應對海量的數據，通常會採用多線程的方式處理數據。
圖片來自 Pexels
談到 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 指令的重排序解決了可見性和有序性的問題。
簡介：十六年開發和架構經驗，曾擔任過惠普武漢交付中心技術專家，需求分析師，項目經理，後在創業公司擔任技術/產品經理。善於學習，樂於分享。目前專注於技術架構與研發管理。
閱讀更多 51CTO 的文章
