目錄一、為什么要學習并發(fā)編程二、為什么需要并發(fā)編程三、從物理機中得到啟發(fā)四、Java 內(nèi)存模型五、原子性5.1、什么是原子性5.2、如何保證原子性六、可見性6.1、什么是可見性6.2、如何保證可見性七、有序性7.1、什么是有序性7.2、如何保證有序性一、為什么要學習并發(fā)編程

對于 “我們?yōu)槭裁匆獙W習并發(fā)編程？” 這個問題，就好比 “我們?yōu)槭裁匆獙W習政治？” 一樣，我們（至少作為學生黨是這樣）平常很少接觸到，然后背了一堆 “正確且偉大無比的廢話”，最終淪為八股被快速遺忘。

直到我開始去深入了解這塊知識而不是盲目背誦的時候，我才明白，它正確且偉大無比，但不是廢話。

盡管并發(fā)編程的各種底層原理以及其龐大的知識體系容易讓人心生畏懼，但是 Java 語言和 Java 虛擬機都提供了相當多的并發(fā)工具，替我們隱藏了很多的線程并發(fā)細節(jié)，使得我們在編碼時能更關注業(yè)務邏輯，把并發(fā)編程的門檻降低了不少。

但是無論語言、中間件和框架再如何先進，我們都不應該完全依賴于它們完成并發(fā)處理的所有事情，了解并發(fā)的內(nèi)幕并學習其中的思想，仍然是成為一個高級程序員的必經(jīng)之路。

我想，上面這段話大概可以回答 “我們?yōu)槭裁匆獙W習并發(fā)編程？” 這個問題了。

二、為什么需要并發(fā)編程

不知道各位有沒有聽說過被譽為計算機第一定律的摩爾定律，它是英特爾創(chuàng)始人之一戈登 · 摩爾長期觀察總結出來的經(jīng)驗，雖然不是嚴格推導出來的真理，但最起碼迄今為止仍然是令人深信不疑的。其核心內(nèi)容通俗來說就是 處理器的性能每隔兩年就會翻一倍。看起來像個廢話。

而事實上，當今多核 CPU 的發(fā)展速度也確實正在支撐著摩爾定律的有效性。在時代的大背景下，并發(fā)編程已成燎原之勢，通過并發(fā)編程的形式將多核 CPU 的計算能力發(fā)揮到極致，性能得到提升。

舉個例子，在當今諸神黃昏的圖像處理領域，很多圖像處理算法，在代碼初步編寫完畢并調(diào)試正確后，其實仍然需要進行一個漫長的優(yōu)化過程。因為盡管有些算法的處理效果很棒，但是如果運算太過耗時，還是無法集成進產(chǎn)品給用戶使用的。

對于一副 1000 x 800 分辨率的圖像，我們最原始的處理思路就是從第 1 個像素開始，一直遍歷計算到最后一個像素。那么面對如此龐大且復雜的計算量，為了提高算法的性能，最直接也最容易實現(xiàn)的想法就是基于多線程充分利用多核 CPU 的計算能力。

可以將整個圖像分成若干塊，比如我們的 CPU 是 8 核的，那么可以分成 8 塊，每塊圖像大小為 1000 * 100 像素，我們可以創(chuàng)建 8 個線程，每個線程處理一個圖像塊，每個 CPU 分配執(zhí)行一個線程。這樣，運算速度將得到明顯的提升。

當然了，這樣操作后，運算速度并不會恐怖的提升 4 倍，因為線程創(chuàng)建和釋放以及上下文切換都有一定的損耗。

這里摘錄《Java 并發(fā)編程的藝術》書中的一段話來回答這個問題，我們?yōu)槭裁葱枰l(fā)線程？

多核 CPU 時代的到來打破了單核 CPU 對多線程效能的限制。多個 CPU 意味著每個線程可以使用自己的 CPU 運行，這減少了線程上下文切換的開銷，但隨著對應用系統(tǒng)性能和吞吐量要求的提高，出現(xiàn)了處理海量數(shù)據(jù)和請求的要求，這些都對高并發(fā)編程有著迫切的需求。

