歡迎關注專欄【JAVA并發】
前言
開篇一個例子，我看看都有誰會？如果不會的，或者不知道原理的，還是老老實實看完這篇文章吧，
@Slf4j(topic = "c.VolatileTest")
public class VolatileTest {
static boolean run = true;
public static void main(String[] args) throws InterruptedException {
Thread t = new Thread(() -> {
while (run) {
// do other things
}
// ?????? 這行會列印嗎？
log.info("done .....");
});
t.start();
Thread.sleep(1000);
// 設定run = false
run = false;
}
}
main函式中新開個執行緒根據標位run回圈，主執行緒中sleep一秒，然后設定run=false，大家認為會列印"done ......."嗎?
答案就是不會列印，為什么呢？
JAVA并發三大特性
我們先來解釋下上面問題的原因，如下圖所示，
現代的CPU架構基本有多級快取機制，t執行緒會將run加載到高速快取中，然后主執行緒修改了主記憶體的值為false，導致快取不一致，但是t執行緒依然是從作業記憶體中的高速快取讀取run的值，最終無法跳出回圈，
可見性
正如上面的例子，由于不做任何處理，一個執行緒能否立刻看到另外一個執行緒修改的共享變數值，我們稱為"可見性"，
如果在并發程式中，不做任何處理，那么就會帶來可見性問題，具體如何處理，見后文，
有序性
有序性是指程式按照代碼的先后順序執行，但是編譯器或者處理器出于性能原因，改變程式陳述句的先后順序，比如代碼順序"a=1; b=2;"，但是指令重排序后，有可能會變成"b=2；a=1", 那么這樣在并發情況下，會有問題嗎？
在單執行緒情況下，指令重排序不會有任何影響，但是在并發情況下，可能會導致一些意想不到的bug，比如下面的例子：
public class Singleton {
static Singleton instance;
static Singleton getInstance(){
if (instance == null) {
synchronized(Singleton.class) {
if (instance == null)
instance = new Singleton();
}
}
return instance;
}
}
假設有兩個執行緒 A、B 同時呼叫 getInstance() 方法，正常情況下，他們都可以拿到instance實體，
但往往bug就在一些極端的例外情況，比如new Singleton() 這個操作，實際會有下面3個步驟：
-
分配一塊記憶體 M；
-
在記憶體 M 上初始化
Singleton物件； -
然后 M 的地址賦值給
instance變數，
現在發生指令重排序，順序變為下面的方式：
-
分配一塊記憶體 M；
-
將 M 的地址賦值給 instance 變數；
-
最后在記憶體 M 上初始化 Singleton 物件，
優化后會導致什么問題呢？我們假設執行緒 A 先執行 getInstance() 方法，當執行完指令 2 時恰好發生了執行緒切換，切換到了執行緒 B 上；如果此時執行緒 B 也執行 getInstance() 方法，那么執行緒 B 在執行第一個判斷時會發現 instance != null ，所以直接回傳 instance，而此時的 instance 是沒有初始化過的，如果我們這個時候訪問 instance 的成員變數就可能觸發空指標例外，
這就是并發情況下，有序性帶來的一個問題，這種情況又該如何處理呢？
當然，指令重排序并不會瞎排序，處理器在進行重排序時，必須要考慮指令之間的資料依賴性，
原子性
如上圖所示，在多執行緒的情況下，CPU資源會在不同的執行緒間切換，那么這樣也會導致意向不到的問題，
比如你認為的一行代碼：count += 1,實際上涉及了多條CPU指令：
- 指令 1：首先，需要把變數 count 從記憶體加載到 CPU 的暫存器；
- 指令 2：之后，在暫存器中執行 +1 操作；
- 指令 3：最后，將結果寫入記憶體（快取機制導致可能寫入的是 CPU 快取而不是記憶體），
作業系統做任務切換，可以發生在任何一條CPU 指令執行完，假設 count=0，如果執行緒 A 在指令 1 執行完后做執行緒切換，執行緒 A 和執行緒 B 按照下圖的序列執行，那么我們會發現兩個執行緒都執行了 count+=1 的操作，但是得到的結果不是我們期望的 2，而是 1，
我們潛意識認為的這個
count+=1操作是一個不可分割的整體，就像一個原子一樣，我們把一個或者多個操作在 CPU 執行的程序中不被中斷的特性稱為原子性，但實際情況就是不做任何處理的話，在并發情況下CPU進行切換，導致出現原子性的問題，我們一般通過加鎖解決，這個不是本文的重點，
Java記憶體模型真面目
前面講解并發的三大特性，其中原子性問題可以通過加鎖的方式解決，那么可見性和有序性有什么解決的方案呢？其實也很容易想到，可見性是因為快取導致，有序性是因為編譯優化指令重排序導致，那么是不是可以讓程式員按需禁用快取以及編譯優化， 因為只有程式員知道什么情況下會出現問題 ， 順著這個思路，就提出了JAVA記憶體模型（JMM）規范，
Java 記憶體模型是 Java Memory Model（JMM），本身是一種抽象的概念，實際上并不存在，描述的是一組規則或規范，通過這組規范定義了程式中各個變數（包括實體欄位，靜態欄位和構成陣列物件的元素）的訪問方式，
默認情況下，JMM中的記憶體機制如下：
- 系統存在一個主記憶體（
Main Memory），Java 中所有變數都存盤在主存中，對于所有執行緒都是共享的 - 每條執行緒都有自己的作業記憶體（
Working Memory），作業記憶體中保存的是主存中某些變數的拷貝 - 執行緒對所有變數的操作都是先對變數進行拷貝，然后在作業記憶體中進行，不能直接操作主記憶體中的變數
- 執行緒之間無法相互直接訪問，執行緒間的通信（傳遞）必須通過主記憶體來完成
同時，JMM規范了 JVM 如何提供按需禁用快取和編譯優化的方法，主要是通過volatile、synchronized 和 final 三個關鍵字，那具體的規則是什么樣的呢？
JMM 中的主記憶體、作業記憶體與 JVM 中的 Java 堆、堆疊、方法區等并不是同一個層次的記憶體劃分，這兩者基本上是沒有關系的，
Happens-Before規則
JMM本質上包含了一些規則，那這個規則就是大家有所耳聞的Happens-Before規則，大家都理解了些規則嗎？
Happens-Before規則，可以簡單理解為如果想要A執行緒發生在B執行緒前面，也就是B執行緒能夠看到A執行緒，需要遵循6個原則，如果不符合 happens-before 規則，JMM 并不能保證一個執行緒的可見性和有序性，
1.程式的順序性規則
在一個執行緒中，邏輯上書寫在前面的操作先行發生于書寫在后面的操作，
這個規則很好理解，同一個執行緒中他們是用的同一個作業快取，是可見的，并且多個操作之間有先后依賴關系，則不允許對這些操作進行重排序，
2. volatile 變數規則
指對一個 volatile 變數的寫操作， Happens-Before 于后續對這個 volatile 變數的讀操作，
怎么理解呢？比如執行緒A對volatile變數進行寫操作，那么執行緒B讀取這個volatile變數是可見的，就是說能夠讀取到最新的值，
3.傳遞性
這條規則是指如果 A Happens-Before B，且 B Happens-Before C，那么 A Happens-Before C，
這個規則也比較容易理解，不展開討論了，
- 鎖的規則
這條規則是指對一個鎖的解鎖 Happens-Before于后續對這個鎖的加鎖，這里的鎖要是同一把鎖, 而且用synchronized或者ReentrantLock都可以，
如下代碼的例子：
synchronized (this) { // 此處自動加鎖
// x 是共享變數, 初始值 =10
if (this.x < 12) {
this.x = 12;
}
} // 此處自動解鎖
- 假設 x 的初始值是 8，執行緒 A 執行完代碼塊后 x 的值會變成 12（執行完自動釋放鎖）
- 執行緒 B 進入代碼塊時，能夠看到執行緒 A 對 x 的寫操作，也就是執行緒 B 能夠看到
x==12，
5.執行緒 start() 規則
主執行緒 A 啟動子執行緒 B 后，子執行緒 B 能夠看到主執行緒在啟動子執行緒 B 前的操作，
這個規則也很容易理解，執行緒 A 呼叫執行緒 B 的 start() 方法（即在執行緒 A 中啟動執行緒 B），那么該 start() 操作 Happens-Before 于執行緒 B 中的任意操作，
6.執行緒 join() 規則
執行緒 A 中，呼叫執行緒 B 的 join() 并成功回傳，那么執行緒 B 中的任意操作 Happens-Before 于該 join() 操作的回傳，
使用JMM規則
我們現在已經基本講清楚了JAVA記憶體模型規范，以及里面關鍵的Happens-Before規則，那有啥用呢？回到前言的問題中，我們是不是可以使用目前學到的關于JMM的知識去解決這個問題，
方案一： 使用volatile
根據JMM的第2條規則，主執行緒寫了volatile修飾的run變數，后面的t執行緒讀取的時候就可以看到了，
方案二：使用鎖
利用synchronized鎖的規則，主執行緒釋放鎖，那么后續t執行緒加鎖就可以看到之前的內容了，
小結：
volatile 關鍵字
- 保證可見性
- 不保證原子性
- 保證有序性（禁止指令重排）
volatile 修飾的變數進行讀操作與普通變數幾乎沒什么差別，但是寫操作相對慢一些，因為需要在本地代碼中插入很多記憶體屏障來保證指令不會發生亂序執行，但是開銷比鎖要小，volatile的性能遠比加鎖要好，
synchronized 關鍵字
- 保證可見性
- 不保證原子性
- 保證有序性
加了鎖之后，只能有一個執行緒獲得到了鎖，獲得不到鎖的執行緒就要阻塞，所以同一時間只有一個執行緒執行，相當于單執行緒，由于資料依賴性的存在，單執行緒的指令重排是沒有問題的，
執行緒加鎖前，將清空作業記憶體中共享變數的值，使用共享變數時需要從主記憶體中重新讀取最新的值；執行緒解鎖前，必須把共享變數的最新值重繪到主記憶體中，
總結
本文講解了JAVA并發的3大特性，可見性、有序性和原子性，從而引出了JAVA記憶體模型規范，這主要是為了解決并發情況下帶來的可見性和有序性問題，主要就是定義了一些規則，需要我們程式員懂得這些規則，然后根據實際場景去使用，就是使用volatile、synchronized、final關鍵字，主要final關鍵字也會讓其他執行緒可見，并且保證有序性，那么具體他們底層的實作是什么，是如何保證可見和有序的，我們后面詳細講解，
如果本文對你有幫助的話，請留下一個贊吧
更多技術干活和學習資料盡在個人公眾號——JAVA旭陽
本文來自博客園，作者：JAVA旭陽，轉載請注明原文鏈接：https://www.cnblogs.com/alvinscript/p/16960418.html
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/539302.html
標籤：Java
上一篇：Spring框架之IOC入門