淺談volatile

- 淺談volatile
- 簡介
- JMM概述
- volatile的特性
- 1、可見性
- 舉個例子
- 總結
- 2、無法保證原子性
- 舉個例子
- 分析
- 使用volatile對原子性測驗
- 使用鎖的機制
- 總結
- 3、禁止指令重排
- 什么是指令重排序
- 重排序怎么提高執行速度
- 重排序的問題所在
- volatile禁止指令重排序
- 記憶體屏障(Memory Barrier) 作用
- volatile記憶體屏障的插入策略
- 1、可見性
簡介
volatile是Java語言中的一種輕量級的同步機制,它可以確保共享變數的記憶體可見性,也就是當一個執行緒修改了共享變數的值時,其他執行緒能夠立即知道這個修改,跟synchronized一樣都是同步機制,但是相比之下,synchronized屬于重量級鎖,volatile屬于輕量級鎖,
JMM概述
JMM就是Java記憶體模型(Java Memory Model),是Java虛擬機規范的一種記憶體模型,屏蔽掉各種硬體和作業系統的記憶體訪問差異,以實作讓Java程式在各種平臺下都能達到一致的并發效果,
Java記憶體模型規定了Java程式的變數(包括實體變數,靜態變數,但是不包括區域變數和方法引數)全部存盤在主記憶體中,定義了各種變數(執行緒的共享變數)的訪問規則,以及在JVM中將變數存盤到主記憶體與從主記憶體讀取變數的底層細節,
JMM的規定
- 所有共享變數都存在于主記憶體(包括實體變數,靜態變數,但是不包括區域變數和方法引數),因為區域變數是執行緒私有,不存在競爭問題,
- 每個執行緒都有自己的作業記憶體,所需要的變數是主記憶體中的副本,
- 執行緒對變數的讀、寫操作都只能在作業記憶體中完成,不能直接參與讀寫主記憶體的變數,
- 不同的執行緒也不能去直接訪問不同執行緒的作業記憶體的變數,執行緒間的變數傳遞需要通過主記憶體來中轉完成,
volatile的特性
1、可見性
volatile可以保證執行緒的可見性,即當多個執行緒訪問同一個變數的時候,此變數發生改變,其他執行緒也能實時獲得到這個修改的值,
在java中,變數都會被放在推記憶體(所有執行緒共享的記憶體)中,多個執行緒對共享記憶體是不可見的,當每個執行緒去獲取這個變數的值時,實際上是copy一份副本在執行緒自身的作業記憶體中,
舉個例子
我們將main作為主執行緒,MyThread為子執行緒,在子執行緒中定義一個共享變數flag,主執行緒會去訪問這個共享變數,在不加volatile的時候,flag在主執行緒讀到的永遠是為false,因為兩個執行緒是不可見的,
public class T2_Volatile01 {
public static void main(String[] args) { // 主執行緒
MyThread my = new MyThread();
my.start();
while (true) {
if (my.isFlag()) System.out.println("進入等待...");
}
}
}
class MyThread extends Thread { // 子執行緒
private volatile boolean flag = false;
@Override
public void run() {
try {
Thread.sleep(1000);
} catch (InterruptedException e) {
throw new RuntimeException(e);
}
flag = true;
System.out.println("flag 修改完畢!");
}
public boolean isFlag() {
return flag;
}
public void setFlag(boolean flag) {
this.flag = flag;
}
}
實際上是已經修改了的,只是執行緒讀的都是自己的作業記憶體中的資料,然而,要解決這個問題,可以使用synchronized加鎖和volatile修飾共享變數來解決,這兩種都能讓主執行緒拿到子執行緒修改的變數的值,
synchronized (my) {
if (my.isFlag()) System.out.println("進入等待...");
}
加了synchronized鎖,首先該執行緒會獲得鎖物件,接著會去清空作業記憶體,再從主記憶體中copy一份最新的值到作業變數中,接著執行代碼, 列印輸出,最后釋放鎖,
當然還能使用volatile關鍵字去修飾共享變數,一開始子執行緒從主記憶體中獲取變數的副本到自己的作業記憶體,進行改值,此時還未寫回主記憶體,主執行緒從主記憶體獲取的變數的值也是一開始的初始值,等到子執行緒寫回到主記憶體時,接下來其他執行緒的作業記憶體中此變數的副本將會失效,也就是類似于監聽,在需要對此變數進行操作的時候,將會到主記憶體獲取新的值保存到執行緒自身的作業記憶體中,從而確保了資料的一致,
總結
volatile能夠保證不同執行緒對共享變數的可見性,也就是修改過的volatile修飾的共享變數只要被寫回到主記憶體中,其他執行緒就能夠馬上看到最新的資料,
當一個執行緒對volatile修飾的變數進行寫的操作時候,JMM會立即把該執行緒自身的作業記憶體的共享變數重繪到主記憶體中,
當對執行緒進行讀操作的時候,JMM會立即把當前執行緒自身的作業記憶體設定無效,從而從主記憶體中去獲取共享變數的資料,
2、無法保證原子性
原子性指的是一項操作要么都執行,要么都不執行,中途不允許中斷也不受其他執行緒干擾,
舉個例子
我們看以下案例代碼,簡單描述一下,AutoAccretion是一個執行緒類,里面定義了一個共享變數count,并去執行1萬次的自增,在main執行緒中呼叫多執行緒去執行自增,我們所期望的結果是最終count的值是1000000,因為每個執行緒自增1萬次,一共100個執行緒,
public class T3_Volatile01 {
public static void main(String[] args) {
Runnable thread = new AutoAccretion();
for (int i = 1; i <= 100; i++) {
new Thread(thread, "執行緒" + i).start();
}
}
}
class AutoAccretion implements Runnable {
private int count = 0;
@Override
public void run() {
for (int i = 1; i <= 10000; i++) {
count++;
System.out.println(Thread.currentThread().getName() + "count ==> " + count);
}
}
}
分析
count++操作首先會從主記憶體中拷貝變數副本到作業記憶體中,在作業記憶體中進行自增操作,最后將作業記憶體的資料寫回主記憶體中,運行之后會發現,count的值是沒辦法到達1百萬的,主要原因是count++自增操作并不是原子性的,也就是說在進行count++的時候可能被其他執行緒打斷,
當執行緒1拿到count=0,進行自增后count=1,但是還沒寫到主記憶體,執行緒2獲取的資料可能也是count=0,經過自增count=1,兩者在寫回記憶體,就會導致資料的錯誤,
使用volatile對原子性測驗
現在通過volatile去修飾共享變數,運行之后,發現任然沒辦法達到一百萬,
使用鎖的機制
通過使用synchronized鎖對代碼快進行加鎖,從而確保原子性,確保某個執行緒對count進行操作不受其他執行緒的干擾,
class AutoAccretion implements Runnable {
private volatile int count = 0; // 并發下可見性
@Override
public void run() {
synchronized (this) {
for (int i = 1; i <= 10000; i++) {
count++;
System.out.println(Thread.currentThread().getName() + "count ==> " + count);
}
}
}
}
通過驗證可以知道能夠實作原子性,
總結
在多執行緒下,volatile關鍵字可以保證共享變數的可見性,但是不能保證對變數操作的原子性,因此,在多執行緒下即使加了volatile修飾的變數也是執行緒不安全的,要保證原子性就得通過加鎖的機制,
除了這個方法,Java還能用過原子類(java.util.concurrent.atomic包) 來保證原子性,
3、禁止指令重排
什么是指令重排序
指令重排序:為了提高程式性能,編譯器和處理器會對代碼指令的執行順序進行重排序,
良好的記憶體模型實際上會通過軟體和硬體一同盡可能提高執行效率,JMM對底層約束盡量減少,在執行程式時,為了提高性能,編譯器和處理器會對指令進行重排序,
一般重排序有以下三種:
- 編譯器優化的重排序:編譯器在不改變單執行緒程式語意可以對執行順序進行排序,
- 指令集并行的重排序:如果指令不存在相互依賴,那么指令可以改變執行的順序,從而能夠減少load/store操作,
- 記憶體系統的重排序:處理器使用快取和讀/寫快取區,使得加載和存盤操作是亂序執行的,
重排序怎么提高執行速度
在不改變結果的時候,對執行進行重排序,可以提高處理速度,重排序后能夠使處理指令執行的更少,減少指令操作,
重排序的問題所在
由于重排序,直接可能帶來的問題就是導致最終的資料不對,通過以下例子來看,如果執行的順序不同,最終得到的結果是不一樣的,
public class T4_Reordering {
public static int a = 0, b = 0;
public static int i = 0, j = 0;
public static void main(String[] args) throws InterruptedException {
int count = 0;
while (true) {
count++;
// 初始化
a = 0;
b = 0;
i = 0;
j = 0;
Thread one = new Thread(new Runnable() {
@Override
public void run() {
a = 1;
i = b;
}
});
Thread two = new Thread(new Runnable() {
@Override
public void run() {
b = 1;
j = a;
}
});
one.start();
two.start();
one.join(); // 確保執行緒都執行完畢
two.join();
System.out.println("第" + count + "次執行緒執行:i = " + i + ", j = " + j );
if (i == 0 && j == 0) return;
}
}
}
正常當執行緒都執行結束之后,最后得到的值應該是i=1, j=1,通過不斷的回圈執行可以看到,出現的結果會出錯,當先執行了j=a(此時a=0)在執行了a=1,i=b(此時b=0),b=1,最后就會導致i=0,j=0
volatile禁止指令重排序
使用volatile可以實作禁止指令重排序,從而確保并發安全,那么volatile是如何實作禁止指令重排序呢?就是通過使用記憶體屏障(Memory Barrier),
記憶體屏障(Memory Barrier) 作用
- 記憶體屏障****能夠阻止屏障兩側的指令重排序,能夠讓cpu或者編譯器在記憶體上的訪問是有序的,
- 強制把寫緩沖區/高速快取中的臟資料寫回主記憶體,或讓快取相應的資料失效,他是一種cpu指令,用來控制特定情況下的重排序和記憶體可見性問題,
volatile記憶體屏障的插入策略
硬體層的記憶體屏障(Memory Barrier)有Load Barrier 和 Store Barrier即讀屏障和寫屏障,
Java記憶體屏障
- StoreStore屏障:確保在該屏障之后的第一個寫操作之前,屏障前的寫操作對其他處理器可見(重繪到記憶體),
- StoreLoad屏障:確保寫操作對其他處理器可見(重繪到記憶體)之后才能讀取屏障后讀操作的資料到快取,
- LoadLoad屏障:確保在該屏障之后的第一個讀操作之前,一定能先加載屏障前的讀操作對應的資料,
- LoadStore屏障:確保屏障后的第一個寫操作寫出的資料對其他處理器可見之前,屏障前的讀操作讀取的資料一定先讀入快取,
在volatile修飾的變數進行寫操作時候,會使用StoreStore屏障和StoreLoad屏障,進行對volatile變數讀操作會在之后使用LoadLoad屏障和LoadStore屏障,
轉載請註明出處,本文鏈接:https://www.uj5u.com/houduan/544946.html
標籤:其他