而至于多核 CPU 盛行的原因，《深入理解 Java 虛擬機 - 第 3 版》一書中也有所涉及，這里我略作修改摘錄如下：

多任務處理在現(xiàn)代計算機操作系統(tǒng)中幾乎已是一項必備的功能了。在許多場景下，讓計算機同時去做幾件事情，不僅是因為計算機的運算能力強大了，更重要的原因是計算機的運算速度與它的存儲和通信子系統(tǒng)速度的差距太大，這樣 CPU 不得不花費大量的時間等待其他資源，比如磁盤 I/O、網(wǎng)絡通信或者數(shù)據(jù)庫訪問等。

為此，我們就必須使用一些手段去把處理器的運算能力“壓榨”出來，否則就會造成很大的性能浪費，而讓計算機同時處理幾項任務則是最容易想到，也被證明是非常有效的“壓榨”手段。

另外，除了充分利用計算機處理器的能力外，一個服務端要同時對多個客戶端提供服務，則是另一個更具體的并發(fā)應用場景。

三、從物理機中得到啟發(fā)

事實上，物理機遇到的并發(fā)問題與虛擬機中的情況有很多相似之處，物理機對并發(fā)的處理方案對虛擬機的實現(xiàn)也有相當大的參考意義，因此，我們有必要學習下物理機中處理問題的方法。

上文說過可以使用并發(fā)編程來充分利用 CPU 的資源，其中一個主要原因就是計算機的存儲設備與 CPU 的運算速度有著幾個數(shù)量級的差距，這樣 CPU 不得不花費大量的時間去等待其他資源。

這是軟件層面，而在硬件層面上，現(xiàn)代計算機系統(tǒng)都會在內(nèi)存與 CPU 之間加入一層或多層讀寫速度盡可能接近 CPU 運算速度的高速緩存來作為緩沖。

將運算需要使用的數(shù)據(jù)復制到緩存中，讓運算能快速進行，當運算結束后再從緩存同步回內(nèi)存之中，這樣處理器就無須等待緩慢的內(nèi)存讀寫了。

為此，這不可避免的帶來了一個新的問題：緩存一致性（Cache Coherence）。

就是說當多個 CPU 的運算任務都涉及同一塊主內(nèi)存區(qū)域時，將可能導致各自的緩存數(shù)據(jù)不一致。如果真的發(fā)生這種情況，那同步回到主內(nèi)存時該以誰的緩存數(shù)據(jù)為準呢？

為了解決一致性的問題，需要各個 CPU 訪問緩存時都遵循一些協(xié)議，在讀寫時要根據(jù)協(xié)議來進行操作。于是，我們引出了內(nèi)存模型的概念。

在物理機層面，內(nèi)存模型可以理解為在特定的操作協(xié)議下，對特定的內(nèi)存或高速緩存進行讀寫訪問的過程抽象。

顯然，不同架構的物理機器可以擁有不一樣的內(nèi)存模型，而 Java 虛擬機也擁有自己的內(nèi)存模型，稱為 Java 內(nèi)存模型（Java Memory Model，JMM），其目的就是為了屏蔽各種硬件和操作系統(tǒng)的內(nèi)存訪問差異，以實現(xiàn)讓 Java 程序在各種平臺下都能達到一致的內(nèi)存訪問效果。

當然了，JMM 與這里我們介紹的物理機的內(nèi)存模型具有高度的可類比性。

四、Java 內(nèi)存模型

JMM 規(guī)定了所有的變量都存儲在主內(nèi)存（Main Memory）中，每條線程還有自己的工作內(nèi)存（Working Memory）。

線程的工作內(nèi)存中保存了被該線程使用的變量的主內(nèi)存副本，線程對變量的所有操作（讀取、賦值等）都必須在工作內(nèi)存中進行，而不能直接讀寫主內(nèi)存中的數(shù)據(jù)。

