理解Java內(nèi)存區(qū)域與Java內(nèi)存模型
Java內(nèi)存區(qū)域
Java虛擬機在運行程序時會把其自動管理的內(nèi)存劃分為以上幾個區(qū)域，每個區(qū)域都有的用途以及創(chuàng)建銷毀的時機门粪，其中藍色部分代表的是所有線程共享的數(shù)據(jù)區(qū)域盐类，而綠色部分代表的是每個線程的私有數(shù)據(jù)區(qū)域。
方法區(qū)（Method Area）：
方法區(qū)屬于線程共享的內(nèi)存區(qū)域，又稱Non-Heap（非堆）嘉涌，主要用于存儲已被虛擬機加載的類信息惊暴、常量饼丘、靜態(tài)變量、即時編譯器編譯后的代碼等數(shù)據(jù)辽话，根據(jù)Java 虛擬機規(guī)范的規(guī)定肄鸽，當(dāng)方法區(qū)無法滿足內(nèi)存分配需求時，將拋出OutOfMemoryError 異常油啤。值得注意的是在方法區(qū)中存在一個叫運行時常量池(Runtime Constant Pool）的區(qū)域典徘，它主要用于存放編譯器生成的各種字面量和符號引用，這些內(nèi)容將在類加載后存放到運行時常量池中益咬，以便后續(xù)使用逮诲。
JVM堆（Java Heap）：
Java 堆也是屬于線程共享的內(nèi)存區(qū)域，它在虛擬機啟動時創(chuàng)建幽告，是Java 虛擬機所管理的內(nèi)存中最大的一塊梅鹦，主要用于存放對象實例，幾乎所有的對象實例都在這里分配內(nèi)存冗锁，注意Java 堆是垃圾收集器管理的主要區(qū)域齐唆，因此很多時候也被稱做GC 堆，如果在堆中沒有內(nèi)存完成實例分配冻河，并且堆也無法再擴展時箍邮，將會拋出OutOfMemoryError 異常茉帅。
程序計數(shù)器(Program Counter Register)：
屬于線程私有的數(shù)據(jù)區(qū)域，是一小塊內(nèi)存空間媒殉，主要代表當(dāng)前線程所執(zhí)行的字節(jié)碼行號指示器担敌。字節(jié)碼解釋器工作時，通過改變這個計數(shù)器的值來選取下一條需要執(zhí)行的字節(jié)碼指令廷蓉，分支全封、循環(huán)、跳轉(zhuǎn)桃犬、異常處理刹悴、線程恢復(fù)等基礎(chǔ)功能都需要依賴這個計數(shù)器來完成。
虛擬機棧(Java Virtual Machine Stacks)：
屬于線程私有的數(shù)據(jù)區(qū)域攒暇，與線程同時創(chuàng)建土匀，總數(shù)與線程關(guān)聯(lián)，代表Java方法執(zhí)行的內(nèi)存模型形用。每個方法執(zhí)行時都會創(chuàng)建一個棧楨來存儲方法的的變量表就轧、操作數(shù)棧、動態(tài)鏈接方法田度、返回值妒御、返回地址等信息。每個方法從調(diào)用直結(jié)束就對于一個棧楨在虛擬機棧中的入棧和出棧過程镇饺，如下（圖有誤乎莉，應(yīng)該為棧楨）：
本地方法棧(Native Method Stacks)：
本地方法棧屬于線程私有的數(shù)據(jù)區(qū)域，這部分主要與虛擬機用到的 Native 方法相關(guān)奸笤，一般情況下惋啃，我們無需關(guān)心此區(qū)域。
這里之所以簡要說明這部分內(nèi)容监右，注意是為了區(qū)別Java內(nèi)存模型與Java內(nèi)存區(qū)域的劃分边灭，畢竟這兩種劃分是屬于不同層次的概念。
Java內(nèi)存模型概述
Java內(nèi)存模型(即Java Memory Model健盒，簡稱JMM)本身是一種抽象的概念存筏，并不真實存在，它描述的是一組規(guī)則或規(guī)范味榛，通過這組規(guī)范定義了程序中各個變量（包括實例字段椭坚，靜態(tài)字段和構(gòu)成數(shù)組對象的元素）的訪問方式。由于JVM運行程序的實體是線程搏色，而每個線程創(chuàng)建時JVM都會為其創(chuàng)建一個工作內(nèi)存(有些地方稱為椛凭ィ空間)，用于存儲線程私有的數(shù)據(jù)频轿，而Java內(nèi)存模型中規(guī)定所有變量都存儲在主內(nèi)存垂涯，主內(nèi)存是共享內(nèi)存區(qū)域烁焙，所有線程都可以訪問，但線程對變量的操作(讀取賦值等)必須在工作內(nèi)存中進行耕赘，首先要將變量從主內(nèi)存拷貝的自己的工作內(nèi)存空間骄蝇，然后對變量進行操作，操作完成后再將變量寫回主內(nèi)存操骡，不能直接操作主內(nèi)存中的變量九火，工作內(nèi)存中存儲著主內(nèi)存中的變量副本拷貝，前面說過册招，工作內(nèi)存是每個線程的私有數(shù)據(jù)區(qū)域岔激，因此不同的線程間無法訪問對方的工作內(nèi)存，線程間的通信(傳值)必須通過主內(nèi)存來完成是掰，其簡要訪問過程如下圖
需要注意的是虑鼎，JMM與Java內(nèi)存區(qū)域的劃分是不同的概念層次，更恰當(dāng)說JMM描述的是一組規(guī)則键痛，通過這組規(guī)則控制程序中各個變量在共享數(shù)據(jù)區(qū)域和私有數(shù)據(jù)區(qū)域的訪問方式炫彩，JMM是圍繞原子性，有序性絮短、可見性展開的(稍后會分析)媒楼。JMM與Java內(nèi)存區(qū)域唯一相似點，都存在共享數(shù)據(jù)區(qū)域和私有數(shù)據(jù)區(qū)域戚丸，在JMM中主內(nèi)存屬于共享數(shù)據(jù)區(qū)域，從某個程度上講應(yīng)該包括了堆和方法區(qū)扔嵌，而工作內(nèi)存數(shù)據(jù)線程私有數(shù)據(jù)區(qū)域限府，從某個程度上講則應(yīng)該包括程序計數(shù)器、虛擬機棧以及本地方法棧痢缎⌒采祝或許在某些地方，我們可能會看見主內(nèi)存被描述為堆內(nèi)存独旷，工作內(nèi)存被稱為線程棧署穗，實際上他們表達的都是同一個含義。關(guān)于JMM中的主內(nèi)存和工作內(nèi)存說明如下
主內(nèi)存
主要存儲的是Java實例對象嵌洼，所有線程創(chuàng)建的實例對象都存放在主內(nèi)存中案疲，不管該實例對象是成員變量還是方法中的本地變量(也稱局部變量)，當(dāng)然也包括了共享的類信息麻养、常量褐啡、靜態(tài)變量。由于是共享數(shù)據(jù)區(qū)域鳖昌，多條線程對同一個變量進行訪問可能會發(fā)現(xiàn)線程安全問題备畦。
工作內(nèi)存
主要存儲當(dāng)前方法的所有本地變量信息(工作內(nèi)存中存儲著主內(nèi)存中的變量副本拷貝)低飒，每個線程只能訪問自己的工作內(nèi)存，即線程中的本地變量對其它線程是不可見的懂盐，就算是兩個線程執(zhí)行的是同一段代碼褥赊，它們也會各自在自己的工作內(nèi)存中創(chuàng)建屬于當(dāng)前線程的本地變量，當(dāng)然也包括了字節(jié)碼行號指示器莉恼、相關(guān)Native方法的信息拌喉。注意由于工作內(nèi)存是每個線程的私有數(shù)據(jù)类垫，線程間無法相互訪問工作內(nèi)存司光，因此存儲在工作內(nèi)存的數(shù)據(jù)不存在線程安全問題。
弄清楚主內(nèi)存和工作內(nèi)存后悉患，接了解一下主內(nèi)存與工作內(nèi)存的數(shù)據(jù)存儲類型以及操作方式残家，根據(jù)虛擬機規(guī)范，對于一個實例對象中的成員方法而言售躁，如果方法中包含本地變量是基本數(shù)據(jù)類型（boolean,byte,short,char,int,long,float,double）坞淮，將直接存儲在工作內(nèi)存的幀棧結(jié)構(gòu)中，但倘若本地變量是引用類型陪捷，那么該變量的引用會存儲在功能內(nèi)存的幀棧中回窘，而對象實例將存儲在主內(nèi)存(共享數(shù)據(jù)區(qū)域，堆)中市袖。但對于實例對象的成員變量啡直，不管它是基本數(shù)據(jù)類型或者包裝類型(Integer、Double等)還是引用類型苍碟，都會被存儲到堆區(qū)酒觅。至于static變量以及類本身相關(guān)信息將會存儲在主內(nèi)存中。需要注意的是微峰，在主內(nèi)存中的實例對象可以被多線程共享舷丹，倘若兩個線程同時調(diào)用了同一個對象的同一個方法，那么兩條線程會將要操作的數(shù)據(jù)拷貝一份到自己的工作內(nèi)存中蜓肆，執(zhí)行完成操作后才刷新到主內(nèi)存颜凯，簡單示意圖如下所示：
硬件內(nèi)存架構(gòu)與Java內(nèi)存模型
硬件內(nèi)存架構(gòu)
正如上圖所示，經(jīng)過簡化CPU與內(nèi)存操作的簡易圖仗扬，實際上沒有這么簡單症概，這里為了理解方便，我們省去了南北橋并將三級緩存統(tǒng)一為CPU緩存(有些CPU只有二級緩存早芭，有些CPU有三級緩存)穴豫。就目前計算機而言，一般擁有多個CPU并且每個CPU可能存在多個核心，多核是指在一枚處理器(CPU)中集成兩個或多個完整的計算引擎(內(nèi)核),這樣就可以支持多任務(wù)并行執(zhí)行精肃，從多線程的調(diào)度來說秤涩，每個線程都會映射到各個CPU核心中并行運行。在CPU內(nèi)部有一組CPU寄存器司抱，寄存器是cpu直接訪問和處理的數(shù)據(jù)筐眷，是一個臨時放數(shù)據(jù)的空間。一般CPU都會從內(nèi)存取數(shù)據(jù)到寄存器习柠，然后進行處理匀谣，但由于內(nèi)存的處理速度遠遠低于CPU，導(dǎo)致CPU在處理指令時往往花費很多時間在等待內(nèi)存做準(zhǔn)備工作资溃，于是在寄存器和主內(nèi)存間添加了CPU緩存武翎，CPU緩存比較小，但訪問速度比主內(nèi)存快得多溶锭，如果CPU總是操作主內(nèi)存中的同一址地的數(shù)據(jù)宝恶，很容易影響CPU執(zhí)行速度，此時CPU緩存就可以把從內(nèi)存提取的數(shù)據(jù)暫時保存起來趴捅，如果寄存器要取內(nèi)存中同一位置的數(shù)據(jù)垫毙，直接從緩存中提取，無需直接從主內(nèi)存取拱绑。需要注意的是综芥，寄存器并不每次數(shù)據(jù)都可以從緩存中取得數(shù)據(jù)，萬一不是同一個內(nèi)存地址中的數(shù)據(jù)猎拨，那寄存器還必須直接繞過緩存從內(nèi)存中取數(shù)據(jù)膀藐。所以并不每次都得到緩存中取數(shù)據(jù)，這種現(xiàn)象有個專業(yè)的名稱叫做緩存的命中率红省，從緩存中取就命中额各，不從緩存中取從內(nèi)存中取，就沒命中类腮，可見緩存命中率的高低也會影響CPU執(zhí)行性能，這就是CPU蛉加、緩存以及主內(nèi)存間的簡要交互過程蚜枢，總而言之當(dāng)一個CPU需要訪問主存時，會先讀取一部分主存數(shù)據(jù)到CPU緩存(當(dāng)然如果CPU緩存中存在需要的數(shù)據(jù)就會直接從緩存獲取)针饥，進而在讀取CPU緩存到寄存器厂抽，當(dāng)CPU需要寫數(shù)據(jù)到主存時，同樣會先刷新寄存器中的數(shù)據(jù)到CPU緩存丁眼，然后再把數(shù)據(jù)刷新到主內(nèi)存中筷凤。
Java線程與硬件處理器
了解完硬件的內(nèi)存架構(gòu)后，接著了解JVM中線程的實現(xiàn)原理，理解線程的實現(xiàn)原理藐守，有助于我們了解Java內(nèi)存模型與硬件內(nèi)存架構(gòu)的關(guān)系挪丢，在Window系統(tǒng)和Linux系統(tǒng)上，Java線程的實現(xiàn)是基于一對一的線程模型卢厂，所謂的一對一模型乾蓬，實際上就是通過語言級別層面程序去間接調(diào)用系統(tǒng)內(nèi)核的線程模型，即我們在使用Java線程時慎恒，Java虛擬機內(nèi)部是轉(zhuǎn)而調(diào)用當(dāng)前操作系統(tǒng)的內(nèi)核線程來完成當(dāng)前任務(wù)任内。這里需要了解一個術(shù)語，內(nèi)核線程(Kernel-Level Thread融柬，KLT)死嗦，它是由操作系統(tǒng)內(nèi)核(Kernel)支持的線程，這種線程是由操作系統(tǒng)內(nèi)核來完成線程切換粒氧，內(nèi)核通過操作調(diào)度器進而對線程執(zhí)行調(diào)度越除，并將線程的任務(wù)映射到各個處理器上。每個內(nèi)核線程可以視為內(nèi)核的一個分身,這也就是操作系統(tǒng)可以同時處理多任務(wù)的原因靠欢。由于我們編寫的多線程程序?qū)儆谡Z言層面的廊敌，程序一般不會直接去調(diào)用內(nèi)核線程，取而代之的是一種輕量級的進程(Light Weight Process)门怪，也是通常意義上的線程骡澈，由于每個輕量級進程都會映射到一個內(nèi)核線程，因此我們可以通過輕量級進程調(diào)用內(nèi)核線程掷空，進而由操作系統(tǒng)內(nèi)核將任務(wù)映射到各個處理器肋殴，這種輕量級進程與內(nèi)核線程間1對1的關(guān)系就稱為一對一的線程模型。如下圖
如圖所示坦弟，每個線程最終都會映射到CPU中進行處理护锤，如果CPU存在多核，那么一個CPU將可以并行執(zhí)行多個線程任務(wù)酿傍。
Java內(nèi)存模型與硬件內(nèi)存架構(gòu)的關(guān)系
通過對前面的硬件內(nèi)存架構(gòu)烙懦、Java內(nèi)存模型以及Java多線程的實現(xiàn)原理的了解，我們應(yīng)該已經(jīng)意識到赤炒，多線程的執(zhí)行最終都會映射到硬件處理器上進行執(zhí)行氯析，但Java內(nèi)存模型和硬件內(nèi)存架構(gòu)并不完全一致。對于硬件內(nèi)存來說只有寄存器莺褒、緩存內(nèi)存掩缓、主內(nèi)存的概念，并沒有工作內(nèi)存(線程私有數(shù)據(jù)區(qū)域)和主內(nèi)存(堆內(nèi)存)之分遵岩，也就是說Java內(nèi)存模型對內(nèi)存的劃分對硬件內(nèi)存并沒有任何影響你辣，因為JMM只是一種抽象的概念，是一組規(guī)則，并不實際存在，不管是工作內(nèi)存的數(shù)據(jù)還是主內(nèi)存的數(shù)據(jù)，對于計算機硬件來說都會存儲在計算機主內(nèi)存中甜害，當(dāng)然也有可能存儲到CPU緩存或者寄存器中窍荧，因此總體上來說，Java內(nèi)存模型和計算機硬件內(nèi)存架構(gòu)是一個相互交叉的關(guān)系，是一種抽象概念劃分與真實物理硬件的交叉。(注意對于Java內(nèi)存區(qū)域劃分也是同樣的道理)
JMM存在的必要性
在明白了Java內(nèi)存區(qū)域劃分、硬件內(nèi)存架構(gòu)叉讥、Java多線程的實現(xiàn)原理與Java內(nèi)存模型的具體關(guān)系后，接著來談?wù)凧ava內(nèi)存模型存在的必要性饥追。由于JVM運行程序的實體是線程图仓，而每個線程創(chuàng)建時JVM都會為其創(chuàng)建一個工作內(nèi)存(有些地方稱為棧空間)但绕，用于存儲線程私有的數(shù)據(jù)救崔，線程與主內(nèi)存中的變量操作必須通過工作內(nèi)存間接完成，主要過程是將變量從主內(nèi)存拷貝的每個線程各自的工作內(nèi)存空間捏顺，然后對變量進行操作六孵，操作完成后再將變量寫回主內(nèi)存，如果存在兩個線程同時對一個主內(nèi)存中的實例對象的變量進行操作就有可能誘發(fā)線程安全問題幅骄。如下圖劫窒，主內(nèi)存中存在一個共享變量x，現(xiàn)在有A和B兩條線程分別對該變量x=1進行操作拆座，A/B線程各自的工作內(nèi)存中存在共享變量副本x主巍。假設(shè)現(xiàn)在A線程想要修改x的值為2，而B線程卻想要讀取x的值挪凑，那么B線程讀取到的值是A線程更新后的值2還是更新前的值1呢孕索？答案是，不確定躏碳，即B線程有可能讀取到A線程更新前的值1搞旭，也有可能讀取到A線程更新后的值2，這是因為工作內(nèi)存是每個線程私有的數(shù)據(jù)區(qū)域菇绵，而線程A變量x時肄渗，首先是將變量從主內(nèi)存拷貝到A線程的工作內(nèi)存中，然后對變量進行操作脸甘，操作完成后再將變量x寫回主內(nèi)恳啥，而對于B線程的也是類似的偏灿，這樣就有可能造成主內(nèi)存與工作內(nèi)存間數(shù)據(jù)存在一致性問題丹诀，假如A線程修改完后正在將數(shù)據(jù)寫回主內(nèi)存，而B線程此時正在讀取主內(nèi)存，即將x=1拷貝到自己的工作內(nèi)存中铆遭，這樣B線程讀取到的值就是x=1硝桩，但如果A線程已將x=2寫回主內(nèi)存后，B線程才開始讀取的話枚荣，那么此時B線程讀取到的就是x=2碗脊，但到底是哪種情況先發(fā)生呢？這是不確定的橄妆，這也就是所謂的線程安全問題衙伶。
為了解決類似上述的問題，JVM定義了一組規(guī)則害碾，通過這組規(guī)則來決定一個線程對共享變量的寫入何時對另一個線程可見矢劲，這組規(guī)則也稱為Java內(nèi)存模型（即JMM），JMM是圍繞著程序執(zhí)行的原子性慌随、有序性芬沉、可見性展開的，下面我們看看這三個特性阁猜。
Java內(nèi)存模型的承諾
這里我們先來了解幾個概念丸逸，即原子性？可見性剃袍？有序性黄刚？最后再闡明JMM是如何保證這3個特性。
原子性
原子性指的是一個操作是不可中斷的笛园，即使是在多線程環(huán)境下隘击，一個操作一旦開始就不會被其他線程影響。比如對于一個靜態(tài)變量int x研铆，兩條線程同時對他賦值埋同，線程A賦值為1，而線程B賦值為2棵红，不管線程如何運行凶赁，最終x的值要么是1，要么是2逆甜，線程A和線程B間的操作是沒有干擾的虱肄，這就是原子性操作，不可被中斷的特點交煞。有點要注意的是咏窿，對于32位系統(tǒng)的來說，long類型數(shù)據(jù)和double類型數(shù)據(jù)(對于基本數(shù)據(jù)類型素征，byte,short,int,float,boolean,char讀寫是原子操作)集嵌，它們的讀寫并非原子性的萝挤，也就是說如果存在兩條線程同時對long類型或者double類型的數(shù)據(jù)進行讀寫是存在相互干擾的，因為對于32位虛擬機來說根欧，每次原子讀寫是32位的怜珍，而long和double則是64位的存儲單元，這樣會導(dǎo)致一個線程在寫時凤粗，操作完前32位的原子操作后酥泛，輪到B線程讀取時，恰好只讀取到了后32位的數(shù)據(jù)嫌拣，這樣可能會讀取到一個既非原值又不是線程修改值的變量柔袁，它可能是“半個變量”的數(shù)值，即64位數(shù)據(jù)被兩個線程分成了兩次讀取异逐。但也不必太擔(dān)心瘦馍，因為讀取到“半個變量”的情況比較少見，至少在目前的商用的虛擬機中应役，幾乎都把64位的數(shù)據(jù)的讀寫操作作為原子操作來執(zhí)行情组，因此對于這個問題不必太在意，知道這么回事即可箩祥。
理解指令重排
計算機在執(zhí)行程序時院崇，為了提高性能，編譯器和處理器的常常會對指令做重排袍祖，一般分以下3種
編譯器優(yōu)化的重排
編譯器在不改變單線程程序語義的前提下底瓣，可以重新安排語句的執(zhí)行順序。
指令并行的重排
現(xiàn)代處理器采用了指令級并行技術(shù)來將多條指令重疊執(zhí)行蕉陋。如果不存在數(shù)據(jù)依賴性(即后一個執(zhí)行的語句無需依賴前面執(zhí)行的語句的結(jié)果)捐凭，處理器可以改變語句對應(yīng)的機器指令的執(zhí)行順序
內(nèi)存系統(tǒng)的重排
由于處理器使用緩存和讀寫緩存沖區(qū)，這使得加載(load)和存儲(store)操作看上去可能是在亂序執(zhí)行凳鬓，因為三級緩存的存在茁肠，導(dǎo)致內(nèi)存與緩存的數(shù)據(jù)同步存在時間差。
其中編譯器優(yōu)化的重排屬于編譯期重排缩举，指令并行的重排和內(nèi)存系統(tǒng)的重排屬于處理器重排垦梆，在多線程環(huán)境中，這些重排優(yōu)化可能會導(dǎo)致程序出現(xiàn)內(nèi)存可見性問題仅孩，下面分別闡明這兩種重排優(yōu)化可能帶來的問題
編譯器重排
下面我們簡單看一個編譯器重排的例子：
線程 1? ? ? ? ? ? 線程 2
1： x2 = a ;? ? ? 3: x1 = b ;
2: b = 1;? ? ? ? 4: a = 2 ;
1
2
3
兩個線程同時執(zhí)行托猩，分別有1、2辽慕、3京腥、4四段執(zhí)行代碼，其中1溅蛉、2屬于線程1 公浪， 3摆尝、4屬于線程2 ，從程序的執(zhí)行順序上看因悲，似乎不太可能出現(xiàn)x1 = 1 和x2 = 2 的情況，但實際上這種情況是有可能發(fā)現(xiàn)的勺爱，因為如果編譯器對這段程序代碼執(zhí)行重排優(yōu)化后晃琳，可能出現(xiàn)下列情況
線程 1? ? ? ? ? ? ? 線程 2
2: b = 1;? ? ? ? ? 4: a = 2 ;
1：x2 = a ;? ? ? ? 3: x1 = b ;
1
2
3
這種執(zhí)行順序下就有可能出現(xiàn)x1 = 1 和x2 = 2 的情況，這也就說明在多線程環(huán)境下琐鲁，由于編譯器優(yōu)化重排的存在卫旱，兩個線程中使用的變量能否保證一致性是無法確定的。
處理器指令重排
先了解一下指令重排的概念围段，處理器指令重排是對CPU的性能優(yōu)化顾翼，從指令的執(zhí)行角度來說一條指令可以分為多個步驟完成，如下
取指 IF
譯碼和取寄存器操作數(shù) ID
執(zhí)行或者有效地址計算 EX
存儲器訪問 MEM
寫回 WB
CPU在工作時奈泪，需要將上述指令分為多個步驟依次執(zhí)行(注意硬件不同有可能不一樣),由于每一個步會使用到不同的硬件操作适贸，比如取指時會只有PC寄存器和存儲器，譯碼時會執(zhí)行到指令寄存器組涝桅，執(zhí)行時會執(zhí)行ALU(算術(shù)邏輯單元)拜姿、寫回時使用到寄存器組。為了提高硬件利用率冯遂，CPU指令是按流水線技術(shù)來執(zhí)行的蕊肥，如下：
從圖中可以看出當(dāng)指令1還未執(zhí)行完成時，第2條指令便利用空閑的硬件開始執(zhí)行蛤肌，這樣做是有好處的壁却，如果每個步驟花費1ms，那么如果第2條指令需要等待第1條指令執(zhí)行完成后再執(zhí)行的話裸准，則需要等待5ms展东，但如果使用流水線技術(shù)的話，指令2只需等待1ms就可以開始執(zhí)行了炒俱，這樣就能大大提升CPU的執(zhí)行性能琅锻。雖然流水線技術(shù)可以大大提升CPU的性能，但不幸的是一旦出現(xiàn)流水中斷向胡，所有硬件設(shè)備將會進入一輪停頓期恼蓬，當(dāng)再次彌補中斷點可能需要幾個周期，這樣性能損失也會很大僵芹，就好比工廠組裝手機的流水線处硬，一旦某個零件組裝中斷，那么該零件往后的工人都有可能進入一輪或者幾輪等待組裝零件的過程拇派。因此我們需要盡量阻止指令中斷的情況荷辕，指令重排就是其中一種優(yōu)化中斷的手段凿跳，我們通過一個例子來闡明指令重排是如何阻止流水線技術(shù)中斷的
a = b + c ;
d = e + f ;
1
2
下面通過匯編指令展示了上述代碼在CPU執(zhí)行的處理過程
LW指令 表示 load，其中LW R1,b表示把b的值加載到寄存器R1中
LW R2,c 表示把c的值加載到寄存器R2中
ADD 指令表示加法疮方，把R1 控嗜、R2的值相加，并存入R3寄存器中骡显。
SW 表示 store 即將 R3寄存器的值保持到變量a中
LW R4,e 表示把e的值加載到寄存器R4中
LW R5,f 表示把f的值加載到寄存器R5中
SUB 指令表示減法疆栏，把R4 、R5的值相減惫谤，并存入R6寄存器中壁顶。
SW d,R6 表示將R6寄存器的值保持到變量d中
上述便是匯編指令的執(zhí)行過程，在某些指令上存在X的標(biāo)志溜歪，X代表中斷的含義若专，也就是只要有X的地方就會導(dǎo)致指令流水線技術(shù)停頓，同時也會影響后續(xù)指令的執(zhí)行蝴猪，可能需要經(jīng)過1個或幾個指令周期才可能恢復(fù)正常调衰，那為什么停頓呢？這是因為部分?jǐn)?shù)據(jù)還沒準(zhǔn)備好自阱，如執(zhí)行ADD指令時窖式，需要使用到前面指令的數(shù)據(jù)R1，R2动壤，而此時R2的MEM操作沒有完成萝喘，即未拷貝到存儲器中，這樣加法計算就無法進行琼懊，必須等到MEM操作完成后才能執(zhí)行阁簸，也就因此而停頓了，其他指令也是類似的情況哼丈。前面闡述過启妹，停頓會造成CPU性能下降，因此我們應(yīng)該想辦法消除這些停頓醉旦，這時就需要使用到指令重排了饶米，如下圖，既然ADD指令需要等待车胡，那我們就利用等待的時間做些別的事情檬输，如把LW R4,e 和 LW R5,f 移動到前面執(zhí)行，畢竟LW R4,e 和 LW R5,f執(zhí)行并沒有數(shù)據(jù)依賴關(guān)系匈棘，對他們有數(shù)據(jù)依賴關(guān)系的SUB R6,R5,R4指令在R4,R5加載完成后才執(zhí)行的丧慈，沒有影響，過程如下：
正如上圖所示主卫，所有的停頓都完美消除了逃默，指令流水線也無需中斷了鹃愤，這樣CPU的性能也能帶來很好的提升，這就是處理器指令重排的作用完域。關(guān)于編譯器重排以及指令重排(這兩種重排我們后面統(tǒng)一稱為指令重排)相關(guān)內(nèi)容已闡述清晰了软吐，我們必須意識到對于單線程而已指令重排幾乎不會帶來任何影響，比竟重排的前提是保證串行語義執(zhí)行的一致性吟税，但對于多線程環(huán)境而已凹耙，指令重排就可能導(dǎo)致嚴(yán)重的程序輪序執(zhí)行問題，如下
class MixedOrder{
? ? int a = 0;
? ? boolean flag = false;
? ? public void writer(){
? ? ? ? a = 1;
? ? ? ? flag = true;
? ? }
? ? public void read(){
? ? ? ? if(flag){
? ? ? ? ? ? int i = a + 1乌妙；
? ? ? ? }
? ? }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
如上述代碼，同時存在線程A和線程B對該實例對象進行操作建钥，其中A線程調(diào)用寫入方法藤韵，而B線程調(diào)用讀取方法，由于指令重排等原因熊经，可能導(dǎo)致程序執(zhí)行順序變?yōu)槿缦拢?/p>
線程A? ? ? ? ? ? ? ? ? ? 線程B
writer：? ? ? ? ? ? ? ? read：
1:flag = true;? ? ? ? ? 1:flag = true;
2:a = 1;? ? ? ? ? ? ? ? 2: a = 0 ; //誤讀
? ? ? ? ? ? ? ? ? ? ? ? ? 3: i = 1 ;
1
2
3
4
5
由于指令重排的原因泽艘，線程A的flag置為true被提前執(zhí)行了，而a賦值為1的程序還未執(zhí)行完镐依，此時線程B匹涮，恰好讀取flag的值為true，直接獲取a的值（此時B線程并不知道a為0）并執(zhí)行i賦值操作槐壳，結(jié)果i的值為1然低，而不是預(yù)期的2，這就是多線程環(huán)境下务唐，指令重排導(dǎo)致的程序亂序執(zhí)行的結(jié)果雳攘。因此，請記住枫笛，指令重排只會保證單線程中串行語義的執(zhí)行的一致性吨灭，但并不會關(guān)心多線程間的語義一致性。
可見性
理解了指令重排現(xiàn)象后刑巧，可見性容易了喧兄，可見性指的是當(dāng)一個線程修改了某個共享變量的值，其他線程是否能夠馬上得知這個修改的值啊楚。對于串行程序來說吠冤，可見性是不存在的，因為我們在任何一個操作中修改了某個變量的值恭理，后續(xù)的操作中都能讀取這個變量值咨演，并且是修改過的新值。但在多線程環(huán)境中可就不一定了蚯斯，前面我們分析過薄风，由于線程對共享變量的操作都是線程拷貝到各自的工作內(nèi)存進行操作后才寫回到主內(nèi)存中的饵较，這就可能存在一個線程A修改了共享變量x的值，還未寫回主內(nèi)存時遭赂，另外一個線程B又對主內(nèi)存中同一個共享變量x進行操作循诉，但此時A線程工作內(nèi)存中共享變量x對線程B來說并不可見，這種工作內(nèi)存與主內(nèi)存同步延遲現(xiàn)象就造成了可見性問題撇他，另外指令重排以及編譯器優(yōu)化也可能導(dǎo)致可見性問題茄猫，通過前面的分析，我們知道無論是編譯器優(yōu)化還是處理器優(yōu)化的重排現(xiàn)象困肩，在多線程環(huán)境下划纽，確實會導(dǎo)致程序輪序執(zhí)行的問題，從而也就導(dǎo)致可見性問題锌畸。
有序性
有序性是指對于單線程的執(zhí)行代碼勇劣，我們總是認(rèn)為代碼的執(zhí)行是按順序依次執(zhí)行的，這樣的理解并沒有毛病潭枣，畢竟對于單線程而言確實如此比默，但對于多線程環(huán)境，則可能出現(xiàn)亂序現(xiàn)象盆犁，因為程序編譯成機器碼指令后可能會出現(xiàn)指令重排現(xiàn)象命咐，重排后的指令與原指令的順序未必一致，要明白的是谐岁，在Java程序中醋奠，倘若在本線程內(nèi)，所有操作都視為有序行為伊佃，如果是多線程環(huán)境下钝域，一個線程中觀察另外一個線程，所有操作都是無序的锭魔，前半句指的是單線程內(nèi)保證串行語義執(zhí)行的一致性例证，后半句則指指令重排現(xiàn)象和工作內(nèi)存與主內(nèi)存同步延遲現(xiàn)象。
JMM提供的解決方案
在理解了原子性迷捧，可見性以及有序性問題后织咧，看看JMM是如何保證的，在Java內(nèi)存模型中都提供一套解決方案供Java工程師在開發(fā)過程使用漠秋，如原子性問題笙蒙，除了JVM自身提供的對基本數(shù)據(jù)類型讀寫操作的原子性外，對于方法級別或者代碼塊級別的原子性操作庆锦，可以使用synchronized關(guān)鍵字或者重入鎖(ReentrantLock)保證程序執(zhí)行的原子性捅位，關(guān)于synchronized的詳解，看博主另外一篇文章( 深入理解Java并發(fā)之synchronized實現(xiàn)原理)。而工作內(nèi)存與主內(nèi)存同步延遲現(xiàn)象導(dǎo)致的可見性問題艇搀，可以使用synchronized關(guān)鍵字或者volatile關(guān)鍵字解決尿扯，它們都可以使一個線程修改后的變量立即對其他線程可見。對于指令重排導(dǎo)致的可見性問題和有序性問題焰雕，則可以利用volatile關(guān)鍵字解決衷笋，因為volatile的另外一個作用就是禁止重排序優(yōu)化，關(guān)于volatile稍后會進一步分析矩屁。除了靠sychronized和volatile關(guān)鍵字來保證原子性辟宗、可見性以及有序性外，JMM內(nèi)部還定義一套happens-before 原則來保證多線程環(huán)境下兩個操作間的原子性吝秕、可見性以及有序性泊脐。
理解JMM中的happens-before 原則
倘若在程序開發(fā)中，僅靠sychronized和volatile關(guān)鍵字來保證原子性烁峭、可見性以及有序性容客，那么編寫并發(fā)程序可能會顯得十分麻煩，幸運的是则剃，在Java內(nèi)存模型中耘柱，還提供了happens-before 原則來輔助保證程序執(zhí)行的原子性如捅、可見性以及有序性的問題棍现，它是判斷數(shù)據(jù)是否存在競爭、線程是否安全的依據(jù)镜遣，happens-before 原則內(nèi)容如下
程序順序原則己肮，即在一個線程內(nèi)必須保證語義串行性，也就是說按照代碼順序執(zhí)行悲关。
鎖規(guī)則 解鎖(unlock)操作必然發(fā)生在后續(xù)的同一個鎖的加鎖(lock)之前谎僻，也就是說，如果對于一個鎖解鎖后寓辱，再加鎖艘绍，那么加鎖的動作必須在解鎖動作之后(同一個鎖)。
volatile規(guī)則 volatile變量的寫秫筏，先發(fā)生于讀诱鞠，這保證了volatile變量的可見性，簡單的理解就是这敬，volatile變量在每次被線程訪問時航夺，都強迫從主內(nèi)存中讀該變量的值，而當(dāng)該變量發(fā)生變化時崔涂，又會強迫將最新的值刷新到主內(nèi)存阳掐，任何時刻，不同的線程總是能夠看到該變量的最新值。
線程啟動規(guī)則 線程的start()方法先于它的每一個動作缭保，即如果線程A在執(zhí)行線程B的start方法之前修改了共享變量的值汛闸，那么當(dāng)線程B執(zhí)行start方法時，線程A對共享變量的修改對線程B可見
傳遞性 A先于B 涮俄，B先于C 那么A必然先于C
線程終止規(guī)則 線程的所有操作先于線程的終結(jié)蛉拙，Thread.join()方法的作用是等待當(dāng)前執(zhí)行的線程終止。假設(shè)在線程B終止之前彻亲，修改了共享變量孕锄，線程A從線程B的join方法成功返回后，線程B對共享變量的修改將對線程A可見苞尝。
線程中斷規(guī)則 對線程 interrupt()方法的調(diào)用先行發(fā)生于被中斷線程的代碼檢測到中斷事件的發(fā)生畸肆，可以通過Thread.interrupted()方法檢測線程是否中斷。
對象終結(jié)規(guī)則 對象的構(gòu)造函數(shù)執(zhí)行宙址，結(jié)束先于finalize()方法
上述8條原則無需手動添加任何同步手段(synchronized|volatile)即可達到效果轴脐，下面我們結(jié)合前面的案例演示這8條原則如何判斷線程是否安全，如下：
class MixedOrder{
? ? int a = 0;
? ? boolean flag = false;
? ? public void writer(){
? ? ? ? a = 1;
? ? ? ? flag = true;
? ? }
? ? public void read(){
? ? ? ? if(flag){
? ? ? ? ? ? int i = a + 1抡砂；
? ? ? ? }
? ? }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
同樣的道理大咱，存在兩條線程A和B，線程A調(diào)用實例對象的writer()方法注益，而線程B調(diào)用實例對象的read()方法碴巾，線程A先啟動而線程B后啟動，那么線程B讀取到的i值是多少呢丑搔？現(xiàn)在依據(jù)8條原則厦瓢，由于存在兩條線程同時調(diào)用，因此程序次序原則不合適啤月。writer()方法和read()方法都沒有使用同步手段煮仇，鎖規(guī)則也不合適。沒有使用volatile關(guān)鍵字谎仲，volatile變量原則不適應(yīng)浙垫。線程啟動規(guī)則、線程終止規(guī)則郑诺、線程中斷規(guī)則夹姥、對象終結(jié)規(guī)則、傳遞性和本次測試案例也不合適间景。線程A和線程B的啟動時間雖然有先后佃声，但線程B執(zhí)行結(jié)果卻是不確定，也是說上述代碼沒有適合8條原則中的任意一條倘要，也沒有使用任何同步手段圾亏，所以上述的操作是線程不安全的十拣，因此線程B讀取的值自然也是不確定的。修復(fù)這個問題的方式很簡單志鹃，要么給writer()方法和read()方法添加同步手段夭问，如synchronized或者給變量flag添加volatile關(guān)鍵字，確保線程A修改的值對線程B總是可見曹铃。
volatile內(nèi)存語義
volatile在并發(fā)編程中很常見缰趋，但也容易被濫用，現(xiàn)在我們就進一步分析volatile關(guān)鍵字的語義陕见。volatile是Java虛擬機提供的輕量級的同步機制秘血。volatile關(guān)鍵字有如下兩個作用
保證被volatile修飾的共享gong’x變量對所有線程總數(shù)可見的，也就是當(dāng)一個線程修改了一個被volatile修飾共享變量的值评甜，新值總數(shù)可以被其他線程立即得知灰粮。
禁止指令重排序優(yōu)化。
volatile的可見性
關(guān)于volatile的可見性作用忍坷，我們必須意識到被volatile修飾的變量對所有線程總數(shù)立即可見的粘舟，對volatile變量的所有寫操作總是能立刻反應(yīng)到其他線程中，但是對于volatile變量運算操作在多線程環(huán)境并不保證安全性佩研，如下
public class VolatileVisibility {
? ? public static volatile int i =0;
? ? public static void increase(){
? ? ? ? i++;
? ? }
}
1
2
3
4
5
6
7
正如上述代碼所示柑肴，i變量的任何改變都會立馬反應(yīng)到其他線程中，但是如此存在多條線程同時調(diào)用increase()方法的話旬薯，就會出現(xiàn)線程安全問題晰骑，畢竟i++;操作并不具備原子性，該操作是先讀取值袍暴，然后寫回一個新值些侍，相當(dāng)于原來的值加上1隶症，分兩步完成政模，如果第二個線程在第一個線程讀取舊值和寫回新值期間讀取i的域值，那么第二個線程就會與第一個線程一起看到同一個值蚂会，并執(zhí)行相同值的加1操作淋样，這也就造成了線程安全失敗，因此對于increase方法必須使用synchronized修飾胁住，以便保證線程安全趁猴，需要注意的是一旦使用synchronized修飾方法后，由于synchronized本身也具備與volatile相同的特性彪见，即可見性儡司，因此在這樣種情況下就完全可以省去volatile修飾變量。
public class VolatileVisibility {
? ? public static int i =0;
? ? public synchronized static void increase(){
? ? ? ? i++;
? ? }
}
1
2
3
4
5
6
7
現(xiàn)在來看另外一種場景余指，可以使用volatile修飾變量達到線程安全的目的捕犬，如下
public class VolatileSafe {
? ? volatile boolean close;
? ? public void close(){
? ? ? ? close=true;
? ? }
? ? public void doWork(){
? ? ? ? while (!close){
? ? ? ? ? ? System.out.println("safe....");
? ? ? ? }
? ? }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
由于對于boolean變量close值的修改屬于原子性操作跷坝，因此可以通過使用volatile修飾變量close，使用該變量對其他線程立即可見碉碉，從而達到線程安全的目的柴钻。那么JMM是如何實現(xiàn)讓volatile變量對其他線程立即可見的呢？實際上垢粮，當(dāng)寫一個volatile變量時贴届，JMM會把該線程對應(yīng)的工作內(nèi)存中的共享變量值刷新到主內(nèi)存中，當(dāng)讀取一個volatile變量時蜡吧，JMM會把該線程對應(yīng)的工作內(nèi)存置為無效毫蚓，那么該線程將只能從主內(nèi)存中重新讀取共享變量。volatile變量正是通過這種寫-讀方式實現(xiàn)對其他線程可見（但其內(nèi)存語義實現(xiàn)則是通過內(nèi)存屏障昔善，稍后會說明）绍些。
volatile禁止重排優(yōu)化
volatile關(guān)鍵字另一個作用就是禁止指令重排優(yōu)化，從而避免多線程環(huán)境下程序出現(xiàn)亂序執(zhí)行的現(xiàn)象耀鸦，關(guān)于指令重排優(yōu)化前面已詳細(xì)分析過柬批，這里主要簡單說明一下volatile是如何實現(xiàn)禁止指令重排優(yōu)化的。先了解一個概念袖订，內(nèi)存屏障(Memory Barrier）氮帐。
內(nèi)存屏障，又稱內(nèi)存柵欄洛姑，是一個CPU指令上沐，它的作用有兩個，一是保證特定操作的執(zhí)行順序楞艾，二是保證某些變量的內(nèi)存可見性（利用該特性實現(xiàn)volatile的內(nèi)存可見性）参咙。由于編譯器和處理器都能執(zhí)行指令重排優(yōu)化。如果在指令間插入一條Memory Barrier則會告訴編譯器和CPU硫眯，不管什么指令都不能和這條Memory Barrier指令重排序蕴侧，也就是說通過插入內(nèi)存屏障禁止在內(nèi)存屏障前后的指令執(zhí)行重排序優(yōu)化。Memory Barrier的另外一個作用是強制刷出各種CPU的緩存數(shù)據(jù)两入，因此任何CPU上的線程都能讀取到這些數(shù)據(jù)的最新版本净宵。總之裹纳，volatile變量正是通過內(nèi)存屏障實現(xiàn)其在內(nèi)存中的語義择葡，即可見性和禁止重排優(yōu)化。下面看一個非常典型的禁止重排優(yōu)化的例子DCL剃氧，如下：
/**
* Created by zejian on 2017/6/11.
* Blog : http://blog.csdn.net/javazejian [原文地址,請尊重原創(chuàng)]
*/
public class DoubleCheckLock {
? ? private static DoubleCheckLock instance;
? ? private DoubleCheckLock(){}
? ? public static DoubleCheckLock getInstance(){
? ? ? ? //第一次檢測
? ? ? ? if (instance==null){
? ? ? ? ? ? //同步
? ? ? ? ? ? synchronized (DoubleCheckLock.class){
? ? ? ? ? ? ? ? if (instance == null){
? ? ? ? ? ? ? ? ? ? //多線程環(huán)境下可能會出現(xiàn)問題的地方
? ? ? ? ? ? ? ? ? ? instance = new DoubleCheckLock();
? ? ? ? ? ? ? ? }
? ? ? ? ? ? }
? ? ? ? }
? ? ? ? return instance;
? ? }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
上述代碼一個經(jīng)典的單例的雙重檢測的代碼敏储，這段代碼在單線程環(huán)境下并沒有什么問題，但如果在多線程環(huán)境下就可以出現(xiàn)線程安全問題朋鞍。原因在于某一個線程執(zhí)行到第一次檢測已添，讀取到的instance不為null時迫横，instance的引用對象可能沒有完成初始化。因為instance = new DoubleCheckLock();可以分為以下3步完成(偽代碼)
memory = allocate(); //1.分配對象內(nèi)存空間
instance(memory);? ? //2.初始化對象
instance = memory;? //3.設(shè)置instance指向剛分配的內(nèi)存地址酝碳，此時instance矾踱！=null
1
2
3
由于步驟1和步驟2間可能會重排序，如下：
memory = allocate(); //1.分配對象內(nèi)存空間
instance = memory;? //3.設(shè)置instance指向剛分配的內(nèi)存地址疏哗，此時instance呛讲！=null，但是對象還沒有初始化完成返奉！
instance(memory);? ? //2.初始化對象
1
2
3
由于步驟2和步驟3不存在數(shù)據(jù)依賴關(guān)系贝搁，而且無論重排前還是重排后程序的執(zhí)行結(jié)果在單線程中并沒有改變，因此這種重排優(yōu)化是允許的芽偏。但是指令重排只會保證串行語義的執(zhí)行的一致性(單線程)雷逆，但并不會關(guān)心多線程間的語義一致性。所以當(dāng)一條線程訪問instance不為null時污尉，由于instance實例未必已初始化完成膀哲，也就造成了線程安全問題。那么該如何解決呢被碗，很簡單某宪，我們使用volatile禁止instance變量被執(zhí)行指令重排優(yōu)化即可。
? //禁止指令重排優(yōu)化
? private volatile static DoubleCheckLock instance;
1
2
ok~锐朴，到此相信我們對Java內(nèi)存模型和volatile應(yīng)該都有了比較全面的認(rèn)識兴喂，總而言之，我們應(yīng)該清楚知道焚志，JMM就是一組規(guī)則衣迷，這組規(guī)則意在解決在并發(fā)編程可能出現(xiàn)的線程安全問題，并提供了內(nèi)置解決方案（happen-before原則）及其外部可使用的同步手段(synchronized/volatile等)酱酬，確保了程序執(zhí)行在多線程環(huán)境中的應(yīng)有的原子性壶谒，可視性及其有序性。
如果想學(xué)習(xí)Java工程化岳悟、高性能及分布式佃迄、深入淺出泼差。性能調(diào)優(yōu)贵少、Spring，MyBatis堆缘，Netty源碼分析的朋友可以加我的Java高級架構(gòu)進階群：180705916滔灶，群里有阿里大牛直播講解技術(shù)，以及Java大型互聯(lián)網(wǎng)技術(shù)的視頻免費分享給大家
