??摘要：CPU為了對程序進行優(yōu)化，會對程序的指令進行重排序，此時程序的執(zhí)行順序和代碼的編寫順序不一定一致，這就可能會引起有序性問題。
本文分享自華為云社區(qū)??《【高并發(fā)】解密導(dǎo)致并發(fā)問題的第三個幕后黑手——有序性問題》??，作者：冰 河 。
有序性
有序性是指：按照代碼的既定順序執(zhí)行。
說的通俗一點，就是代碼會按照指定的順序執(zhí)行，例如，按照程序編寫的順序執(zhí)行，先執(zhí)行第一行代碼，再執(zhí)行第二行代碼，然后是第三行代碼，以此類推。如下圖所示。
指令重排序
編譯器或者解釋器為了優(yōu)化程序的執(zhí)行性能，有時會改變程序的執(zhí)行順序。但是，編譯器或者解釋器對程序的執(zhí)行順序進行修改，可能會導(dǎo)致意想不到的問題！
在單線程下，指令重排序可以保證最終執(zhí)行的結(jié)果與程序順序執(zhí)行的結(jié)果一致，但是在多線程下就會存在問題。
如果發(fā)生了指令重排序，則程序可能先執(zhí)行第一行代碼，再執(zhí)行第三行代碼，然后執(zhí)行第二行代碼，如下所示。
例如下面的三行代碼。
int x = 1;
int y = 2;
int z = x + y;
CPU發(fā)生指令重排序時，能夠保證x=1和y = 2這兩行代碼在z = x+ y這行代碼的上面，而x = 1和 y = 2的順序就不一定了。在單線程下不會出現(xiàn)問題，但是在多線程下就不一定了。
有序性問題
CPU為了對程序進行優(yōu)化，會對程序的指令進行重排序，此時程序的執(zhí)行順序和代碼的編寫順序不一定一致，這就可能會引起有序性問題。
在Java程序中，一個經(jīng)典的案例就是使用雙重檢查機制來創(chuàng)建單例對象。例如，在下面的代碼中，在getInstance()方法中獲取對象實例時，首先判斷instance對象是否為空，如果為空，則鎖定當前類的class對象，并再次檢查instance是否為空，如果instance對象仍然為空，則為instance對象創(chuàng)建一個實例。
package io.binghe.concurrent.lab01;
/**
* @author binghe
* @version 1.0.0
* @description 測試單例
*/
public class SingleInstance {
private static SingleInstance instance;
public static SingleInstance getInstance(){
if(instance == null){
synchronized (SingleInstance.class){
if(instance == null){
instance = new SingleInstance();
}
}
}
return instance;
}
}
如果編譯器或者解釋器不會對上面的程序進行優(yōu)化，整個代碼的執(zhí)行過程如下所示。
注意：為了讓大家更加明確流程圖的執(zhí)行順序，我在上圖中標注了數(shù)字，以明確線程A和線程B執(zhí)行的順序。
?
假設(shè)此時有線程A和線程B兩個線程同時調(diào)用getInstance()方法來獲取對象實例，兩個線程會同時發(fā)現(xiàn)instance對象為空，此時會同時對SingleInstance.class加鎖，而JVM會保證只有一個線程獲取到鎖，這里我們假設(shè)是線程A獲取到鎖。則線程B由于未獲取到鎖而進行等待。接下來，線程A再次判斷instance對象為空，從而創(chuàng)建instance對象的實例，最后釋放鎖。此時，線程B被喚醒，線程B再次嘗試獲取鎖，獲取鎖成功后，線程B檢查此時的instance對象已經(jīng)不再為空，線程B不再創(chuàng)建instance對象。
上面的一切看起來很完美，但是這一切的前提是編譯器或者解釋器沒有對程序進行優(yōu)化，也就是說CPU沒有對程序進行重排序。而實際上，這一切都只是我們自己覺得是這樣的。
在真正高并發(fā)環(huán)境下運行上面的代碼獲取instance對象時，創(chuàng)建對象的new操作會因為編譯器或者解釋器對程序的優(yōu)化而出現(xiàn)問題。也就是說，問題的根源在于如下一行代碼。
instance = new SingleInstance();
對于上面的一行代碼來說，會有3個CPU指令與其對應(yīng)。
1.分配內(nèi)存空間。
2.初始化對象。
3.將instance引用指向內(nèi)存空間。
正常執(zhí)行的CPU指令順序為1—>2—>3，CPU對程序進行重排序后的執(zhí)行順序可能為1—>3—>2。此時，就會出現(xiàn)問題。
當CPU對程序進行重排序后的執(zhí)行順序為1—>3—>2時，我們將線程A和線程B調(diào)用getInstance()方法獲取對象實例的兩種步驟總結(jié)如下所示。
【第一種步驟】
（1）假設(shè)線程A和線程B同時進入第一個if條件判斷。
（2）假設(shè)線程A首先獲取到synchronized鎖，進入synchronized代碼塊，此時因為instance對象為null，所以，此時執(zhí)行instance = new SingleInstance()語句。
（3）在執(zhí)行instance = new SingleInstance()語句時，線程A會在JVM中開辟一塊空白的內(nèi)存空間。
（4）線程A將instance引用指向空白的內(nèi)存空間，在沒有進行對象初始化的時候，發(fā)生了線程切換，線程A釋放synchronized鎖，CPU切換到線程B上。
（5）線程B進入synchronized代碼塊，讀取到線程A返回的instance對象，此時這個instance不為null，但是并未進行對象的初始化操作，是一個空對象。此時，線程B如果使用instance，就可能出現(xiàn)問題！！！
【第二種步驟】
（1）線程A先進入if條件判斷，
（2）線程A獲取synchronized鎖，并進行第二次if條件判斷，此時的instance為null，執(zhí)行instance = new SingleInstance()語句。
（3）線程A在JVM中開辟一塊空白的內(nèi)存空間。
（4）線程A將instance引用指向空白的內(nèi)存空間，在沒有進行對象初始化的時候，發(fā)生了線程切換，CPU切換到線程B上。
（5）線程B進行第一次if判斷，發(fā)現(xiàn)instance對象不為null，但是此時的instance對象并未進行初始化操作，是一個空對象。如果線程B直接使用這個instance對象，就可能出現(xiàn)問題！！！
在第二種步驟中，即使發(fā)生線程切換時，線程A沒有釋放鎖，則線程B進行第一次if判斷時，發(fā)現(xiàn)instance已經(jīng)不為null，直接返回instance，而無需嘗試獲取synchronized鎖。
?
我們可以將上述過程簡化成下圖所示。
總結(jié)
導(dǎo)致并發(fā)編程產(chǎn)生各種詭異問題的根源有三個：緩存導(dǎo)致的可見性問題、線程切換導(dǎo)致的原子性問題和編譯優(yōu)化帶來的有序性問題。我們從根源上理解了這三個問題產(chǎn)生的原因，能夠幫助我們更好的編寫高并發(fā)程序。