此處的主內(nèi)存可以與前面所說的物理機的主內(nèi)存類比，當然，實際上它僅是虛擬機內(nèi)存的一部分，工作內(nèi)存可與前面講的高速緩存類比。

《Java 并發(fā)編程的藝術》中把 “工作內(nèi)存” 稱為 “本地內(nèi)存”（Local Memory）。 “工作內(nèi)存” 是《深入理解 Java 虛擬機 - 第 3 版》這本書中的寫法。

多提一嘴，這里的變量其實和我們?nèi)粘＞幊讨兴f的變量不一樣，它包括了實例字段、靜態(tài)字段和構成數(shù)組對象的元素，但是不包括局部變量與方法參數(shù)，因為后面這倆是線程私有的，不會被共享，自然就不會存在競爭問題。各位知道就好，不必太過深究。

五、原子性5.1、什么是原子性

類比物理機，擁有緩存一致性協(xié)議來規(guī)定主內(nèi)存和高速緩存之間的操作邏輯，那么 JMM 中主內(nèi)存與工作內(nèi)存之間有沒有具體的交互協(xié)議呢？

Of Course！JMM 中定義了以下 8 種操作規(guī)范來完成一個變量從主內(nèi)存拷貝到工作內(nèi)存、以及從工作內(nèi)存同步回主內(nèi)存這一類的實現(xiàn)細節(jié)。Java 虛擬機實現(xiàn)時必須保證下面提及的每一種操作都是原子的、不可再分的。

暫時放下到底是哪 8 種操作，我們先談何為原子？

原子（atomic）本意是 “不能被進一步分割的最小粒子”，而原子操作（atomic operation）意為 “不可被中斷的一個或一系列操作”。

舉個經(jīng)典的簡單例子，銀行轉賬，A 像 B 轉賬 100 元。轉賬這個操作其實包含兩個離散的步驟：

步驟 1：A 賬戶減去 100 步驟 2：B 賬戶增加 100

我們要求轉賬這個操作是原子性的，也就是說步驟 1 和步驟 2 是順續(xù)執(zhí)行且不可被打斷的，要么全部執(zhí)行成功、要么執(zhí)行失敗。

試想一下，如果轉賬操作不具備原子性會導致什么問題呢？

比如說步驟 1 執(zhí)行成功了，但是步驟 2 沒有執(zhí)行或者執(zhí)行失敗，就會導致 A 賬戶少了 100 但是 B 賬戶并沒有相應的多出 100。

對于上述這種情況，符合原子性的轉賬操作應該是如果步驟 2 執(zhí)行失敗，那么整個轉賬操作就會失敗，步驟 1 就會回滾，并不會將 A 賬戶減少 100。

OK，了解了原子性的概念后，我們再來看 JMM 定義的 8 種原子操作具體是啥，以下了解即可，沒必要死記：

lock（鎖定）：作用于主內(nèi)存的變量，它把一個變量標識為一條線程獨占的狀態(tài)。 unlock（解鎖）：作用于主內(nèi)存的變量，它把一個處于鎖定狀態(tài)的變量釋放出來，釋放后的變量才可以被其他線程鎖定。 read（讀取）：作用于主內(nèi)存的變量，它把一個變量的值從主內(nèi)存?zhèn)鬏數(shù)骄€程的工作內(nèi)存中，以便隨后的load動作使用。 load（載入）：作用于工作內(nèi)存的變量，它把read操作從主內(nèi)存中得到的變量值放入工作內(nèi)存的變量副本中。 use（使用）：作用于工作內(nèi)存的變量，它把工作內(nèi)存中一個變量的值傳遞給執(zhí)行引擎，每當虛擬機遇到一個需要使用變量的值的字節(jié)碼指令時將會執(zhí)行這個操作。 assign（賦值）：作用于工作內(nèi)存的變量，它把一個從執(zhí)行引擎接收的值賦給工作內(nèi)存的變量，每當虛擬機遇到一個給變量賦值的字節(jié)碼指令時執(zhí)行這個操作。 store（存儲）：作用于工作內(nèi)存的變量，它把工作內(nèi)存中一個變量的值傳送到主內(nèi)存中，以便隨后的write操作使用。 write（寫入）：作用于主內(nèi)存的變量，它把store操作從工作內(nèi)存中得到的變量的值放入主內(nèi)存的變量

