您好,登錄后才能下訂單哦!
這篇文章主要介紹“Java語言中的線程安全及鎖優(yōu)化”,在日常操作中,相信很多人在Java語言中的線程安全及鎖優(yōu)化問題上存在疑惑,小編查閱了各式資料,整理出簡單好用的操作方法,希望對大家解答”Java語言中的線程安全及鎖優(yōu)化”的疑惑有所幫助!接下來,請跟著小編一起來學(xué)習(xí)吧!
1. Java語言中的線程安全
1.1 不可變
1.2 絕對線程安全
1.3 相對線程安全
1.4 線程兼容
1.5 線程對立
2. 線程安全的實現(xiàn)方法
2.1 互斥同步
3. 鎖優(yōu)化
3.1 自旋鎖與自適應(yīng)自旋
3.2 鎖消除
3.3 鎖粗化
3.4 輕量級鎖
3.5 偏向鎖
按照線程安全的“安全程度”由強至弱來排序,可以將Java語言中各種操作共享的數(shù)據(jù)分為以下五類:不可變、絕對線程安全、相對線程安全、線程兼容和線程對立。
不可變的對象一定是線程安全的,無論是對象的方法實現(xiàn)還是方法的調(diào)用者,都不需要再進行任何線程安全保障措施。
Java語言中,如果多線程共享的數(shù)據(jù)是一個基本數(shù)據(jù)類型,那么只要定義時使用 final 關(guān)鍵字修飾他就可以保證它是不可變的,如果共享數(shù)據(jù)是一個對象類型,由于Java語言目前暫時還沒有提供值類型的支持,那就需要對象自行保證其行為不會對其狀態(tài)產(chǎn)生任何影響才行。
例如:java.lang.String 類的對象實例,它是一個典型的不可變對象,用戶調(diào)用它的 substring()、replace() 和 concat() 這些方法都不會影響它原來的值,只會返回一個新構(gòu)造的字符串對象。
保證對象行為不影響自己狀態(tài)的途徑有很多種,最簡單的一種就是把對象里面帶有狀態(tài)的變量都聲明為 final,這樣在構(gòu)造函數(shù)結(jié)束之后,它就是不可變的,例如下面代碼中 java.lang.Integer 的構(gòu)造函數(shù),它通過將內(nèi)部狀態(tài)變量 value 定義為 final 來保障狀態(tài)不變 :
/** * The value of the <code>Integer</code>. * @serial */ private final int value; /** * Constructs a newly allocated <code>Integer</code> object that * represents the specified <code>int</code> value. * * @param value the value to be represented by the * <code>Integer</code> object. */ public Integer(int value) { this.value = value; }
在Java類庫API中符合不可變要求的類型,除了上面提到的 String 之外,常用的還有枚舉類型及 java.lang.Number 的部分子類,如 Long 和 Double 等數(shù)值包裝類型、BigInteger 和 BigDecimal 等大數(shù)據(jù)類型。但同為Number子類型的原子類 AtomicInteger 和 AtomicLong 則是可變的。
Java API中標注自己是線程安全的類,大多數(shù)都不是絕對的線程安全。java.util.Vector 是個線程安全的容器,add()、get()、size() 等方法都是被synchronized修飾的,保證了具備原子性、可見性和有序性。不過,就算是所有方法都被synchronized修飾,那也不意味著調(diào)用它的時候就不需要同步手段了。
如下代碼,對 Vector 線程安全性的測試 :
private static Vector<Integer> vector = new Vector<Integer>(); public static void main(String[] args) { while (true) { for (int i = 0; i < 10; i++) { vector.add(i); } Thread removeThread = new Thread(new Runnable() { @Override public void run() { for (int i = 0; i < vector.size(); i++) { vector.remove(i); } } }; Thread printThread = new Thread(new Runnable() { @Override public void run() { for (int i = 0; i < vector.size(); i++) { System.out.println((vector.get(i))); } } }); removeThread.start(); printThread.start(); //不要同時產(chǎn)生過多的線程,否則會導(dǎo)致操作系統(tǒng)假死 while (Thread.activeCount() > 20); } }
運行結(jié)果如下:
Exception in thread "Thread-132" java.lang.ArrayIndexOutOfBoundsException:
Array index out of range: 17
at java.util.Vector.remove(Vector.java:777)
at org.fenixsoft.mulithread.VectorTest$1.run(VectorTest.java:21)
at java.lang.Thread.run(Thread.java:662)
盡管這里使用到的 Vector 的 get()、remove() 和 size() 方法都是同步的,但是在多線程的環(huán)境中,如果不在方法調(diào)用端做額外的同步措施,使用這段代碼仍然是不安全的。因為如果另一個線程恰好在錯誤的時間里刪除了一個元素,導(dǎo)致序號i已經(jīng)不再可用,再用i訪問數(shù)組就會拋出一個 ArrayIndexOutOfBoundsException 異常。如果要保證這段代碼能正確執(zhí)行下去,我們不得不把 removeThread 和 printThread 的定義改成如下所示:
Thread removeThread = new Thread(new Runnable() { @Override public void run() { synchronized (vector) { for (int i = 0; i < vector.size(); i++) { vector.remove(i); } } } }); Thread printThread = new Thread(new Runnable() { @Override public void run() { synchronized (vector) { for (int i = 0; i < vector.size(); i++) { System.out.println((vector.get(i))); } } } });
假如Vector一定要做到絕對的線程安全,那就必須在它內(nèi)部維護一組一致性的快照訪問才行,每次對其中元素進行改動都要產(chǎn)生新的快照,這樣要付出的時間和空間成本都是非常大的。
相對線程安全就是我們通常意義上所講的線程安全,它需要保證對這個對象單次的操作是線程安全的,我們在調(diào)用的時候不需要進行額外的保障措施,但是對于一些特定順序的連續(xù)調(diào)用,就可能需要在調(diào)用端使用額外的同步手段來保證調(diào)用的正確性。
在Java語言中,大部分聲稱線程安全的類都屬于這種類型,例如Vector、HashTable、Collections的 synchronizedCollection() 方法包裝的集合等。
線程兼容是指對象本身并不是線程安全的,但是可以通過在調(diào)用端正確地使用同步手段來保證對象在并發(fā)環(huán)境中可以安全地使用。我們平常說一個類不是線程安全的,通常就是指這種情況。Java類庫API中大部分的類都是線程兼容的,如與前面的 Vector 和 HashTable 相對應(yīng)的集合類 ArrayList 和 HashMap 等。
線程對立是指不管調(diào)用端是否采取了同步措施,都無法在多線程環(huán)境中并發(fā)使用代碼。由于Java 語言天生就支持多線程的特性,線程對立這種排斥多線程的代碼是很少出現(xiàn)的,而且通常都是有害的,應(yīng)當盡量避免。
互斥同步(Mutual Exclusion & Synchronization)是一種最常見也是最主要的并發(fā)正確性保障手段。同步是指在多個線程并發(fā)訪問共享數(shù)據(jù)時,保證共享數(shù)據(jù)在同一個時刻只被一個線程使用。而互斥是實現(xiàn)同步的一種手段,臨界區(qū)(Critical Section)、互斥量(Mutex)和信號量(Semaphore)都是常見的互斥實現(xiàn)方式。因此在“互斥同步”這四個字里面,互斥是因,同步是果;互斥是方法,同步是目的。
在 Java 里面,最基本的互斥同步手段就是 synchronized 關(guān)鍵字,這是一種塊結(jié)構(gòu)(Block Structured)的同步語法。synchronized 關(guān)鍵字經(jīng)過 Javac 編譯之后,會在同步塊的前后分別形成 monitorenter 和 monitorexit 這兩個字節(jié)碼指令。這兩個字節(jié)碼指令都需要一個 reference 類型的參數(shù)來指明要鎖定和解鎖的對象。
如果 Java 源碼中的 synchronized 明確指定了對象參數(shù),那就以這個對象的引用作為 reference;如果沒有明確指定,那將根據(jù) synchronized 修飾的方法類型(如實例方法或類方法),來決定是取代碼所在的對象實例還是取類型對應(yīng)的 Class 對象來作為線程要持有的鎖。
在執(zhí)行 monitorenter 指令時,首先要去嘗試獲取對象的鎖。如果這個對象沒被鎖定,或者當前線程已經(jīng)持有了那個對象的鎖,就把鎖的計數(shù)器的值增加一,而在執(zhí)行 monitorexit 指令時會將鎖計數(shù)器的值減一。一旦計數(shù)器的值為零,鎖隨即就被釋放了。如果獲取對象鎖失敗,那當前線程就應(yīng)當被阻塞等待,直到請求鎖定的對象被持有它的線程釋放為止。
由上面的描述,可得出 synchronized 鎖的一些特性:
被 synchronized 修飾的同步塊對同一條線程來說是可重入的。這意味著同一線程反復(fù)進入同步塊也不會出現(xiàn)自己把自己鎖死的情況。被 synchronized 修飾的同步塊在持有鎖的線程執(zhí)行完畢并釋放鎖之前,會無條件地阻塞后面其他線程的進入。這意味著無法像處理某些數(shù)據(jù)庫中的鎖那樣,強制已獲取鎖的線程釋放鎖;也無法強制正在等待鎖的線程中斷等待或超時退出。
從執(zhí)行成本的角度看,synchronized 持有鎖是Java語言中一個重量級(Heavy-Weight)的操作。主流 Java 虛擬機實現(xiàn)中,Java 的線程是映射到操作系統(tǒng)的原生內(nèi)核線程之上的,如果要阻塞或喚醒一條線程,則需要操作系統(tǒng)來幫忙完成,這就不可避免地陷入用戶態(tài)到核心態(tài)的轉(zhuǎn)換中,進行這種狀態(tài)轉(zhuǎn)換需要耗費很多的處理器時間。
實際上,虛擬機本身會對 synchronized 持鎖操作進行一些優(yōu)化,譬如在通知操作系統(tǒng)阻塞線程之前加入一段自旋等待過程,以避免頻繁地切入核心態(tài)之中(這個問題下面小節(jié)再討論)。
自旋鎖:即,當一個線程去競爭共享資源時,該資源已被其他線程占用,這時該線程不會立刻進入掛起阻塞狀態(tài),而是通過不斷自旋,等待共享資源使用權(quán)被持鎖線程釋放。當然,不可能讓一個線程一直自旋等待下去,自旋等待的時間是必須有一定的限度的,如果自旋超過了限定的次數(shù)仍然沒有成功獲得鎖,就應(yīng)當使用傳統(tǒng)的方式去掛起線程。自旋次數(shù)的默認值是 10 次,用戶也可以使用參數(shù) -XX:PreBlockSpin 來自行更改。
在JDK 6中對自旋鎖的優(yōu)化,引入了自適應(yīng)的自旋。自適應(yīng)意味著自旋的時間不再是固定的了,而是由前一次在同一個鎖上的自旋時間及鎖的擁有者的狀態(tài)來決定的。如果在同一個鎖對象上,自旋等待剛剛成功獲得過鎖,并且持有鎖的線程正在運行中,那么虛擬機就會認為這次自旋也很有可能再次成功,進而允許自旋等待持續(xù)相對更長的時間,比如持續(xù)100次忙循環(huán)。另一方面,如果對于某個鎖,自旋很少成功獲得過鎖,那在以后要獲取這個鎖時將有可能直接省略掉自旋過程,以避免浪費處理器資源。
鎖消除:是指虛擬機即時編譯器在運行時,對一些代碼要求同步,但是對被檢測到不可能存在共享資源競爭的鎖進行消除。
鎖消除的主要判定依據(jù)來源于逃逸分析的數(shù)據(jù)支持,如果判斷到一段代碼中,在堆上的所有數(shù)據(jù)都不會逃逸出去被其他線程訪問到,那就可以把它們當作棧上數(shù)據(jù)對待,認為它們是線程私有的,同步加鎖自然就無須再進行。
示例如下:(示例2-1)
public String concatString(String s1, String s2, String s3) { return s1 + s2 + s3; }
由于 String 是一個不可變的類,對字符串的連接操作總是通過生成新的 String 對象來進行的,因此 Javac 編譯器會對 String 連接做自動優(yōu)化。
在JDK 5之前,字符串加法會轉(zhuǎn)化為 StringBuffer 對象的連續(xù) append() 操作,在JDK 5及以后的版本中,會轉(zhuǎn)化為 StringBuilder 對象的連續(xù) append() 操作。
優(yōu)化為如下所示:(示例2-2)
public String concatString(String s1, String s2, String s3) { StringBuffer sb = new StringBuffer(); sb.append(s1); sb.append(s2); sb.append(s3); return sb.toString(); }
現(xiàn)在大家還認為這段代碼沒有涉及同步嗎?每個 StringBuffer.append() 方法中都有一個同步塊,鎖就是 sb 對象。虛擬機觀察變量 sb,經(jīng)過逃逸分析后會發(fā)現(xiàn)它的動態(tài)作用域被限制在 concatString() 方法內(nèi)部。也就是 sb 的所有引用都永遠不會逃逸到 concatString() 方法之外,其他線程無法訪問到它,所以這里雖然有鎖,但是可以被安全地消除掉。在解釋執(zhí)行時這里仍然會加鎖,但在經(jīng)過服務(wù)端編譯器的即時編譯之后,這段代碼就會忽略所有的同步措施而直接執(zhí)行。
客觀地說,既然談到鎖消除與逃逸分析,那虛擬機就不可能是JDK 5之前的版本,所以實際上會轉(zhuǎn)化為非線程安全的 StringBuilder 來完成字符串拼接,并不會加鎖。但是這也不影響筆者用這個例子證明 Java 對象中同步的普遍性。
原則上,我們在編寫代碼的時候,總是推薦將同步塊的作用范圍限制得盡量小——只在共享數(shù)據(jù)的實際作用域中才進行同步,這樣是為了使得需要同步的操作數(shù)量盡可能變少,即使存在鎖競爭,等待鎖的線程也能盡可能快地拿到鎖。
大多數(shù)情況下,上面的原則都是正確的,但是如果一系列的連續(xù)操作都對同一個對象反復(fù)加鎖和解鎖,甚至加鎖操作是出現(xiàn)在循環(huán)體之中的,那即使沒有線程競爭,頻繁地進行互斥同步操作也會導(dǎo)致不必要的性能損耗。
(示例2-2)所示連續(xù)的 append() 方法就屬于這類情況。如果虛擬機探測到有這樣一串零碎的操作都對同一個對象加鎖,將會把加鎖同步的范圍擴展(粗化)到整個操作序列的外部,以(示例2-2)為例,就是擴展到第一個 append() 操作之前直至最后一個 append() 操作之后,這樣只需要加鎖一次就可以了。
總之,如果虛擬機探測到有這樣一串零碎的操作都對同一個對象加鎖,將會把加鎖同步的范圍擴展(粗化)到整個操作序列的外部。
輕量級鎖是JDK 6時加入的新型鎖機制,它名字中的“輕量級”是相對于使用操作系統(tǒng)互斥量來實現(xiàn)的傳統(tǒng)鎖而言的,因此傳統(tǒng)的鎖機制就被稱為“重量級”鎖。輕量級鎖并不是用來代替重量級鎖的,它設(shè)計的初衷是在沒有多線程競爭的前提下,減少傳統(tǒng)的重量級鎖使用操作系統(tǒng)互斥量產(chǎn)生的性能消耗。
由于對象頭信息是與對象自身定義的數(shù)據(jù)無關(guān)的額外存儲成本,考慮到Java虛擬機的空間使用效率,Mark Word被設(shè)計成一個非固定的動態(tài)數(shù)據(jù)結(jié)構(gòu),以便在極小的空間內(nèi)存儲盡量多的信息。它會根據(jù)對象的狀態(tài)復(fù)用自己的存儲空間。
例如在32位的HotSpot虛擬機中,對象未被鎖定的狀態(tài)下,Mark Word的32個比特空間里的25個比特將用于存儲對象哈希碼,4個比特用于存儲對象分代年齡,2個比特用于存儲鎖標志位,還有 1 個比特固定為 0(這表示未進入偏向模式)。
對象除了未被鎖定的正常狀態(tài)外,還有輕量級鎖定、重量級鎖定、GC標記、可偏向等幾種不同狀態(tài),這些狀態(tài)下對象頭的存儲內(nèi)容如下表所示:
在代碼即將進入同步塊的時候,如果此同步對象沒有被鎖定(鎖標志位為“01”狀態(tài)),虛擬機首先將在當前線程的棧幀中建立一個名為鎖記錄(Lock Record)的空間,用于存儲鎖對象目前的Mark Word的拷貝,這時候線程堆棧與對象頭的狀態(tài)如下圖所示:
然后,虛擬機將使用CAS操作嘗試把對象的Mark Word更新為指向Lock Record的指針。如果這個更新動作成功了,即代表該線程擁有了這個對象的鎖,并且對象Mark Word的鎖標志位(Mark Word的最后兩個比特)將轉(zhuǎn)變?yōu)椤?0”,表示此對象處于輕量級鎖定狀態(tài)。這時候線程堆棧與對象頭的狀態(tài)如下圖所示:
如果這個更新操作失敗了,那就意味著至少存在一條線程與當前線程競爭獲取該對象的鎖。虛擬機首先會檢查對象的Mark Word是否指向當前線程的棧幀,如果是,說明當前線程已經(jīng)擁有了這個對象的鎖,那直接進入同步塊繼續(xù)執(zhí)行就可以了,否則就說明這個鎖對象已經(jīng)被其他線程搶占了。如果出現(xiàn)兩條以上的線程爭用同一個鎖的情況,那輕量級鎖就不再有效,必須要膨脹為重量級鎖,鎖標志的狀態(tài)值變?yōu)椤?0”,此時Mark Word中存儲的就是指向重量級鎖(互斥量)的指針,后面等待鎖的線程也必須進入阻塞狀態(tài)。
上面描述的是輕量級鎖的加鎖過程,它的解鎖過程也同樣是通過CAS操作來進行的,如果對象的Mark Word仍然指向線程的鎖記錄,那就用CAS操作把對象當前的Mark Word和線程中復(fù)制的Displaced Mark Word替換回來。假如能夠成功替換,那整個同步過程就順利完成了;如果替換失敗,則說明有其他線程嘗試過獲取該鎖,就要在釋放鎖的同時,喚醒被掛起的線程。
輕量級鎖能提升程序同步性能的依據(jù)是“對于絕大部分的鎖,在整個同步周期內(nèi)都是不存在競爭的”這一經(jīng)驗法則。如果沒有競爭,輕量級鎖便通過CAS操作成功避免了使用互斥量的開銷;但如果確實存在鎖競爭,除了互斥量的本身開銷外,還額外發(fā)生了CAS操作的開銷。因此在有競爭的情況下,輕量級鎖反而會比傳統(tǒng)的重量級鎖更慢。
偏向鎖也是JDK 6中引入的一項鎖優(yōu)化措施,它的目的是消除數(shù)據(jù)在無競爭情況下的同步原語,進一步提高程序的運行性能。如果說輕量級鎖是在無競爭的情況下使用CAS操作去消除同步使用的互斥量,那偏向鎖就是在無競爭的情況下把整個同步都消除掉,連CAS操作都不去做了。
偏向鎖中的“偏”,就是偏心的“偏”、偏袒的“偏”。它的意思是這個鎖會偏向于第一個獲得它的線程,如果在接下來的執(zhí)行過程中,該鎖一直沒有被其他的線程獲取,則持有偏向鎖的線程將永遠不需要再進行同步。
假設(shè)當前虛擬機啟用了偏向鎖(啟用參數(shù)-XX:+UseBiased Locking,這是自JDK 6起HotSpot虛擬機的默認值),那么當鎖對象第一次被線程獲取的時候,虛擬機將會把對象頭中的標志位設(shè)置為“01”、把偏向模式設(shè)置為“1”,表示進入偏向模式。同時使用CAS操作把獲取到這個鎖的線程的ID記錄在對象的Mark Word之中。如果CAS操作成功,持有偏向鎖的線程以后每次進入這個鎖相關(guān)的同步塊時,虛擬機都可以不再進行任何同步操作(例如加鎖、解鎖及對Mark Word的更新操作 等)。
一旦出現(xiàn)另外一個線程去嘗試獲取這個鎖的情況,偏向模式就馬上宣告結(jié)束。根據(jù)鎖對象目前是否處于被鎖定的狀態(tài)決定是否撤銷偏向(偏向模式設(shè)置為“0”),撤銷后標志位恢復(fù)到未鎖定(標志位為“01”)或輕量級鎖定(標志位為“00”)的狀態(tài),后續(xù)的同步操作就按照上面介紹的輕量級鎖那樣去執(zhí)行。偏向鎖、輕量級鎖的狀態(tài)轉(zhuǎn)化及對象Mark Word的關(guān)系如下圖所示:
到此,關(guān)于“Java語言中的線程安全及鎖優(yōu)化”的學(xué)習(xí)就結(jié)束了,希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學(xué)習(xí),快去試試吧!若想繼續(xù)學(xué)習(xí)更多相關(guān)知識,請繼續(xù)關(guān)注億速云網(wǎng)站,小編會繼續(xù)努力為大家?guī)砀鄬嵱玫奈恼拢?/p>
免責(zé)聲明:本站發(fā)布的內(nèi)容(圖片、視頻和文字)以原創(chuàng)、轉(zhuǎn)載和分享為主,文章觀點不代表本網(wǎng)站立場,如果涉及侵權(quán)請聯(lián)系站長郵箱:is@yisu.com進行舉報,并提供相關(guān)證據(jù),一經(jīng)查實,將立刻刪除涉嫌侵權(quán)內(nèi)容。