建站
咨詢
售后
建站咨詢
新聞中心
【稿件】應(yīng)用開發(fā)隨著業(yè)務(wù)量的增加，數(shù)據(jù)量也在不斷增加，為了應(yīng)對海量的數(shù)據(jù)，通常會采用多線程的方式處理數(shù)據(jù)。
10余年專注成都網(wǎng)站制作，企業(yè)網(wǎng)站建設(shè)，個人網(wǎng)站制作服務(wù)，為大家分享網(wǎng)站制作知識、方案，網(wǎng)站設(shè)計流程、步驟,成功服務(wù)上千家企業(yè)。為您提供網(wǎng)站建設(shè),網(wǎng)站制作,網(wǎng)頁設(shè)計及定制高端網(wǎng)站建設(shè)服務(wù),專注于企業(yè)網(wǎng)站建設(shè),高端網(wǎng)頁制作,對成都發(fā)電機回收等多個領(lǐng)域，擁有豐富的網(wǎng)站營銷經(jīng)驗。
談到 Java 的多線程編程，一定繞不開線程的安全性，線程安全又包括原子性，可見性和有序性等特性。今天，我們就來看看他們之間的關(guān)聯(lián)和實現(xiàn)原理。
線程與競態(tài)
開發(fā)的應(yīng)用程序會在一個進程中運行，換句話說進程就是程序的運行實例。運行一個 Java 程序的實質(zhì)就是運行了一個 Java 虛擬機進程。
如果說一個進程可以包括多個線程，并且這些線程會共享進程中的資源。任何一段代碼會運行在一個線程中，也運行在多個線程中。線程所要完成的計算被稱為任務(wù)。
為了提高程序的效率，我們會生成多個任務(wù)一起工作，這種工作模式有可能是并行的，A 任務(wù)在執(zhí)行的時候，B 任務(wù)也在執(zhí)行。
如果多個任務(wù)(線程)在執(zhí)行過程中，操作相同的資源(變量)，這個資源(變量)被稱為共享資源(變量)。
當(dāng)多個線程同時對共享資源進行操作時，例如：寫資源，就會出現(xiàn)競態(tài)，它會導(dǎo)致被操作的資源在不同時間看到的結(jié)果不同。
來看看多個線程訪問相同的資源/變量的例子如下：
當(dāng)線程 A 和 B 同時執(zhí)行 Counter 對象中的 add() 方法時，在無法知道兩個線程如何切換的情況下，JVM 會按照下面的順序來執(zhí)行代碼：
- 從內(nèi)存獲取 this.count 的值放到寄存器。
- 將寄存器中的值增加 value。
- 將寄存器中的值寫回內(nèi)存。
上面操作在線程 A 和 B 交錯執(zhí)行時，會出現(xiàn)以下情況：
兩個線程分別加 2 和 3 到 count 變量上，我們希望的結(jié)果是，兩個線程執(zhí)行后 count 的值等于 5。
但是，兩個線程交叉執(zhí)行，即使兩個線程從內(nèi)存中讀出的初始值都是 0，之后各自加了 2 和 3，并分別寫回內(nèi)存。
然而，最終的值并不是期望的 5，而是最后寫回內(nèi)存的那個線程(A 線程)的值(3)。
最后寫回內(nèi)存的是線程 A 所以結(jié)果是 3，但也有可能是線程 B 最后寫回內(nèi)存，所以結(jié)果是不可知的。
因此，如果沒有采用同步機制，線程間的交叉寫資源/變量，結(jié)果是不可控的。
我們把這種一個計算結(jié)果的正確性與時間有關(guān)的現(xiàn)象稱作競態(tài)(Race Condition)。
線程安全
前面我們談到，當(dāng)多線程同時寫一個資源/變量的時候會出現(xiàn)競態(tài)的情況。這種情況的發(fā)生會造成，最終結(jié)果的不確定性。
如果把這個被寫的資源看成 Java 中的一個類的話，這個類不是線程安全的。
即便這個類在單線程環(huán)境下運作正常，但在多線程環(huán)境下就無法正常運行。例如：ArrayList，HashMap，SimpledateFormat。
那么，為了做到線程安全，需要從以下三個方面考慮，分別是：
- 原子性
- 可見性
- 有序性
原子性
原子性是指某個操作或者多個操作，要么全部執(zhí)行，要么就都不執(zhí)行，不會出現(xiàn)中間過程。換成線程執(zhí)行也一樣，線程中執(zhí)行的操作要么不執(zhí)行，要么全部執(zhí)行。
例如，在 Java 中，基本數(shù)據(jù)類型讀取操作就是原子性操作，來看下面的語句：
- x = 10
- x = x + 1
第一句是原子性操作，因為其直接將數(shù)值 10 賦值給 x，線程執(zhí)行這個語句時直接將 10 寫到內(nèi)存中。
第二句包含三個操作，讀取 x 的值，進行加 1 操作，寫入新的值。這三個操作合起來就不是原子性操作了。
Java 中的原子包括：
- lock(鎖定)
- unlock(解鎖)
- read(讀取)
- load(載入)
- use(使用)
- assign(賦值)
- store(存儲)
- write(寫入)
假設(shè) A，B 兩個線程一起執(zhí)行語句 2，同時對 x 變量進行寫操作，由于不滿足原子性操作，因此得到的結(jié)果也是不確定的。在 Java 中有兩種方式來實現(xiàn)原子性。一種是使用鎖(Lock)。
鎖具有排他性，在多線程訪問時，能夠保障一個共享變量在任意時刻都能夠被一個線程訪問，也就是排除了競態(tài)的可能。
另一種是利用處理器提供的 CAS(Compare-and-Swap)指令實現(xiàn)，它是直接在硬件(處理器和內(nèi)存)這一層實現(xiàn)的，被稱為“硬件鎖”。
可見性
說完了原子性，再來談?wù)効梢娦?。名如其意，在多線程訪問中，一個線程對某個共享變量進行更新以后，后續(xù)訪問的線程可以立即讀取更新的結(jié)果。
這種情況就稱作可見，對共享變量的更新對其他線程是可見的，否則就稱不可見。
來看看 Java 是如何實現(xiàn)可見性的。首先，假設(shè)線程 A 執(zhí)行了一段指令，這個指令在 CPU A 中運行。
這個指令寫的共享變量會存放在 CPU A 的寄存器中。當(dāng)指令執(zhí)行完畢以后，會將共享變量從寄存器中寫入到內(nèi)存中。
PS：實際上是通過寄存器到高速緩存，再到寫緩沖器和無序化隊列，最后寫到內(nèi)存的。
這里為了舉例，采用了簡化的說法。這樣做的目的是，讓共享變量能夠被另外一個 CPU 中的線程訪問到。
因此，共享變量寫入到內(nèi)存的行為稱為“沖刷處理器緩存”。也就是把共享變量從處理器緩存，沖刷到內(nèi)存中。
沖刷處理器緩存
此時，線程 B 剛好運行在 CPU B 上，指令為了獲取共享變量，需要從內(nèi)存中的共享變量進行同步。
這個緩存同步的過程被稱為，“刷新處理器緩存”。也就是從內(nèi)存中刷新緩存到處理器的寄存器中。
經(jīng)過這兩個步驟以后，運行在 CPU B 上的線程就能夠同步到，CPU A 上線程處理的共享變量來。也保證了共享變量的可見性。
刷新處理器緩存
有序性
說完了可見性，再來聊聊有序性。Java 編譯器針對代碼執(zhí)行的順序會有調(diào)整。
它有可能改變兩個操作執(zhí)行的先后順序，另外一個處理器上執(zhí)行的多個操作，從其他處理器的角度來看，指令的執(zhí)行順序有可能也是不一致的。
在 Java 內(nèi)存模型中，允許編譯器和處理器對指令進行重排序，但是重排序過程不會影響到單線程程序的執(zhí)行，卻會影響到多線程并發(fā)執(zhí)行的正確性。
究其原因，編譯器出于性能的考慮，在不影響程序(單線程程序)正確性的情況下，對源代碼順序進行調(diào)整。
在 Java 中，可以通過 Volatile 關(guān)鍵字來保證“有序性”。還可以通過 Synchronized 和 Lock 來保證有序性。后面還會介紹通過內(nèi)存屏障來實現(xiàn)有序性。
多線程同步與鎖
前面講到了線程競態(tài)和線程安全，都是圍繞多線程訪問共享變量來討論的。正因為有這種情況出現(xiàn)，在進行多線程開發(fā)的時候需要解決這個問題。
為了保障線程安全，會將多線程的并發(fā)訪問轉(zhuǎn)化成串行的訪問。鎖(Lock)就是利用這種思路來保證多線程同步的。
鎖就好像是共享數(shù)據(jù)訪問的許可證，任何線程需要訪問共享數(shù)據(jù)之前都需要獲得這個鎖。
當(dāng)一個線程獲取鎖的時候，其他申請鎖的線程需要等待。獲取鎖的線程會根據(jù)線程上的任務(wù)執(zhí)行代碼，執(zhí)行代碼以后才會釋放掉鎖。
在獲得鎖與釋放鎖之間執(zhí)行的代碼區(qū)域被稱為臨界區(qū)，在臨界區(qū)中訪問的數(shù)據(jù)，被稱為共享數(shù)據(jù)。
在該線程釋放鎖以后，其他的線程才能獲得該鎖，再對共享數(shù)據(jù)進行操作。
多線程訪問臨界區(qū)，訪問共享數(shù)據(jù)
上面描述的操作也被稱為互斥操作，鎖通過這種互斥操作來保障競態(tài)的原子性。
記得前面談到的原子性嗎?一個或者多個對共享數(shù)據(jù)的操作，要么完成，要么不完成，不能出現(xiàn)中間狀態(tài)。
假設(shè)臨界區(qū)中的代碼，并不是原子性的。例如前文提到的“x=x+1”，其中就包括了三個操作，讀取 x 的值，進行加 1 操作，寫入新的值。
如果在多線程訪問的時候，隨著運行時間的不同會得到不同的結(jié)果。如果對這個操作加上鎖，就可以使之具有“原子性”，也就是在一個線程訪問的時候其他線程無法訪問。
說完了多線程開發(fā)中鎖的重要性，再來看看 Java 有那幾種鎖。
內(nèi)部鎖
內(nèi)部鎖也稱作監(jiān)視器(Monitor)，它是通過 Synchronized 關(guān)鍵字來修飾方法及代碼塊，來制造臨界區(qū)的。
Synchronized 關(guān)鍵字可以用來修飾同步方法，同步靜態(tài)方法，同步實例方法，同步代碼塊。
Synchronized 引導(dǎo)的代碼塊就是上面提到的臨界區(qū)。鎖句柄就是一個對象的引用，例如：它可以寫成 this 關(guān)鍵字，就表示當(dāng)前對象。
鎖句柄對應(yīng)的監(jiān)視器被稱為相應(yīng)同步塊的引導(dǎo)鎖，相應(yīng)的我們稱呼相應(yīng)的同步塊為該鎖引導(dǎo)的同步塊。
內(nèi)部鎖示意圖
鎖句柄通常采用 final 修飾(private final)。因為鎖句柄一旦改變，會導(dǎo)致同一個代碼塊的多個線程使用不同的鎖，而導(dǎo)致競態(tài)。
同步靜態(tài)方法相當(dāng)于當(dāng)前類為引導(dǎo)鎖的同步塊。線程在執(zhí)行臨界區(qū)代碼的時候，必須持有該臨界區(qū)的引導(dǎo)鎖。
一旦執(zhí)行完臨界區(qū)代碼，引導(dǎo)該臨界區(qū)的鎖就會被釋放。內(nèi)部鎖申請和釋放的過程由 Java 虛擬機負(fù)責(zé)完成。
所以 Synchronized 實現(xiàn)的鎖被稱為內(nèi)部鎖。因此不會導(dǎo)致鎖泄露，Java 編譯器在將代碼塊編譯成字節(jié)碼的時候，對臨界區(qū)拋出的異常進行了處理。
Java 虛擬機會給每個內(nèi)部鎖分配一個入口集(Entry Set)，用于記錄等待獲取鎖的線程。申請鎖失敗的線程會在入口集中等待再次申請鎖的機會。
當(dāng)?shù)却逆i被其他線程釋放時，入口集中的等待線程會被喚醒，獲得申請鎖的機會。
內(nèi)部鎖的機制會在等待的線程中進行選擇，選擇的規(guī)則會根據(jù)線程活躍度和優(yōu)先級來進行，被選中的線程會持有鎖進行后續(xù)操作。
顯示鎖
顯示鎖是 JDK 1.5 開始引入的排他鎖，作為一種線程同步機制存在，其作用與內(nèi)部鎖相同，但它提供了一些內(nèi)部鎖不具備的特性。顯示鎖是 java.util.concurrent.locks.Lock 接口的實例。
顯示鎖實現(xiàn)的幾個步驟分別是：
- 創(chuàng)建 Lock 接口實例
- 申請顯示鎖 Lock
- 對共享數(shù)據(jù)進行訪問
- 在 finally 中釋放鎖，避免鎖泄漏
顯示鎖使用實例圖
顯示鎖支持非公平鎖也支持公平鎖。公平鎖中, 線程嚴(yán)格先進先出(FIFO)的順序，獲取鎖資源。
如果有“當(dāng)前線程”需要獲取共享變量，需要進行排隊。當(dāng)鎖被釋放，由隊列中排第一個的線程(Node1)獲取，依次類推。
公平鎖示意圖
非公平鎖中，在線程釋放鎖的時候, “當(dāng)前線程“和等待隊列中的第一個線程(Node1)競爭鎖資源。通過線程活躍度和優(yōu)先級來確定那個線程持有鎖資源。
非公平鎖示意圖
公平鎖保證鎖調(diào)度的公平性，但是增加了線程暫停和喚醒的可能性，即增加了上下文切換的代價。非公平鎖加入了競爭機制，會有更好的性能，能夠承載更大的吞吐量。
當(dāng)然，非公平鎖讓獲取鎖的時間變得更加不確定，可能會導(dǎo)致在阻塞隊列中的線程長期處于饑餓狀態(tài)。
線程同步機制：內(nèi)存屏障
說了多線程訪問共享變量，存在的競態(tài)問題，然后引入鎖的機制來解決這個問題。
上文提到內(nèi)部鎖和顯示鎖來解決線程同步的問題，而且提到了解決了競態(tài)中“原子性”的問題。
那么接下來，通過介紹內(nèi)存屏障機制，來理解如何實現(xiàn)“可見性”和“有序性”的。
這里就引出了內(nèi)存屏障的概念，內(nèi)存屏障是被插入兩個 CPU 指令之間執(zhí)行的，它是用來禁止編譯器，處理器重排序從而保證有序性和可見性的。
對于可見性來說，我們提到了線程獲得和釋放鎖時分別執(zhí)行的兩個動作：“刷新處理器緩存”和“沖刷處理器緩存”。
前一個動作保證了，持有鎖的線程讀取共享變量，后一個動作保證了，持有鎖的線程對共享變量更新之后，對于后續(xù)線程可見。
另外，為了達(dá)到屏障的效果，它也會使處理器寫入、讀取值之前，將主內(nèi)存的值寫入高速緩存，清空無效隊列，從而保障可見性。
對于有序性來說。下面來舉個例子說明，假設(shè)有一組 CPU 指令：
- Store 表示“存儲指令”
- Load 表示“讀取指令”
- StoreLoad 代表“寫讀內(nèi)存屏障”
StoreLoad 內(nèi)存屏障示意圖
StoreLoad 屏障之前的 Store 指令，無法與 StoreLoad 屏障之后的 Load 指令進行交換位置，即重排序。
但是 StoreLoad 屏障之前和之后的指令是可以互換位置的，即 Store1 可以和 Store2 互換，Load2 可以和 Load3 互換。
常見有 4 種屏障：
- LoadLoad 屏障：指令順序如：Load1→LoadLoad→Load2。 需要保證 Load1 指令先完成，才能執(zhí)行 Load2 及后續(xù)指令。
- StoreStore 屏障：指令順序如：Store1→StoreStore→Store2。需要保證 Store1 指令對其他處理器可見，才能執(zhí)行 Store2 及后續(xù)指令。
- LoadStore 屏障：指令順序如：Load1→LoadStore→Store2。需要保證 Load1 指令執(zhí)行完成，才能執(zhí)行 Store2 及后續(xù)指令。
- StoreLoad 屏障：指令順序如：Store1→StoreLoad→Load2。需要保證 Store1 指令對所有處理器可見，才能執(zhí)行 Load2 及后續(xù)指令。
這種內(nèi)存屏障的開銷是四種中最大的(沖刷寫緩沖器，刷新處理器緩存)。它也是個萬能屏障，兼具其他三種內(nèi)存屏障的功能。
一般在 Java 常用 Volatile 和 Synchronized 關(guān)鍵字實現(xiàn)內(nèi)存屏障，也可以通過 Unsafe 來實現(xiàn)。
總結(jié)
從線程的定義和多線程訪問共享變量開始，出現(xiàn)了線程對資源的競態(tài)現(xiàn)象。競態(tài)會使多線程訪問資源的時候，隨著時間的推移，資源結(jié)果不可控制。
這個給我們的多線程編程提出了挑戰(zhàn)。于是，我們需要通過原子性，可見性，有序性來解決線程安全的問題。
對于共享資源的同步可以解決這些問題，Java 提供內(nèi)部鎖和顯示鎖作為解決方案的最佳實踐。
在最后，又介紹了線程同步的底層機制：內(nèi)存屏障。它通過組織 CPU 指令的重排序解決了可見性和有序性的問題。
作者：崔皓
簡介：十六年開發(fā)和架構(gòu)經(jīng)驗，曾擔(dān)任過惠普武漢交付中心技術(shù)專家，需求分析師，項目經(jīng)理，后在創(chuàng)業(yè)公司擔(dān)任技術(shù)/產(chǎn)品經(jīng)理。善于學(xué)習(xí)，樂于分享。目前專注于技術(shù)架構(gòu)與研發(fā)管理。
【原創(chuàng)稿件，合作站點轉(zhuǎn)載請注明原文作者和出處為.com】
當(dāng)前文章：面試突然問Java多線程原理，我哭了！
當(dāng)前網(wǎng)址：http://m.fisionsoft.com.cn/article/dhoisgd.html