事實上，對于 double 和 long 類型的變量來說，load、store、read 和 write 操作在某些平臺上允許有例外，稱為 “l(fā)ong 和 double 的非原子性協(xié)定”，不過一般不需要我們特別注意，這里就不再過多贅述了。

這 8 種操作當然不是可以隨便用的，為了保證 Java 程序中的內(nèi)存訪問操作在并發(fā)下仍然是線程安全的，JMM 規(guī)定了在執(zhí)行上述 8 種基本操作時必須滿足的一系列規(guī)則。

這我就不一一列舉了，多提這么一嘴的原因就是下文會涉及一些這其中的規(guī)則，為了防止大家看的時候云里霧里，所以先前說明白比較好。

上面我們舉了一個轉賬的例子，那么，在具體的代碼中，非原子性操作可能會導致什么問題呢？

看下面這段代碼，各位不妨考慮一個的問題，如果兩個線程對初始值為 0 的靜態(tài)變量一個做自增，一個做自減，各做 5000 次，結果一定是 0 嗎？

耳熟能詳?shù)膯栴}，我們無法保證這段代碼執(zhí)行結果的一定性（正確性），可能是正數(shù)、也可能是負數(shù)、當然也可能是 0。

那么，我們就把這段代碼稱為線程不安全的，就是說在單線程環(huán)境下正常運行的一段代碼，在多線程環(huán)境中可能發(fā)生各種意外情況，導致無法得到正確的結果。

從線程安全的角度來反向理解線程不安全的概念可能更容易點，這里參考《Java 并發(fā)編程實踐》上面的一句話：

一段代碼在被多個線程訪問后，它仍然能夠進行正確的行為，那這段代碼就是線程安全的。

至于這段代碼線程不安全的原因，就是 Java 中對靜態(tài)變量自增和自減操作并不是原子操作，它倆其實都包含三個離散的操作：

步驟 1：讀取當前 i 的值 步驟 2：將 i 的值加 1（減 1） 步驟 3：寫回新值

可以看出來這是一個 讀 - 改 - 寫 的操作。

以 i ++ 操作為例，我們來看看它對應的字節(jié)碼指令：

上方這段代碼對應的字節(jié)碼是這樣的：

簡單解釋下這些字節(jié)碼指令的含義：

getstatic i：獲取靜態(tài)變量 i 的值 iconst_1：準備常量 1 iadd：自增（自減操作對應 isub） putstatic i：將修改后的值存入靜態(tài)變量 i

如果是在單線程的環(huán)境下，先自增 5000 次，然后再自減 5000 次，那當然不會發(fā)生任何問題。

但是在多線程的環(huán)境下，由于 CPU 時間片調(diào)度的原因，可能 Thread1 正在執(zhí)行自增操作著呢，CPU 剝奪了它的資源占用，轉而分配給了 Thread2，也就是發(fā)生了線程上下文切換。這樣，就可能導致本該是一個連續(xù)的讀改寫動作（連續(xù)執(zhí)行的三個步驟）被打斷了。

下圖出現(xiàn)的就是結果最終是負數(shù)的情況：

總結來說，如果多個 CPU 同時對某個共享變量進行讀-改-寫操作，那么這個共享變量就會被多個 CPU 同時處理，由于 CPU 時間片調(diào)度等原因，某個線程的讀-改-寫操作可能會被其他線程打斷，導致操作完后共享變量的值和我們期望的不一致。

另外，多說一嘴，除了自增自減，我們常見的 i = j 這個操作也是非原子性的，它分為兩個離散的步驟：

步驟 1：讀取 j 的值 步驟 2：將 j 的值賦給 i5.2、如何保證原子性

那么，如何實現(xiàn)原子操作，也就是如何保證原子性呢？

