溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
這篇文章主要講解了“JVM虛擬機內存模型與高效并發知識點有哪些”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學習“JVM虛擬機內存模型與高效并發知識點有哪些”吧！
Java內存模型，即Java Memory Model，簡稱 JMM ，它是一種抽象的概念，或者是一種協議，用來解決在并發編程過程中內存訪問的問題，同時又可以兼容不同的硬件和操作系統，JMM的原理與硬件一致性的原理類似。在硬件一致性的實現中，每個CPU會存在一個高速緩存，并且各個CPU通過與自己的高速緩存交互來向共享內存中讀寫數據。
如下圖所示，在Java內存模型中，所有的變量都存儲在主內存。每個Java線程都存在著自己的工作內存，工作內存中保存了該線程用得到的變量的副本，線程對變量的讀寫都在工作內存中完成，無法直接操作主內存，也無法直接訪問其他線程的工作內存。當一個線程之間的變量的值的傳遞必須經過主內存。
當兩個線程A和線程B之間要完成通信的話，要經歷如下兩步：
線程A從主內存中將共享變量讀入線程A的工作內存后并進行操作，之后將數據重新寫回到主內存中；
線程B從主存中讀取最新的共享變量
volatile關鍵字使得每次volatile變量都能夠強制刷新到主存，從而對每個線程都是可見的。
需要注意的是，JMM與Java內存區域的劃分是不同的概念層次，更恰當說JMM描述的是一組規則，通過這組規則控制程序中各個變量在共享數據區域和私有數據區域的訪問方式。在JMM中主內存屬于共享數據區域，從某個程度上講應該包括了堆和方法區，而工作內存數據線程私有數據區域，從某個程度上講則應該包括程序計數器、虛擬機棧以及本地方法棧。
上面介紹了JMM中主內存和工作內存交互以及線程之間通信的原理，但是具體到各個內存之間如何進行變量的傳遞，JMM定義了8種操作，用來實現主內存與工作內存之間的具體交互協議：
lock unlock read load use assign store write
如果要把一個變量從主內存中復制到工作內存，就需要按順尋地執行 read 和 load 操作，如果把變量從工作內存中同步回主內存中，就要按順序地執行 store 和 writ e操作。Java內存模型只要求上述兩個操作必須按順序執行，而沒有保證必須是連續執行。也就是 read 和 load 之間， store 和 write 之間是可以插入其他指令的，如對主內存中的變量 a 、 b 進行訪問時，可能的順序是 read a ， read b ， load b ， load a 。
Java內存模型還規定了在執行上述八種基本操作時，必須滿足如下規則：
不允許 read 和 load 、 store 和 write 操作之一單獨出現；
不允許一個線程丟棄它的最近 assign 的操作，即變量在工作內存中改變了之后必須同步到主內存中；
不允許一個線程無原因地（沒有發生過任何 assign 操作）把數據從工作內存同步回主內存中；
一個新的變量只能在主內存中誕生，不允許在工作內存中直接使用一個未被初始化（load或assign）的變量。即就是對一個變量實施 use 和 store 操作之前，必須先執行過了 assign 和 load 操作；
一個變量在同一時刻只允許一條線程對其進行 lock 操作， lock 和 unlock 必須成對出現；
如果對一個變量執行 lock 操作，將會清空工作內存中此變量的值，在執行引擎使用這個變量前需要重新執行 load 或 assign 操作初始化變量的值；
如果一個變量事先沒有被 lock 操作鎖定，則不允許對它執行 unlock 操作，也不允許去unlock一個被其他線程鎖定的變量；
對一個變量執行 unlock 操作之前，必須先把此變量同步到主內存中（執行 store 和 write操作）。
此外，虛擬機還對voliate關鍵字和long及double做了一些特殊的規定。
保證變量的可見性：當一個被voliate關鍵字修飾的變量被一個線程修改的時候，其他線程可以立刻得到修改之后的結果。當一個線程向被voliate關鍵字修飾的變量寫入數據的時候，虛擬機會強制它被值刷新到主內存中。當一個線程用到被voliate關鍵字修飾的值的時候，虛擬機會強制要求它從主內存中讀取。
屏蔽指令重排序：指令重排序是編譯器和處理器為了高效對程序進行優化的手段，它只能保證程序執行的結果時正確的，但是無法保證程序的操作順序與代碼順序一致。這在單線程中不會構成問題，但是在多線程中就會出現問題。非常經典的例子是在單例方法中同時對字段加入voliate，就是為了防止指令重排序。為了說明這一點，可以看下面的例子。
我們以下面的程序為例來說明voliate是如何防止指令重排序：
public class Singleton {
private volatile static Singleton singleton;
private Singleton() {}
public static Singleton getInstance() {
if (singleton == null) { // 1
sychronized(Singleton.class) {
if (singleton == null) {
singleton = new Singleton(); // 2
}
}
}
return singleton;
}
}
復制代碼實際上當程序執行到2處的時候，如果我們沒有使用voliate關鍵字修飾變量singleton，就可能會造成錯誤。這是因為使用 new 關鍵字初始化一個對象的過程并不是一個原子的操作，它分成下面三個步驟進行：
給 singleton 分配內存
調用 Singleton 的構造函數來初始化成員變量
將 singleton 對象指向分配的內存空間（執行完這步 singleton 就為非 null 了）
如果虛擬機存在指令重排序優化，則步驟2和3的順序是無法確定的。如果A線程率先進入同步代碼塊并先執行了3而沒有執行2，此時因為singleton已經非null。這時候線程B到了1處，判斷singleton非null并將其返回使用，因為此時Singleton實際上還未初始化，自然就會出錯。
但是特別注意在jdk 1.5以前的版本使用了volatile的雙檢鎖還是有問題的。其原因是Java 5以前的JMM（Java 內存模型）是存在缺陷的，即時將變量聲明成volatile也不能完全避免重排序，主要是volatile變量前后的代碼仍然存在重排序問題。這個volatile屏蔽重排序的問題在jdk 1.5 (JSR-133)中才得以修復，這時候jdk對volatile增強了語義，對volatile對象都會加入讀寫的內存屏障，以此來保證可見性，這時候2-3就變成了代碼序而不會被CPU重排，所以在這之后才可以放心使用volatile。
虛擬機除了對voliate關鍵字做了特殊規定，還對long及double做了一些特殊的規定：允許沒有被volatile修飾的long和double類型的變量讀寫操作分成兩個32位操作。也就是說，對long和double的讀寫是非原子的，它是分成兩個步驟來進行的。但是，你可以通過將它們聲明為voliate的來保證對它們的讀寫的原子性。
Java內存模型是通過各種操作定義的，JMM為程序中所有的操作定義了一個偏序關系，就是先行發生原則(Happens-before)。它是判斷數據是否存在競爭、線程是否安全的主要依據。想要保證執行操作B的線程看到操作A的結果，那么在A和B之間必須滿足Happens-before關系，否則JVM就可以對它們任意地排序。
先行發生原則主要包括下面幾項，當兩個變量之間滿足以下關系中的任意一個的時候，我們就可以判斷它們之間的是存在先后順序的，串行執行的。
程序次序規則(Program Order Rule) 管理鎖定規則(Monitor Lock Rule) volatile變量規則(Volatile Variable Rule) 線程啟動規則(Thread Start Rule) 線程終止規則(Thread Termination Rule) 線程中斷規則(Thread Interruption Rule) 對象終結規則(Finilizer Rule) 傳遞性(Transitivity)
不同操作時間先后順序與先行發生原則之間沒有關系，二者不能相互推斷，衡量并發安全問題不能受到時間順序的干擾，一切都要以先行發生原則為準。
如果兩個操作訪問同一個變量，且這兩個操作有一個為寫操作，此時這兩個操作就存在數據依賴性這里就存在三種情況：1).讀后寫；2).寫后寫；3). 寫后讀，三種操作都是存在數據依賴性的，如果重排序會對最終執行結果會存在影響。編譯器和處理器在重排序時，會遵守數據依賴性，編譯器和處理器不會改變存在數據依賴性關系的兩個操作的執行順序。
還有就是 as-if-serial 語義：不管怎么重排序（編譯器和處理器為了提供并行度），（單線程）程序的執行結果不能被改變。編譯器，runtime和處理器都必須遵守as-if-serial語義。as-if-serial語義保證單線程內程序的執行結果不被改變，happens-before關系保證正確同步的多線程程序的執行結果不被改變。
先行發生原則(happens-before)和as-if-serial語義是虛擬機為了保證執行結果不變的情況下提供程序的并行度優化所遵循的原則，前者適用于多線程的情形，后者適用于單線程的環境。
在此我向大家推薦一個Java高級群 ：725633148 里面會分享一些資深架構師錄制的視頻錄像：（有Spring，MyBatis，Netty源碼分析，高并發、高性能、分布式、微服務架構的原理，JVM性能優化、分布式架構）等這些成為架構師必備的知識體系 進群馬上免費領取，目前受益良多！
在Window系統和Linux系統上，Java線程的實現是基于一對一的線程模型，所謂的一對一模型，實際上就是通過語言級別層面程序去間接調用系統內核的線程模型，即我們在使用Java線程時，Java虛擬機內部是轉而調用當前操作系統的內核線程來完成當前任務。這里需要了解一個術語，內核線程(Kernel-Level Thread，KLT)，它是由操作系統內核(Kernel)支持的線程，這種線程是由操作系統內核來完成線程切換，內核通過操作調度器進而對線程執行調度，并將線程的任務映射到各個處理器上。每個內核線程可以視為內核的一個分身，這也就是操作系統可以同時處理多任務的原因。由于我們編寫的多線程程序屬于語言層面的，程序一般不會直接去調用內核線程，取而代之的是一種輕量級的進程(Light Weight Process)，也是通常意義上的線程，由于每個輕量級進程都會映射到一個內核線程，因此我們可以通過輕量級進程調用內核線程，進而由操作系統內核將任務映射到各個處理器，這種輕量級進程與內核線程間1對1的關系就稱為一對一的線程模型。
如圖所示，每個線程最終都會映射到CPU中進行處理，如果CPU存在多核，那么一個CPU將可以并行執行多個線程任務。
Java中可以使用三種方式來保障程序的線程安全：1).互斥同步；2).非阻塞同步;3).無同步。
在Java中最基本的使用同步方式是使用 sychronized 關鍵字，該關鍵字在被編譯之后會在同步代碼塊前后形成 monitorenter 和 monitorexit 字節碼指令。這兩個字節碼都需要一個reference類型的參數來指明要鎖定和解鎖的對象。如果在Java程序中明確指定了對象參數，就會使用該對象，否則就會根據sychronized修飾的是實例方法還是類方法，去去對象實例或者Class對象作為加鎖對象。
synchronized先天具有 重入性 ：根據虛擬機的要求，在執行sychronized指令時，首先要嘗試獲取對象的鎖。如果這個對象沒有被鎖定，或者當前線程已經擁有了該對象的鎖，就把鎖的計數器加1，相應地執行 monitorexit 指令時會將鎖的計數器減1，當計數器為0時就釋放鎖。弱獲取對象鎖失敗，那當前線程就要阻塞等待，直到對象鎖被另外一個線程釋放為止。
除了使用sychronized，我們還可以使用JUC中的ReentrantLock來實現同步，它與sychronized類似，區別主要表現在以下3個方面：
等待可中斷：當持有鎖的線程長期不釋放鎖的時候，正在等待的線程可以選擇放棄等待；
公平鎖：多個線程等待同一個鎖時，必須按照申請鎖的時間順序來依次獲得鎖；而非公平鎖無法保證，當鎖被釋放時任何在等待的線程都可以獲得鎖。sychronized本身時非公平鎖，而ReentrantLock默認是非公平的，可以通過構造函數要求其為公平的。
鎖可以綁定多個條件：ReentrantLock可以綁定多個Condition對象，而sychronized要與多個條件關聯就不得不加一個鎖，ReentrantLock只要多次調用newCondition即可。
在JDK1.5之前，sychronized在多線程環境下比ReentrantLock要差一些，但是在JDK1.6以上，虛擬機對sychronized的性能進行了優化，性能不再是使用ReentrantLock替代sychronized的主要因素。
所謂非阻塞同步就是在實現同步的過程中無需將線程掛起，它是相對于互斥同步而言的。互斥同步本質上是一種悲觀的并發策略，而非阻塞同步是一種樂觀的并發策略。在JUC中的許多并發組建都是基于CAS原理實現的，所謂CAS就是Compare-And-Swape，類似于樂觀加鎖。但與我們熟知的樂觀鎖不同的是，它在判斷的時候會涉及到3個值：“新值”、“舊值”和“內存中的值”，在實現的時候會使用一個無限循環，每次拿“舊值”與“內存中的值”進行比較，如果兩個值一樣就說明“內存中的值”沒有被其他線程修改過，否則就被修改過，需要重新讀取內存中的值為“舊值”，再拿“舊值”與“內存中的值”進行判斷。直到“舊值”與“內存中的值”一樣，就把“新值”更新到內存當中。
這里要注意上面的CAS操作是分3個步驟的，但是這3個步驟必須一次性完成，因為不然的話，當判斷“內存中的值”與“舊值”相等之后，向內存寫入“新值”之間被其他線程修改就可能會得到錯誤的結果。JDK中的 sun.misc.Unsafe 中的 compareAndSwapInt 等一系列方法Native就是用來完成這種操作的。另外還要注意，上面的CAS操作存在一些問題：
AtomicReference
所謂無同步方案就是不需要同步，比如一些集合屬于不可變集合，那么就沒有必要對其進行同步。有一些方法，它的作用就是一個函數，這在函數式編程思想里面比較常見，這種函數通過輸入就可以預知輸出，而且參與計算的變量都是局部變量等，所以也沒必要進行同步。還有一種就是線程局部變量，比如ThreadLocal等。
自旋鎖用來解決互斥同步過程中線程切換的問題，因為線程切換本身是存在一定的開銷的。如果物理機器有一個以上的處理器，能讓兩個或以上的線程同時并行執行，我們就可以讓后面請求鎖的那個線程“稍等一會”，但不放棄處理器的執行時間，看看持有鎖的線程是否很快就會釋放鎖。為了讓線程等待，我們只須讓線程執行一個忙循環（自旋），這項技術就是所謂的自旋鎖。
自旋鎖在JDK 1.4.2中就已經引入，只不過默認是關閉的，可以使用 -XX:+UseSpinnin g參數來開啟，在JDK 1.6中就已經改為默認開啟了。自旋等待本身雖然避免了線程切換的開銷，但它是要占用處理器時間的， 所以如果鎖被占用的時間很短，自旋等待的效果就會非常好，反之如果鎖被占用的時間很長，那么自旋的線程只會白白消耗處理器資源，而不會做任何有用的工作， 反而會帶來性能的浪費。
我們可以通過參數 -XX:PreBlockSpin 來指定自旋的次數，默認值是10次。在JDK 1.6中引入了 自適應的自旋鎖 。自適應意味著自旋的時間不再固定了，而是由前一次在同一個鎖上的自旋時間及鎖的擁有者的狀態來決定。如果在同一個鎖對象上，自旋等待剛剛成功獲得過鎖，并且持有鎖的線程正在運行中，那么虛擬機就會認為這次自旋也很有可能再次成功，進而它將允許自旋等待持續相對更長的時間， 比如100個循環。另一方面，如果對于某個鎖，自旋很少成功獲得過，那在以后要獲取這個鎖時將可能省略掉自旋過程，以避免浪費處理器資源。
下面是自旋鎖的一種實現的例子：
public class SpinLock {
private AtomicReference<Thread> sign = new AtomicReference<>();
public void lock() {
Thread current = Thread.currentThread();
while(!sign.compareAndSet(null, current)) ;
}
public void unlock() {
Thread current = Thread.currentThread();
sign.compareAndSet(current, null);
}
}
復制代碼從上面的例子我們可以看出，自旋鎖是通過CAS操作，通過比較期值是否符合預期來加鎖和釋放鎖的。在lock方法中如果sign中的值是null，也就代標鎖被釋放了，否則鎖被其他線程占用，需要通過循環來等待。在unlock方法中，通過將sign中的值設置為null來通知正在等待的線程鎖已經被釋放。
鎖粗化的概念應該比較好理解，就是將多次連接在一起的加鎖、解鎖操作合并為一次，將多個連續的鎖擴展成一個范圍更大的鎖。
public class StringBufferTest {
StringBuffer sb = new StringBuffer();
public void append(){
sb.append("a");
sb.append("b");
sb.append("c");
}
}
復制代碼這里每次調用 sb.append() 方法都需要加鎖和解鎖，如果虛擬機檢測到有一系列連串的對同一個對象加鎖和解鎖操作，就會將其合并成一次范圍更大的加鎖和解鎖操作，即在第一次 append()方法時進行加鎖，最后一次 append() 方法結束后進行解鎖。
輕量級鎖是用來解決重量級鎖在互斥過程中的性能消耗問題的，所謂的重量級鎖就是 sychronized 關鍵字實現的鎖。 synchronized 是通過對象內部的一個叫做監視器鎖（monitor）來實現的。但是監視器鎖本質又依賴于底層的操作系統的 Mutex Lock 來實現的。而操作系統實現線程之間的切換就需要從用戶態轉換到核心態，這個成本非常高，狀態之間的轉換需要相對比較長的時間。
首先，對象的對象頭中存在一個部分叫做 Mark word ，其中存儲了對象的運行時數據，如哈希碼、GC年齡等，其中有2bit用于存儲鎖標志位。
在代碼進入同步塊的時候，如果對象鎖狀態為無鎖狀態（鎖標志位為“01”狀態），虛擬機首先將在當前線程的棧幀中建立一個名為 鎖記錄 （ Lock Record ）的空間，用于存儲鎖對象目前的 Mark Word 的拷貝。拷貝成功后，虛擬機將使用CAS操作嘗試將對象的 Mark Word 更新為指向 Lock Record 的指針，并將 Lock Record 里的 owner 指針指向對的 Mark word 。并且將對象的 Mark Word 的鎖標志位變為"00"，表示該對象處于鎖定狀態。更新操作失敗了，虛擬機首先會檢查對象的 Mark Word 是否指向當前線程的棧幀，如果是就說明當前線程已經擁有了這個對象的鎖，那就可以直接進入同步塊繼續執行。否則說明多個線程競爭鎖，輕量級鎖就要膨脹為重量級鎖，鎖標志的變為“10”， Mark Word 中存儲的就是指向重量級鎖（互斥量）的指針，后面等待鎖的線程也要進入阻塞狀態。 而當前線程便嘗試使用自旋來獲取鎖，自旋就是為了不讓線程阻塞，而采用循環去獲取鎖的過程。
從上面我們可以看出，實際上當一個線程獲取了一個對象的輕量級鎖之后，對象的 Mark Word會指向線程的棧幀中的 Lock Record ，而棧幀中的 Lock Record 也會指向對象的 Mark Word 。 棧幀中的 Lock Record 用于判斷當前線程已經持有了哪些對象的鎖，而對象的 Mark Word 用來判斷哪個線程持有了當前對象的鎖。 當一個線程嘗試去獲取一個對象的鎖的時候，會先通過鎖標志位判斷當前對象是否被加鎖，然后通過CAS操作來判斷當前獲取該對象鎖的線程是否是當前線程。
輕量級鎖不是設計用來取代重量級鎖的，因為它除了加鎖之外還增加了額外的CAS操作，因此在競爭激烈的情況下，輕量級鎖會比傳統的重量級鎖更慢。
一個對象剛開始實例化的時候，沒有任何線程來訪問它的時候。它是可偏向的，意味著，它現在認為只可能有一個線程來訪問它，所以當第一個線程來訪問它的時候，它會偏向這個線程。此時，對象持有偏向鎖，偏向第一個線程。這個線程在修改對象頭成為偏向鎖的時候使用CAS操作，并將對象頭中的ThreadID改成自己的ID，之后再次訪問這個對象時，只需要對比ID，不需要再使用CAS在進行操作。
一旦有第二個線程訪問這個對象，因為偏向鎖不會主動釋放，所以第二個線程可以看到對象時偏向狀態，這時表明在這個對象上已經存在競爭了，檢查原來持有該對象鎖的線程是否依然存活，如果掛了，則可以將對象變為無鎖狀態，然后重新偏向新的線程，如果原來的線程依然存活，則馬上執行那個線程的操作棧，檢查該對象的使用情況，如果仍然需要持有偏向鎖，則偏向鎖升級為輕量級鎖，（偏向鎖就是這個時候升級為輕量級鎖的）。如果不存在使用了，則可以將對象回復成無鎖狀態，然后重新偏向。
輕量級鎖認為競爭存在，但是競爭的程度很輕，一般兩個線程對于同一個鎖的操作都會錯開，或者說稍微等待一下（自旋），另一個線程就會釋放鎖。 但是當自旋超過一定的次數，或者一個線程在持有鎖，一個在自旋，又有第三個來訪時，輕量級鎖膨脹為重量級鎖，重量級鎖使除了擁有鎖的線程以外的線程都阻塞，防止CPU空轉。
如果大多數情況下鎖總是被多個不同的線程訪問，那么偏向模式就是多余的，可以通過 -XX:-UserBiaseLocking 禁止偏向鎖優化。
輕量級鎖和偏向鎖的提出是基于一個事實，就是大部分情況下獲取一個對象鎖的線程都是同一個線程，它在這種情形下的效率會比重量級鎖高，當鎖總是被多個不同的線程訪問它們的效率就不一定比重量級鎖高。 因此，它們的提出不是用來取代重量級鎖的，但在一些場景中會比重量級鎖效率高，因此我們可以根據自己應用的場景通過虛擬機參數來設置是否啟用它們。
感謝各位的閱讀，以上就是“JVM虛擬機內存模型與高效并發知識點有哪些”的內容了，經過本文的學習后，相信大家對JVM虛擬機內存模型與高效并發知識點有哪些這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關知識點的文章，歡迎關注！
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
