這篇文章主要介紹“Java內(nèi)存模型與原子性、可見(jiàn)性、有序性分別是什么”，在日常操作中，相信很多人在Java內(nèi)存模型與原子性、可見(jiàn)性、有序性分別是什么問(wèn)題上存在疑惑，小編查閱了各式資料，整理出簡(jiǎn)單好用的操作方法，希望對(duì)大家解答”Java內(nèi)存模型與原子性、可見(jiàn)性、有序性分別是什么”的疑惑有所幫助！接下來(lái)，請(qǐng)跟著小編一起來(lái)學(xué)習(xí)吧！
我們注重客戶(hù)提出的每個(gè)要求，我們充分考慮每一個(gè)細(xì)節(jié)，我們積極的做好網(wǎng)站設(shè)計(jì)、成都做網(wǎng)站服務(wù)，我們努力開(kāi)拓更好的視野，通過(guò)不懈的努力，成都創(chuàng)新互聯(lián)贏得了業(yè)內(nèi)的良好聲譽(yù)，這一切，也不斷的激勵(lì)著我們更好的服務(wù)客戶(hù)。 主要業(yè)務(wù)：網(wǎng)站建設(shè),網(wǎng)站制作,網(wǎng)站設(shè)計(jì),重慶小程序開(kāi)發(fā),網(wǎng)站開(kāi)發(fā),技術(shù)開(kāi)發(fā)實(shí)力，DIV+CSS，PHP及ASP，ASP.Net，SQL數(shù)據(jù)庫(kù)的技術(shù)開(kāi)發(fā)工程師。
對(duì)于 “我們?yōu)槭裁匆獙W(xué)習(xí)并發(fā)編程?” 這個(gè)問(wèn)題，就好比 “我們?yōu)槭裁匆獙W(xué)習(xí)政治?” 一樣，我們(至少作為學(xué)生黨是這樣)平常很少接觸到，然后背了一堆 “正確且偉大無(wú)比的廢話”，最終淪為八股被快速遺忘。
直到我開(kāi)始去深入了解這塊知識(shí)而不是盲目背誦的時(shí)候，我才明白，它正確且偉大無(wú)比，但不是廢話。
盡管并發(fā)編程的各種底層原理以及其龐大的知識(shí)體系容易讓人心生畏懼，但是 Java 語(yǔ)言和 Java 虛擬機(jī)都提供了相當(dāng)多的并發(fā)工具，替我們隱藏了很多的線程并發(fā)細(xì)節(jié)，使得我們?cè)诰幋a時(shí)能更關(guān)注業(yè)務(wù)邏輯，把并發(fā)編程的門(mén)檻降低了不少。
但是無(wú)論語(yǔ)言、中間件和框架再如何先進(jìn)，我們都不應(yīng)該完全依賴(lài)于它們完成并發(fā)處理的所有事情，了解并發(fā)的內(nèi)幕并學(xué)習(xí)其中的思想，仍然是成為一個(gè)高級(jí)程序員的必經(jīng)之路。
我想，上面這段話大概可以回答 “我們?yōu)槭裁匆獙W(xué)習(xí)并發(fā)編程?” 這個(gè)問(wèn)題了。
不知道各位有沒(méi)有聽(tīng)說(shuō)過(guò)被譽(yù)為計(jì)算機(jī)第一定律的摩爾定律，它是英特爾創(chuàng)始人之一戈登 · 摩爾長(zhǎng)期觀察總結(jié)出來(lái)的經(jīng)驗(yàn)，雖然不是嚴(yán)格推導(dǎo)出來(lái)的真理，但最起碼迄今為止仍然是令人深信不疑的。其核心內(nèi)容通俗來(lái)說(shuō)就是 處理器的性能每隔兩年就會(huì)翻一倍?？雌饋?lái)像個(gè)廢話(狗頭)。
而事實(shí)上，當(dāng)今多核 CPU 的發(fā)展速度也確實(shí)正在支撐著摩爾定律的有效性。在時(shí)代的大背景下，并發(fā)編程已成燎原之勢(shì)，通過(guò)并發(fā)編程的形式將多核 CPU 的計(jì)算能力發(fā)揮到極致，性能得到提升。
舉個(gè)例子，在當(dāng)今諸神黃昏的圖像處理領(lǐng)域，很多圖像處理算法，在代碼初步編寫(xiě)完畢并調(diào)試正確后，其實(shí)仍然需要進(jìn)行一個(gè)漫長(zhǎng)的優(yōu)化過(guò)程。因?yàn)楸M管有些算法的處理效果很棒，但是如果運(yùn)算太過(guò)耗時(shí)，還是無(wú)法集成進(jìn)產(chǎn)品給用戶(hù)使用的。
對(duì)于一副 1000 x 800 分辨率的圖像，我們最原始的處理思路就是從第 1 個(gè)像素開(kāi)始，一直遍歷計(jì)算到最后一個(gè)像素。那么面對(duì)如此龐大且復(fù)雜的計(jì)算量，為了提高算法的性能，最直接也最容易實(shí)現(xiàn)的想法就是基于多線程充分利用多核 CPU 的計(jì)算能力。
可以將整個(gè)圖像分成若干塊，比如我們的 CPU 是 8 核的，那么可以分成 8 塊，每塊圖像大小為 1000 * 100 像素，我們可以創(chuàng)建 8 個(gè)線程，每個(gè)線程處理一個(gè)圖像塊，每個(gè) CPU 分配執(zhí)行一個(gè)線程。這樣，運(yùn)算速度將得到明顯的提升。
當(dāng)然了，這樣操作后，運(yùn)算速度并不會(huì)恐怖的提升 4 倍，因?yàn)榫€程創(chuàng)建和釋放以及上下文切換都有一定的損耗。
這里摘錄《Java 并發(fā)編程的藝術(shù)》書(shū)中的一段話來(lái)回答這個(gè)問(wèn)題，我們?yōu)槭裁葱枰l(fā)線程?
多核 CPU 時(shí)代的到來(lái)打破了單核 CPU 對(duì)多線程效能的限制。多個(gè) CPU 意味著每個(gè)線程可以使用自己的 CPU 運(yùn)行，這減少了線程上下文切換的開(kāi)銷(xiāo)，但隨著對(duì)應(yīng)用系統(tǒng)性能和吞吐量要求的提高，出現(xiàn)了處理海量數(shù)據(jù)和請(qǐng)求的要求，這些都對(duì)高并發(fā)編程有著迫切的需求。
而至于多核 CPU 盛行的原因，《深入理解 Java 虛擬機(jī) - 第 3 版》一書(shū)中也有所涉及，這里我略作修改摘錄如下：
多任務(wù)處理在現(xiàn)代計(jì)算機(jī)操作系統(tǒng)中幾乎已是一項(xiàng)必備的功能了。在許多場(chǎng)景下，讓計(jì)算機(jī)同時(shí)去做幾件事情，不僅是因?yàn)橛?jì)算機(jī)的運(yùn)算能力強(qiáng)大了，更重要的原因是計(jì)算機(jī)的運(yùn)算速度與它的存儲(chǔ)和通信子系統(tǒng)速度的差距太大，這樣 CPU 不得不花費(fèi)大量的時(shí)間等待其他資源，比如磁盤(pán) I/O、網(wǎng)絡(luò)通信或者數(shù)據(jù)庫(kù)訪問(wèn)等。
為此，我們就必須使用一些手段去把處理器的運(yùn)算能力“壓榨”出來(lái)，否則就會(huì)造成很大的性能浪費(fèi)，而讓計(jì)算機(jī)同時(shí)處理幾項(xiàng)任務(wù)則是最容易想到，也被證明是非常有效的“壓榨”手段。
另外，除了充分利用計(jì)算機(jī)處理器的能力外，一個(gè)服務(wù)端要同時(shí)對(duì)多個(gè)客戶(hù)端提供服務(wù)，則是另一個(gè)更具體的并發(fā)應(yīng)用場(chǎng)景。
事實(shí)上，物理機(jī)遇到的并發(fā)問(wèn)題與虛擬機(jī)中的情況有很多相似之處，物理機(jī)對(duì)并發(fā)的處理方案對(duì)虛擬機(jī)的實(shí)現(xiàn)也有相當(dāng)大的參考意義，因此，我們有必要學(xué)習(xí)下物理機(jī)中處理問(wèn)題的方法。
上文說(shuō)過(guò)可以使用并發(fā)編程來(lái)充分利用 CPU 的資源，其中一個(gè)主要原因就是計(jì)算機(jī)的存儲(chǔ)設(shè)備與 CPU 的運(yùn)算速度有著幾個(gè)數(shù)量級(jí)的差距，這樣 CPU 不得不花費(fèi)大量的時(shí)間去等待其他資源。
這是軟件層面，而在硬件層面上，現(xiàn)代計(jì)算機(jī)系統(tǒng)都會(huì)在內(nèi)存與 CPU 之間加入一層或多層讀寫(xiě)速度盡可能接近 CPU 運(yùn)算速度的高速緩存來(lái)作為緩沖。
將運(yùn)算需要使用的數(shù)據(jù)復(fù)制到緩存中，讓運(yùn)算能快速進(jìn)行，當(dāng)運(yùn)算結(jié)束后再?gòu)木彺嫱交貎?nèi)存之中，這樣處理器就無(wú)須等待緩慢的內(nèi)存讀寫(xiě)了。
為此，這不可避免的帶來(lái)了一個(gè)新的問(wèn)題：緩存一致性(Cache Coherence)。
就是說(shuō)當(dāng)多個(gè) CPU 的運(yùn)算任務(wù)都涉及同一塊主內(nèi)存區(qū)域時(shí)，將可能導(dǎo)致各自的緩存數(shù)據(jù)不一致。如果真的發(fā)生這種情況，那同步回到主內(nèi)存時(shí)該以誰(shuí)的緩存數(shù)據(jù)為準(zhǔn)呢?
為了解決一致性的問(wèn)題，需要各個(gè) CPU 訪問(wèn)緩存時(shí)都遵循一些協(xié)議，在讀寫(xiě)時(shí)要根據(jù)協(xié)議來(lái)進(jìn)行操作。于是，我們引出了內(nèi)存模型的概念。
在物理機(jī)層面，內(nèi)存模型可以理解為在特定的操作協(xié)議下，對(duì)特定的內(nèi)存或高速緩存進(jìn)行讀寫(xiě)訪問(wèn)的過(guò)程抽象。
顯然，不同架構(gòu)的物理機(jī)器可以擁有不一樣的內(nèi)存模型，而 Java 虛擬機(jī)也擁有自己的內(nèi)存模型，稱(chēng)為 Java 內(nèi)存模型(Java Memory Model，JMM)，其目的就是為了屏蔽各種硬件和操作系統(tǒng)的內(nèi)存訪問(wèn)差異，以實(shí)現(xiàn)讓 Java 程序在各種平臺(tái)下都能達(dá)到一致的內(nèi)存訪問(wèn)效果。
當(dāng)然了，JMM 與這里我們介紹的物理機(jī)的內(nèi)存模型具有高度的可類(lèi)比性。
JMM 規(guī)定了所有的變量都存儲(chǔ)在主內(nèi)存(Main Memory)中，每條線程還有自己的工作內(nèi)存(Working Memory)。
線程的工作內(nèi)存中保存了被該線程使用的變量的主內(nèi)存副本，線程對(duì)變量的所有操作(讀取、賦值等)都必須在工作內(nèi)存中進(jìn)行，而不能直接讀寫(xiě)主內(nèi)存中的數(shù)據(jù)。
此處的主內(nèi)存可以與前面所說(shuō)的物理機(jī)的主內(nèi)存類(lèi)比，當(dāng)然，實(shí)際上它僅是虛擬機(jī)內(nèi)存的一部分，工作內(nèi)存可與前面講的高速緩存類(lèi)比。
《Java 并發(fā)編程的藝術(shù)》中把 “工作內(nèi)存” 稱(chēng)為 “本地內(nèi)存”(Local Memory)?！肮ぷ鲀?nèi)存” 是《深入理解 Java 虛擬機(jī) - 第 3 版》這本書(shū)中的寫(xiě)法。
多提一嘴，這里的變量其實(shí)和我們?nèi)粘＞幊讨兴f(shuō)的變量不一樣，它包括了實(shí)例字段、靜態(tài)字段和構(gòu)成數(shù)組對(duì)象的元素，但是不包括局部變量與方法參數(shù)，因?yàn)楹竺孢@倆是線程私有的，不會(huì)被共享，自然就不會(huì)存在競(jìng)爭(zhēng)問(wèn)題。各位知道就好，不必太過(guò)深究。
什么是原子性
類(lèi)比物理機(jī)，擁有緩存一致性協(xié)議來(lái)規(guī)定主內(nèi)存和高速緩存之間的操作邏輯，那么 JMM 中主內(nèi)存與工作內(nèi)存之間有沒(méi)有具體的交互協(xié)議呢?
Of Course!JMM 中定義了以下 8 種操作規(guī)范來(lái)完成一個(gè)變量從主內(nèi)存拷貝到工作內(nèi)存、以及從工作內(nèi)存同步回主內(nèi)存這一類(lèi)的實(shí)現(xiàn)細(xì)節(jié)。Java 虛擬機(jī)實(shí)現(xiàn)時(shí)必須保證下面提及的每一種操作都是原子的、不可再分的。
暫時(shí)放下到底是哪 8 種操作，我們先談何為原子?
原子(atomic)本意是 “不能被進(jìn)一步分割的最小粒子”，而原子操作(atomic operation)意為 “不可被中斷的一個(gè)或一系列操作”。
舉個(gè)經(jīng)典的簡(jiǎn)單例子，銀行轉(zhuǎn)賬，A 像 B 轉(zhuǎn)賬 100 元。轉(zhuǎn)賬這個(gè)操作其實(shí)包含兩個(gè)離散的步驟：
步驟 1：A 賬戶(hù)減去 100
步驟 2：B 賬戶(hù)增加 100
我們要求轉(zhuǎn)賬這個(gè)操作是原子性的，也就是說(shuō)步驟 1 和步驟 2 是順續(xù)執(zhí)行且不可被打斷的，要么全部執(zhí)行成功、要么執(zhí)行失敗。
試想一下，如果轉(zhuǎn)賬操作不具備原子性會(huì)導(dǎo)致什么問(wèn)題呢?
比如說(shuō)步驟 1 執(zhí)行成功了，但是步驟 2 沒(méi)有執(zhí)行或者執(zhí)行失敗，就會(huì)導(dǎo)致 A 賬戶(hù)少了 100 但是 B 賬戶(hù)并沒(méi)有相應(yīng)的多出 100。
對(duì)于上述這種情況，符合原子性的轉(zhuǎn)賬操作應(yīng)該是如果步驟 2 執(zhí)行失敗，那么整個(gè)轉(zhuǎn)賬操作就會(huì)失敗，步驟 1 就會(huì)回滾，并不會(huì)將 A 賬戶(hù)減少 100。
OK，了解了原子性的概念后，我們?cè)賮?lái)看 JMM 定義的 8 種原子操作具體是啥，以下了解即可，沒(méi)必要死記：
lock(鎖定)：作用于主內(nèi)存的變量，它把一個(gè)變量標(biāo)識(shí)為一條線程獨(dú)占的狀態(tài)。
unlock(解鎖)：作用于主內(nèi)存的變量，它把一個(gè)處于鎖定狀態(tài)的變量釋放出來(lái)，釋放后的變量才可以被其他線程鎖定。
read(讀取)：作用于主內(nèi)存的變量，它把一個(gè)變量的值從主內(nèi)存?zhèn)鬏數(shù)骄€程的工作內(nèi)存中，以便隨后的load動(dòng)作使用。
load(載入)：作用于工作內(nèi)存的變量，它把read操作從主內(nèi)存中得到的變量值放入工作內(nèi)存的變量副本中。
use(使用)：作用于工作內(nèi)存的變量，它把工作內(nèi)存中一個(gè)變量的值傳遞給執(zhí)行引擎，每當(dāng)虛擬機(jī)遇到一個(gè)需要使用變量的值的字節(jié)碼指令時(shí)將會(huì)執(zhí)行這個(gè)操作。
assign(賦值)：作用于工作內(nèi)存的變量，它把一個(gè)從執(zhí)行引擎接收的值賦給工作內(nèi)存的變量，每當(dāng)虛擬機(jī)遇到一個(gè)給變量賦值的字節(jié)碼指令時(shí)執(zhí)行這個(gè)操作。
store(存儲(chǔ))：作用于工作內(nèi)存的變量，它把工作內(nèi)存中一個(gè)變量的值傳送到主內(nèi)存中，以便隨后的write操作使用。
write(寫(xiě)入)：作用于主內(nèi)存的變量，它把store操作從工作內(nèi)存中得到的變量的值放入主內(nèi)存的變量
事實(shí)上，對(duì)于 double 和 long 類(lèi)型的變量來(lái)說(shuō)，load、store、read 和 write 操作在某些平臺(tái)上允許有例外，稱(chēng)為 “l(fā)ong 和 double 的非原子性協(xié)定”，不過(guò)一般不需要我們特別注意，這里就不再過(guò)多贅述了。
這 8 種操作當(dāng)然不是可以隨便用的，為了保證 Java 程序中的內(nèi)存訪問(wèn)操作在并發(fā)下仍然是線程安全的，JMM 規(guī)定了在執(zhí)行上述 8 種基本操作時(shí)必須滿(mǎn)足的一系列規(guī)則。
這我就不一一列舉了，多提這么一嘴的原因就是下文會(huì)涉及一些這其中的規(guī)則，為了防止大家看的時(shí)候云里霧里，所以先前說(shuō)明白比較好。
上面我們舉了一個(gè)轉(zhuǎn)賬的例子，那么，在具體的代碼中，非原子性操作可能會(huì)導(dǎo)致什么問(wèn)題呢?
看下面這段代碼，各位不妨考慮一個(gè)的問(wèn)題，如果兩個(gè)線程對(duì)初始值為 0 的靜態(tài)變量一個(gè)做自增，一個(gè)做自減，各做 5000 次，結(jié)果一定是 0 嗎?
耳熟能詳?shù)膯?wèn)題，我們無(wú)法保證這段代碼執(zhí)行結(jié)果的一定性(正確性)，可能是正數(shù)、也可能是負(fù)數(shù)、當(dāng)然也可能是 0。
那么，我們就把這段代碼稱(chēng)為線程不安全的，就是說(shuō)在單線程環(huán)境下正常運(yùn)行的一段代碼，在多線程環(huán)境中可能發(fā)生各種意外情況，導(dǎo)致無(wú)法得到正確的結(jié)果。
從線程安全的角度來(lái)反向理解線程不安全的概念可能更容易點(diǎn)，這里參考《Java 并發(fā)編程實(shí)踐》上面的一句話：
一段代碼在被多個(gè)線程訪問(wèn)后，它仍然能夠進(jìn)行正確的行為，那這段代碼就是線程安全的。
至于這段代碼線程不安全的原因，就是 Java 中對(duì)靜態(tài)變量自增和自減操作并不是原子操作，它倆其實(shí)都包含三個(gè)離散的操作：
步驟 1：讀取當(dāng)前 i 的值
步驟 2：將 i 的值加 1(減 1)
步驟 3：寫(xiě)回新值
可以看出來(lái)這是一個(gè) 讀 - 改 - 寫(xiě) 的操作。
以 i ++ 操作為例，我們來(lái)看看它對(duì)應(yīng)的字節(jié)碼指令：
上方這段代碼對(duì)應(yīng)的字節(jié)碼是這樣的：
簡(jiǎn)單解釋下這些字節(jié)碼指令的含義：
getstatic i：獲取靜態(tài)變量 i 的值
iconst_1：準(zhǔn)備常量 1
iadd：自增(自減操作對(duì)應(yīng) isub)
putstatic i：將修改后的值存入靜態(tài)變量 i
如果是在單線程的環(huán)境下，先自增 5000 次，然后再自減 5000 次，那當(dāng)然不會(huì)發(fā)生任何問(wèn)題。
但是在多線程的環(huán)境下，由于 CPU 時(shí)間片調(diào)度的原因，可能 Thread1 正在執(zhí)行自增操作著呢，CPU 剝奪了它的資源占用，轉(zhuǎn)而分配給了 Thread2，也就是發(fā)生了線程上下文切換。這樣，就可能導(dǎo)致本該是一個(gè)連續(xù)的讀改寫(xiě)動(dòng)作(連續(xù)執(zhí)行的三個(gè)步驟)被打斷了。
下圖出現(xiàn)的就是結(jié)果最終是負(fù)數(shù)的情況：
總結(jié)來(lái)說(shuō)，如果多個(gè) CPU 同時(shí)對(duì)某個(gè)共享變量進(jìn)行讀-改-寫(xiě)操作，那么這個(gè)共享變量就會(huì)被多個(gè) CPU 同時(shí)處理，由于 CPU 時(shí)間片調(diào)度等原因，某個(gè)線程的讀-改-寫(xiě)操作可能會(huì)被其他線程打斷，導(dǎo)致操作完后共享變量的值和我們期望的不一致。
另外，多說(shuō)一嘴，除了自增自減，我們常見(jiàn)的 i = j 這個(gè)操作也是非原子性的，它分為兩個(gè)離散的步驟：
步驟 1：讀取 j 的值
步驟 2：將 j 的值賦給 i
那么，如何實(shí)現(xiàn)原子操作，也就是如何保證原子性呢?
對(duì)于這個(gè)問(wèn)題，其實(shí)在處理器和 Java 編程語(yǔ)言層面，它們都提供了一些有效的措施，比如處理器提供了總線鎖和緩存鎖，Java 提供了鎖和循環(huán) CAS 的方式，這里我們簡(jiǎn)單解釋下 Java 保證原子性的措施。
由 Java 內(nèi)存模型來(lái)直接保證的原子性變量操作包括 read、load、assign、use、store 和 write這 6 個(gè)，我們大致可以認(rèn)為，基本數(shù)據(jù)類(lèi)型的訪問(wèn)、讀寫(xiě)都是具備原子性的(例外就是 long 和 double 的非原子性協(xié)定，各位只要知道這件事情就可以了，無(wú)須太過(guò)在意這些幾乎不會(huì)發(fā)生的例外情況)。
如果應(yīng)用場(chǎng)景需要一個(gè)更大范圍的原子性保證，Java 內(nèi)存模型還提供了 lock 和 unlock 操作來(lái)滿(mǎn)足這種需求。
盡管 JVM 并沒(méi)有把 lock 和 unlock 操作直接開(kāi)放給用戶(hù)使用，但是卻提供了更高層次的字節(jié)碼指令 monitorenter 和 monitorexit 來(lái)隱式地使用這兩個(gè)操作。這兩個(gè)字節(jié)碼指令反映到 Java 代碼中就是同步塊 — synchronized 關(guān)鍵字，因此在 synchronized 塊之間的操作也具備原子性。
而除了 synchronized 關(guān)鍵字這種 Java 語(yǔ)言層面的鎖，juc 并發(fā)包中的 java.util.concurrent.locks.Lock 接口也提供了一些類(lèi)庫(kù)層面的鎖，比如 ReentrantLock。
另外，隨著硬件指令集的發(fā)展，在 JDK 5 之后，Java 類(lèi)庫(kù)中開(kāi)始使用基于 cmpxchg 指令的 CAS 操作(又來(lái)一個(gè)重點(diǎn))，該操作由 sun.misc.Unsafe 類(lèi)里面的 compareAndSwapInt() 和 compareAndSwapLong() 等幾個(gè)方法包裝提供。不過(guò)在 JDK 9 之前 Unsafe 類(lèi)是不開(kāi)放給用戶(hù)使用的，只有 Java 類(lèi)庫(kù)可以使用，譬如 juc 包里面的整數(shù)原子類(lèi)，其中的 compareAndSet() 和 getAndIncrement() 等方法都使用了 Unsafe 類(lèi)的 CAS 操作來(lái)實(shí)現(xiàn)。
使用這種 CAS 措施的代碼也常被稱(chēng)為無(wú)鎖編程(Lock-Free)。
什么是可見(jiàn)性
回到物理機(jī)，前文說(shuō)過(guò)，由于引入了高速緩存，不可避免的帶來(lái)了一個(gè)新的問(wèn)題：緩存一致性。而同樣的，這個(gè)問(wèn)題在 Java 虛擬機(jī)中同樣存在，表現(xiàn)為工作內(nèi)存與主內(nèi)存的同步延遲，也就是內(nèi)存可見(jiàn)性問(wèn)題。
何為可見(jiàn)性?就是指當(dāng)一個(gè)線程修改了共享變量的值時(shí)，其他線程能夠立即得知這個(gè)修改。
回顧下 Java 內(nèi)存模型：
從上圖來(lái)看，如果線程 A 與線程 B 之間要通信的話，必須要經(jīng)歷下面 2 個(gè)步驟：
1)線程 A 把工作內(nèi)存 A 中更新過(guò)的共享變量刷新到主內(nèi)存中去
2)線程 B 到主內(nèi)存中去讀取線程 A 之前已更新過(guò)的共享變量
也就是說(shuō)，線程 A 在向線程 B 的通信過(guò)程必須要經(jīng)過(guò)主內(nèi)存。
那么，這就可能出現(xiàn)一個(gè)問(wèn)題，舉個(gè)簡(jiǎn)單的例子，看下面這段代碼：
// 線程 1 執(zhí)行的代碼 int i = 0; i = 1; // 線程 2 執(zhí)行的代碼 j = i;
當(dāng)線程 1 執(zhí)行 i = 1 這句時(shí)，會(huì)先去主內(nèi)存中讀取 i 的初始值，然后加載到線程 1 的的工作內(nèi)存中，再賦值為1，至此，線程 1 的工作內(nèi)存當(dāng)中 i 的值變?yōu)?1 了，不過(guò)還沒(méi)有寫(xiě)入到主內(nèi)存當(dāng)中。
如果在線程 1 準(zhǔn)備把新的 i 值寫(xiě)回主內(nèi)存的時(shí)候，線程 2 執(zhí)行了 j = i 這條語(yǔ)句，它會(huì)去主存讀取 i 的值并加載到線程 2 的工作內(nèi)存當(dāng)中，而此時(shí)主內(nèi)存當(dāng)中 i 的值還是 0，那么就會(huì)使得 j 的值為 0，而不是 1。
這就是內(nèi)存可見(jiàn)性問(wèn)題，線程 1 修改了共享變量 i 的值，線程 2 并沒(méi)有立即得知這個(gè)修改。
各位可能脫口而出使用 volatile 關(guān)鍵字修飾共享變量，但除了這個(gè)，容易被大家忽略的是，其實(shí) sunchronized 和 final 這倆關(guān)鍵字也能保證可見(jiàn)性。
上面我提過(guò)一嘴，為了保證 Java 程序中的內(nèi)存訪問(wèn)操作在并發(fā)下仍然是線程安全的，JMM 規(guī)定了在執(zhí)行 8 種基本原子操作時(shí)必須滿(mǎn)足的一系列規(guī)則，這其中有一條規(guī)則正是 sychronized 能夠保證原子性的理論支撐，如下：
對(duì)一個(gè)變量執(zhí)行 unlock 操作之前，必須先把此變量同步回主內(nèi)存中(執(zhí)行 store、write 操作)
也就是說(shuō) synchronized在修改了工作內(nèi)存中的變量后，解鎖前會(huì)將工作內(nèi)存修改的內(nèi)容刷新到主內(nèi)存中，確保了共享變量的值是最新的，也就保證了可見(jiàn)性。
至于 final 關(guān)鍵字的可見(jiàn)性需要結(jié)合其內(nèi)存語(yǔ)義深入來(lái)講，這里就先簡(jiǎn)單的概括下：被 final 修飾的字段在構(gòu)造器中一旦被初始化完成，并且構(gòu)造器沒(méi)有把 this 的引用傳遞出去，那么在其他線程中就能看見(jiàn) final 字段的值。
什么是有序性
OK，說(shuō)完了可見(jiàn)性，我們?cè)倩氐轿锢頇C(jī)，其實(shí)除了增加高速緩存之外，為了使 CPU 內(nèi)部的運(yùn)算單元能盡量被充分利用，CPU 可能會(huì)對(duì)輸入代碼進(jìn)行亂序執(zhí)行優(yōu)化，CPU 會(huì)在計(jì)算之后將亂序執(zhí)行的結(jié)果重組，保證該結(jié)果與順序執(zhí)行的結(jié)果是一致的，但并不保證程序中各個(gè)語(yǔ)句計(jì)算的先后順序與輸入代碼中的順序一致，因此如果存在一個(gè)計(jì)算任務(wù)依賴(lài)另外一個(gè)計(jì)算任務(wù)的中間結(jié)果，那么其順序性并不能靠代碼的先后順序來(lái)保證。
與之類(lèi)似的，Java 的編譯器也有這樣的一種優(yōu)化手段：指令重排序(Instruction Reorder)。
那么，既然能夠優(yōu)化性能，重排序可以沒(méi)有限制的被使用嗎?
當(dāng)然不，在重排序的時(shí)候，CPU 和編譯器都需要遵守一個(gè)規(guī)矩，這個(gè)規(guī)矩就是 as-if-serial 語(yǔ)義：不管怎么重排序，單線程環(huán)境下程序的執(zhí)行結(jié)果不能被改變。
為了遵守 as-if-serial 語(yǔ)義，CPU 和編譯器不會(huì)對(duì)存在數(shù)據(jù)依賴(lài)關(guān)系的操作做重排序，因?yàn)檫@種重排序會(huì)改變執(zhí)行結(jié)果。
那么這里，我們又引出了 “數(shù)據(jù)依賴(lài)性” 的概念。
如果兩個(gè)操作訪問(wèn)同一個(gè)變量，且這兩個(gè)操作中有一個(gè)為寫(xiě)操作，此時(shí)這兩個(gè)操作之間就存在數(shù)據(jù)依賴(lài)性。
數(shù)據(jù)依賴(lài)性分為三種類(lèi)型：寫(xiě)后讀、寫(xiě)后寫(xiě)、讀后寫(xiě)，看下圖
上面 3 種情況，只要重排序兩個(gè)操作的執(zhí)行順序，程序的執(zhí)行結(jié)果就會(huì)被改變。
其實(shí)考慮數(shù)據(jù)依賴(lài)關(guān)系的時(shí)候，各位可以通過(guò)畫(huà)圖來(lái)直觀的判斷。舉個(gè)例子：
int a = 1; // A int b = 2; // B int sum = a + b; // C
上面 3 個(gè)操作的數(shù)據(jù)依賴(lài)關(guān)系如下圖所示：
可以看出，A 和 C、B 和 C 之間存在數(shù)據(jù)依賴(lài)關(guān)系，因此在最終執(zhí)行的指令序列中，C 不能被重排序到 A 或B 的前面。但 A 和 B 之間沒(méi)有數(shù)據(jù)依賴(lài)關(guān)系，所以 CPU 和處理器可以重排序 A 和 B 之間的執(zhí)行順序。如下是程序的兩種執(zhí)行順序：
看起來(lái)好像沒(méi)啥問(wèn)題，重排序之后程序的結(jié)果并沒(méi)有發(fā)生改變，還提升了性能。
然而，很不幸的是，我們這里所說(shuō)的數(shù)據(jù)依賴(lài)性?xún)H針對(duì)單個(gè) CPU 中執(zhí)行的指令序列和單個(gè)線程中執(zhí)行的操作，不同 CPU 之間和不同線程之間的數(shù)據(jù)依賴(lài)性是不被 CPU 和編譯器考慮的。
這就是為啥我在寫(xiě) as-if-serial 語(yǔ)義的時(shí)候把 “單線程” 加粗的目的了。
看下面這段代碼：
假設(shè)有兩個(gè)線程 A 和 B，A 首先執(zhí)行 writer() 方法，隨后 B 線程接著執(zhí)行 reader() 方法。線程 B 在執(zhí)行操作 4 時(shí)，能否看到線程 A 在操作 1 把共享變量 a 修改成了 1 呢?
答案是不一定。
由于操作 1 和操作 2 沒(méi)有數(shù)據(jù)依賴(lài)關(guān)系，CPU 和編譯器可以對(duì)這兩個(gè)操作重排序;同樣的，操作 3 和操作 4 沒(méi)有數(shù)據(jù)依賴(lài)關(guān)系，編譯器和處理器也可以對(duì)這兩個(gè)操作重排序。
以操作 1 和操作 2 重排序?yàn)槔?，可能?huì)產(chǎn)生什么效果呢?
如上圖右邊所示，程序執(zhí)行時(shí)，線程 A 首先寫(xiě)標(biāo)記變量 flag，隨后線程 B 讀這個(gè)變量。由于條件判斷為真，線程 B 將讀取變量 a。此時(shí)，變量 a 還沒(méi)有被線程 A 寫(xiě)入，因此線程 B 讀到的 a 值仍然是 0。也就是說(shuō)在這里多線程程序的語(yǔ)義被重排序破壞了。
這樣，我們可以得出結(jié)論：CPU 和 Java 編譯器為了優(yōu)化程序性能，會(huì)自發(fā)地對(duì)指令序列進(jìn)行重新排序。在多線程的環(huán)境下，由于重排序的存在，就可能導(dǎo)致程序運(yùn)行結(jié)果出現(xiàn)錯(cuò)誤。
了解了重排序的概念，我們可以這樣總結(jié)下 Java 程序天然的有序性：
如果在本線程內(nèi)觀察，所有的操作都是有序的(簡(jiǎn)單來(lái)說(shuō)就是線程內(nèi)表現(xiàn)為串行)
如果在一個(gè)線程中觀察另一個(gè)線程，所有的操作都是無(wú)序的(這個(gè)無(wú)序主要就是指 “指令重排序” 現(xiàn)象和 “工作內(nèi)存與主內(nèi)存同步延遲” 現(xiàn)象)
Java 語(yǔ)言提供了 volatile 和 synchronized 兩個(gè)關(guān)鍵字來(lái)保證線程之間操作的有序性。
volatile 本身除了保證可見(jiàn)性的語(yǔ)義外，還包含了禁止指令重排序的語(yǔ)義，所以天生就具有保證有序性的功能。
而 synchronized 保證有序性的理論支撐，仍然是 JMM 規(guī)定在執(zhí)行 8 種基本原子操作時(shí)必須滿(mǎn)足的一系列規(guī)則中的某一個(gè)提供的：
一個(gè)變量在同一個(gè)時(shí)刻只允許一條線程對(duì)其進(jìn)行 lock 操作
這個(gè)規(guī)則決定了持有同一個(gè)鎖的兩個(gè) synchronized 同步塊只能串行地進(jìn)入。
不是很難理解吧，通俗來(lái)說(shuō)，synchronized 通過(guò)排他鎖的方式保證了同一時(shí)間內(nèi)，被 synchronized 修飾的代碼是單線程執(zhí)行的。所以，這就滿(mǎn)足了 as-if-serial 語(yǔ)義的一個(gè)關(guān)鍵前提，那就是單線程，這樣，有了 as-if-serial 語(yǔ)義的保證，單線程的有序性也就得到保障了。
Happens-before 是 JMM 的靈魂，它是判斷數(shù)據(jù)是否存在競(jìng)爭(zhēng)，線程是否安全的非常有用的手段。為了知識(shí)體系的完整性，這里簡(jiǎn)單提一下，后續(xù)文章會(huì)詳細(xì)解釋的。
如果 Java 內(nèi)存模型中所有的有序性都僅靠 volatile 和 synchronized 來(lái)完成，那么有很多操作都將會(huì)變得非常啰嗦，但是我們?cè)诰帉?xiě) Java 并發(fā)代碼的時(shí)候并沒(méi)有察覺(jué)到這一點(diǎn)，這就歸功于 “先行發(fā)生”(Happens-Before)原則。
依賴(lài)這個(gè)原則，我們可以通過(guò)幾條簡(jiǎn)單規(guī)則快速解決并發(fā)環(huán)境下兩個(gè)操作之間是否可能存在沖突的所有問(wèn)題，而不需要陷入 Java 內(nèi)存模型苦澀難懂的定義之中。
到此，關(guān)于“Java內(nèi)存模型與原子性、可見(jiàn)性、有序性分別是什么”的學(xué)習(xí)就結(jié)束了，希望能夠解決大家的疑惑。理論與實(shí)踐的搭配能更好的幫助大家學(xué)習(xí)，快去試試吧！若想繼續(xù)學(xué)習(xí)更多相關(guān)知識(shí)，請(qǐng)繼續(xù)關(guān)注創(chuàng)新互聯(lián)網(wǎng)站，小編會(huì)繼續(xù)努力為大家?guī)?lái)更多實(shí)用的文章！
重慶分公司
重慶分公司