對于這個問題，其實在處理器和 Java 編程語言層面，它們都提供了一些有效的措施，比如處理器提供了總線鎖和緩存鎖，Java 提供了鎖和循環(huán) CAS 的方式，這里我們簡單解釋下 Java 保證原子性的措施。

由 Java 內(nèi)存模型來直接保證的原子性變量操作包括 read、load、assign、use、store 和 write 這 6 個，我們大致可以認為，基本數(shù)據(jù)類型的訪問、讀寫都是具備原子性的（例外就是 long 和 double 的非原子性協(xié)定，各位只要知道這件事情就可以了，無須太過在意這些幾乎不會發(fā)生的例外情況）。

如果應用場景需要一個更大范圍的原子性保證，Java 內(nèi)存模型還提供了 lock 和 unlock 操作來滿足這種需求。

盡管 JVM 并沒有把 lock 和 unlock 操作直接開放給用戶使用，但是卻提供了更高層次的字節(jié)碼指令 monitorenter 和 monitorexit 來隱式地使用這兩個操作。這兩個字節(jié)碼指令反映到 Java 代碼中就是同步塊 — synchronized 關鍵字，因此在 synchronized 塊之間的操作也具備原子性。

而除了 synchronized 關鍵字這種 Java 語言層面的鎖，juc 并發(fā)包中的 java.util.concurrent.locks.Lock 接口也提供了一些類庫層面的鎖，比如 ReentrantLock。

另外，隨著硬件指令集的發(fā)展，在 JDK 5 之后，Java 類庫中開始使用基于 cmpxchg 指令的 CAS 操作（又來一個重點），該操作由 sun.misc.Unsafe 類里面的 compareAndSwapInt() 和 compareAndSwapLong() 等幾個方法包裝提供。不過在 JDK 9 之前 Unsafe 類是不開放給用戶使用的，只有 Java 類庫可以使用，譬如 juc 包里面的整數(shù)原子類，其中的 compareAndSet() 和 getAndIncrement() 等方法都使用了 Unsafe 類的 CAS 操作來實現(xiàn)。

使用這種 CAS 措施的代碼也常被稱為無鎖編程（Lock-Free）。

六、可見性6.1、什么是可見性

回到物理機，前文說過，由于引入了高速緩存，不可避免的帶來了一個新的問題：緩存一致性。而同樣的，這個問題在 Java 虛擬機中同樣存在，表現(xiàn)為工作內(nèi)存與主內(nèi)存的同步延遲，也就是內(nèi)存可見性問題。

何為可見性？就是指當一個線程修改了共享變量的值時，其他線程能夠立即得知這個修改。

回顧下 Java 內(nèi)存模型：

從上圖來看，如果線程 A 與線程 B 之間要通信的話，必須要經(jīng)歷下面 2 個步驟：

1）線程 A 把工作內(nèi)存 A 中更新過的共享變量刷新到主內(nèi)存中去 2）線程 B 到主內(nèi)存中去讀取線程 A 之前已更新過的共享變量

也就是說，線程 A 在向線程 B 的通信過程必須要經(jīng)過主內(nèi)存。

那么，這就可能出現(xiàn)一個問題，舉個簡單的例子，看下面這段代碼：

// 線程 1 執(zhí)行的代碼int i = 0;i = 1;// 線程 2 執(zhí)行的代碼j = i;

當線程 1 執(zhí)行 i = 1 這句時，會先去主內(nèi)存中讀取 i 的初始值，然后加載到線程 1 的的工作內(nèi)存中，再賦值為1，至此，線程 1 的工作內(nèi)存當中 i 的值變?yōu)?1 了，不過還沒有寫入到主內(nèi)存當中。

如果在線程 1 準備把新的 i 值寫回主內(nèi)存的時候，線程 2 執(zhí)行了 j = i 這條語句，它會去主存讀取 i 的值并加載到線程 2 的工作內(nèi)存當中，而此時主內(nèi)存當中 i 的值還是 0，那么就會使得 j 的值為 0，而不是 1。

這就是內(nèi)存可見性問題，線程 1 修改了共享變量 i 的值，線程 2 并沒有立即得知這個修改。

6.2、如何保證可見性

各位可能脫口而出使用 volatile 關鍵字修飾共享變量，但除了這個，容易被大家忽略的是，其實 sunchronized 和 final 這倆關鍵字也能保證可見性。

上面我提過一嘴，為了保證 Java 程序中的內(nèi)存訪問操作在并發(fā)下仍然是線程安全的，JMM 規(guī)定了在執(zhí)行 8 種基本原子操作時必須滿足的一系列規(guī)則，這其中有一條規(guī)則正是 sychronized 能夠保證原子性的理論支撐，如下：

對一個變量執(zhí)行 unlock 操作之前，必須先把此變量同步回主內(nèi)存中（執(zhí)行 store、write 操作）

也就是說 synchronized在修改了工作內(nèi)存中的變量后，解鎖前會將工作內(nèi)存修改的內(nèi)容刷新到主內(nèi)存中，確保了共享變量的值是最新的，也就保證了可見性。

至于 final 關鍵字的可見性需要結合其內(nèi)存語義深入來講，這里就先簡單的概括下：被 final 修飾的字段在構造器中一旦被初始化完成，并且構造器沒有把 this 的引用傳遞出去，那么在其他線程中就能看見 final 字段的值。

七、有序性7.1、什么是有序性

OK，說完了可見性，我們再回到物理機，其實除了增加高速緩存之外，為了使 CPU 內(nèi)部的運算單元能盡量被充分利用，CPU 可能會對輸入代碼進行亂序執(zhí)行優(yōu)化，CPU 會在計算之后將亂序執(zhí)行的結果重組，保證該結果與順序執(zhí)行的結果是一致的，但并不保證程序中各個語句計算的先后順序與輸入代碼中的順序一致，因此如果存在一個計算任務依賴另外一個計算任務的中間結果，那么其順序性并不能靠代碼的先后順序來保證。

與之類似的，Java 的編譯器也有這樣的一種優(yōu)化手段：指令重排序（Instruction Reorder）。

那么，既然能夠優(yōu)化性能，重排序可以沒有限制的被使用嗎？

當然不，在重排序的時候，CPU 和編譯器都需要遵守一個規(guī)矩，這個規(guī)矩就是 as-if-serial 語義：不管怎么重排序，單線程環(huán)境下程序的執(zhí)行結果不能被改變。

為了遵守 as-if-serial 語義，CPU 和編譯器不會對存在數(shù)據(jù)依賴關系的操作做重排序，因為這種重排序會改變執(zhí)行結果。

那么這里，我們又引出了 “數(shù)據(jù)依賴性” 的概念。

如果兩個操作訪問同一個變量，且這兩個操作中有一個為寫操作，此時這兩個操作之間就存在數(shù)據(jù)依賴性。

數(shù)據(jù)依賴性分為三種類型：寫后讀、寫后寫、讀后寫，看下圖

上面 3 種情況，只要重排序兩個操作的執(zhí)行順序，程序的執(zhí)行結果就會被改變。

其實考慮數(shù)據(jù)依賴關系的時候，各位可以通過畫圖來直觀的判斷。舉個例子：

int a = 1; // Aint b = 2; // Bint sum = a + b; // C

上面 3 個操作的數(shù)據(jù)依賴關系如下圖所示：

可以看出，A 和 C、B 和 C 之間存在數(shù)據(jù)依賴關系，因此在最終執(zhí)行的指令序列中，C 不能被重排序到 A 或B 的前面。但 A 和 B 之間沒有數(shù)據(jù)依賴關系，所以 CPU 和處理器可以重排序 A 和 B 之間的執(zhí)行順序。如下是程序的兩種執(zhí)行順序：

看起來好像沒啥問題，重排序之后程序的結果并沒有發(fā)生改變，還提升了性能。

然而，很不幸的是，我們這里所說的數(shù)據(jù)依賴性僅針對單個 CPU 中執(zhí)行的指令序列和單個線程中執(zhí)行的操作，不同 CPU 之間和不同線程之間的數(shù)據(jù)依賴性是不被 CPU 和編譯器考慮的。

這就是為啥我在寫 as-if-serial 語義的時候把 “單線程” 加粗的目的了。

看下面這段代碼：

假設有兩個線程 A 和 B，A 首先執(zhí)行 writer() 方法，隨后 B 線程接著執(zhí)行 reader() 方法。線程 B 在執(zhí)行操作 4 時，能否看到線程 A 在操作 1 把共享變量 a 修改成了 1 呢？

答案是不一定。

由于操作 1 和操作 2 沒有數(shù)據(jù)依賴關系，CPU 和編譯器可以對這兩個操作重排序；同樣的，操作 3 和操作 4 沒有數(shù)據(jù)依賴關系，編譯器和處理器也可以對這兩個操作重排序。

以操作 1 和操作 2 重排序為例，可能會產(chǎn)生什么效果呢？

如上圖右邊所示，程序執(zhí)行時，線程 A 首先寫標記變量 flag，隨后線程 B 讀這個變量。由于條件判斷為真，線程 B 將讀取變量 a。此時，變量 a 還沒有被線程 A 寫入，因此線程 B 讀到的 a 值仍然是 0。也就是說在這里多線程程序的語義被重排序破壞了。

這樣，我們可以得出結論：CPU 和 Java 編譯器為了優(yōu)化程序性能，會自發(fā)地對指令序列進行重新排序。在多線程的環(huán)境下，由于重排序的存在，就可能導致程序運行結果出現(xiàn)錯誤。

了解了重排序的概念，我們可以這樣總結下 Java 程序天然的有序性：

如果在本線程內(nèi)觀察，所有的操作都是有序的（簡單來說就是線程內(nèi)表現(xiàn)為串行） 如果在一個線程中觀察另一個線程，所有的操作都是無序的（這個無序主要就是指 “指令重排序” 現(xiàn)象和 “工作內(nèi)存與主內(nèi)存同步延遲” 現(xiàn)象）7.2、如何保證有序性

Java 語言提供了 volatile 和 synchronized 兩個關鍵字來保證線程之間操作的有序性。

volatile 本身除了保證可見性的語義外，還包含了禁止指令重排序的語義，所以天生就具有保證有序性的功能。

而 synchronized 保證有序性的理論支撐，仍然是 JMM 規(guī)定在執(zhí)行 8 種基本原子操作時必須滿足的一系列規(guī)則中的某一個提供的：

一個變量在同一個時刻只允許一條線程對其進行 lock 操作

這個規(guī)則決定了持有同一個鎖的兩個 synchronized 同步塊只能串行地進入。

不是很難理解吧，通俗來說，synchronized 通過排他鎖的方式保證了同一時間內(nèi)，被 synchronized 修飾的代碼是單線程執(zhí)行的。所以，這就滿足了 as-if-serial 語義的一個關鍵前提，那就是單線程，這樣，有了 as-if-serial 語義的保證，單線程的有序性也就得到保障了。

Happens-before 原則：

Happens-before 是 JMM 的靈魂，它是判斷數(shù)據(jù)是否存在競爭，線程是否安全的非常有用的手段。為了知識體系的完整性，這里簡單提一下，后續(xù)文章會詳細解釋的。

如果 Java 內(nèi)存模型中所有的有序性都僅靠 volatile 和 synchronized 來完成，那么有很多操作都將會變得非常??攏??俏頤竊詒嘈 Java 并發(fā)代碼的時候并沒有察覺到這一點，這就歸功于 “先行發(fā)生”（Happens-Before）原則。

依賴這個原則，我們可以通過幾條簡單規(guī)則快速解決并發(fā)環(huán)境下兩個操作之間是否可能存在沖突的所有問題，而不需要陷入 Java 內(nèi)存模型苦澀難懂的定義之中。

以上就是詳細分析Java內(nèi)存模型的詳細內(nèi)容，更多關于Java內(nèi)存模型的資料請關注好吧啦網(wǎng)其它相關文章！