可見性

如果一個(gè)線程對(duì)共享變量值的修改, 能夠及時(shí)的被其他線程看到, 叫做共享變量的可見性.

Java 虛擬機(jī)規(guī)范試圖定義一種 Java 內(nèi)存模型 (JMM), 來屏蔽掉各種硬件和操作系統(tǒng)的內(nèi)存訪問差異, 讓 Java 程序在各種平臺(tái)上都能達(dá)到一致的內(nèi)存訪問效果.

簡單來說, 由于 CPU 執(zhí)行指令的速度是很快的, 但是內(nèi)存訪問的速度就慢了很多, 相差的不是一個(gè)數(shù)量級(jí), 所以搞處理器的那群大佬們又在 CPU 里加了好幾層高速緩存.

在 Java 內(nèi)存模型里, 對(duì)上述的優(yōu)化又進(jìn)行了一波抽象. JMM 規(guī)定所有變量都是存在主存中的, 類似于上面提到的普通內(nèi)存, 每個(gè)線程又包含自己的工作內(nèi)存, 方便理解就可以看成 CPU 上的寄存器或者高速緩存.

所以線程的操作都是以工作內(nèi)存為主, 它們只能訪問自己的工作內(nèi)存, 且工作前后都要把值在同步回主內(nèi)存.

簡單點(diǎn)就是, 多線程中讀取或修改共享變量時(shí), 首先會(huì)讀取這個(gè)變量到自己的工作內(nèi)存中成為一個(gè)副本, 對(duì)這個(gè)副本進(jìn)行改動(dòng)后, 再更新回主內(nèi)存中.

使用工作內(nèi)存和主存, 雖然加快的速度, 但是也帶來了一些問題. 比如看下面一個(gè)例子:

i = i + 1;

假設(shè) i 初值為 0, 當(dāng)只有一個(gè)線程執(zhí)行它時(shí), 結(jié)果肯定得到 1, 當(dāng)兩個(gè)線程執(zhí)行時(shí), 會(huì)得到結(jié)果 2 嗎? 這倒不一定了. 可能存在這種情況:

線程1： load i from 主存  // i = 0
    i + 1 // i = 1
線程2： load i from主存 // 因?yàn)榫€程1還沒將i的值寫回主內(nèi)存，所以i還是0
    i + 1 //i = 1
線程1: save i to 主存
線程2： save i to 主存

如果兩個(gè)線程按照上面的執(zhí)行流程, 那么 i 最后的值居然是 1 了. 如果最后的寫回生效的慢, 你再讀取 i 的值, 都可能是 0, 這就是緩存不一致問題.

這種情況一般稱為 失效數(shù)據(jù), 因?yàn)榫€程1 還沒將 i 的值寫回主內(nèi)存, 所以 i 還是 0, 在線程2 中讀到的就是 i 的失效值(舊值).

也可以理解成, 在操作完成之后將工作內(nèi)存中的副本回寫到主內(nèi)存, 并且在其它線程從主內(nèi)存將變量同步回自己的工作內(nèi)存之前, 共享變量的改變對(duì)其是不可見的.

有序性

有序性: 即程序執(zhí)行的順序按照代碼的先后順序執(zhí)行. 舉個(gè)簡單的例子, 看下面這段代碼:

int i = 0;       
boolean flag = false;
i = 1;        //語句1 
flag = true;     //語句2

上面代碼定義了一個(gè) int 型變量, 定義了一個(gè) boolean 類型變量, 然后分別對(duì)兩個(gè)變量進(jìn)行賦值操作.

從代碼順序上看, 語句1 是在語句2 前面的, 那么 JVM 在真正執(zhí)行這段代碼的時(shí)候會(huì)保證語句1 一定會(huì)在語句2 前面執(zhí)行嗎？ 不一定, 為什么呢？ 這里可能會(huì)發(fā)生指令重排序.

重排序

指令重排是指 JVM 在編譯 Java 代碼的時(shí)候, 或者 CPU 在執(zhí)行 JVM 字節(jié)碼的時(shí)候, 對(duì)現(xiàn)有的指令順序進(jìn)行重新排序.

它不保證程序中各個(gè)語句的執(zhí)行先后順序同代碼中的順序一致, 但是它會(huì)保證程序最終執(zhí)行結(jié)果和代碼順序執(zhí)行的結(jié)果是一致的(指的是不改變單線程下的程序執(zhí)行結(jié)果).

雖然處理器會(huì)對(duì)指令進(jìn)行重排序, 但是它會(huì)保證程序最終結(jié)果會(huì)和代碼順序執(zhí)行結(jié)果相同, 那么它靠什么保證的呢？ 再看下面一個(gè)例子:

int a = 10;  //語句1
int r = 2;  //語句2
a = a + 3;  //語句3
r = a*a;   //語句4

這段代碼有 4 個(gè)語句, 那么可能的一個(gè)執(zhí)行順序是:

那么可不可能是這個(gè)執(zhí)行順序呢?

語句2 語句1 語句4 語句3.

不可能, 因?yàn)樘幚砥髟谶M(jìn)行重排序時(shí)是會(huì)考慮指令之間的數(shù)據(jù)依賴性, 如果一個(gè)指令 Instruction 2 必須用到 Instruction 1 的結(jié)果, 那么處理器會(huì)保證 Instruction 1 會(huì)在 Instruction 2 之前執(zhí)行.

雖然重排序不會(huì)影響單個(gè)線程內(nèi)程序執(zhí)行的結(jié)果, 但是多線程呢? 下面看一個(gè)例子:

//線程1:
context = loadContext();  //語句1
inited = true;       //語句2
 
//線程2:
while(!inited ){
 sleep()
}
doSomethingwithconfig(context);

上面代碼中, 由于語句1 和語句2 沒有數(shù)據(jù)依賴性, 因此可能會(huì)被重排序.

假如發(fā)生了重排序, 在線程1 執(zhí)行過程中先執(zhí)行語句2, 而此時(shí)線程2 會(huì)以為初始化工作已經(jīng)完成, 那么就會(huì)跳出 while 循環(huán), 去執(zhí)行 doSomethingwithconfig(context) 方法, 而此時(shí) context 并沒有被初始化, 就會(huì)導(dǎo)致程序出錯(cuò).

從上面可以看出, 指令重排序不會(huì)影響單個(gè)線程的執(zhí)行, 但是會(huì)影響到線程并發(fā)執(zhí)行的正確性.

原子性

Java 中, 對(duì)基本數(shù)據(jù)類型的讀取和賦值操作是原子性操作, 所謂原子性操作就是指這些操作是不可中斷的, 要做一定做完, 要么就沒有執(zhí)行.

JMM 只實(shí)現(xiàn)了基本的原子性, 像 i++ 的操作, 必須借助于 synchronized 和 Lock 來保證整塊代碼的原子性了. 線程在釋放鎖之前, 必然會(huì)把 i 的值刷回到主存的.

重點(diǎn), 要想并發(fā)程序正確地執(zhí)行, 必須要保證原子性、可見性以及有序性. 只要有一個(gè)沒有被保證, 就有可能會(huì)導(dǎo)致程序運(yùn)行不正確.

volatile 關(guān)鍵字

volatile 關(guān)鍵字的兩層語義

一旦一個(gè)共享變量 (類的成員變量、類的靜態(tài)成員變量) 被 volatile 修飾之后, 那么就具備了兩層語義:

1) 禁止進(jìn)行指令重排序.

2) 讀寫一個(gè)變量時(shí), 都是直接操作主內(nèi)存.

在一個(gè)變量被 volatile 修飾后, JVM 會(huì)為我們做兩件事:

1.在每個(gè) volatile 寫操作前插入 StoreStore 屏障, 在寫操作后插入 StoreLoad 屏障.

2.在每個(gè) volatile 讀操作前插入 LoadLoad 屏障, 在讀操作后插入 LoadStore 屏障.

或許這樣說有些抽象, 我們看一看剛才線程A代碼的例子:

boolean contextReady = false;

//在線程A中執(zhí)行:
context = loadContext();
contextReady = true;

我們給 contextReady 增加 volatile 修飾符, 會(huì)帶來什么效果呢?

由于加入了 StoreStore 屏障, 屏障上方的普通寫入語句 context = loadContext() 和屏障下方的 volatile 寫入語句 contextReady = true 無法交換順序, 從而成功阻止了指令重排序.

也就是說, 當(dāng)程序執(zhí)行到 volatile 變量的讀或?qū)懖僮鲿r(shí), 在其前面的操作的更改肯定全部已經(jīng)進(jìn)行, 且結(jié)果已經(jīng)對(duì)后面的操作可見.

volatile特性之一:
保證變量在線程之間的可見性. 可見性的保證是基于 CPU 的內(nèi)存屏障指令, 被 JSR-133 抽象為 happens-before 原則.

volatile特性之二:
阻止編譯時(shí)和運(yùn)行時(shí)的指令重排. 編譯時(shí) JVM 編譯器遵循內(nèi)存屏障的約束, 運(yùn)行時(shí)依靠 CPU 屏障指令來阻止重排.

volatile 除了保證可見性和有序性, 還解決了 long 類型和 double 類型數(shù)據(jù)的 8 字節(jié)賦值問題.
虛擬機(jī)規(guī)范中允許對(duì) 64 位數(shù)據(jù)類型, 分為 2 次 32 位的操作來處理, 當(dāng)讀取一個(gè)非 volatile 類型的 long 變量時(shí), 如果對(duì)該變量的讀操作和寫操作不在同一個(gè)線程中執(zhí)行, 那么很有可能會(huì)讀取到某個(gè)值得高 32 位和另一個(gè)值得低 32 位.

以上就是本文的全部內(nèi)容，希望對(duì)大家的學(xué)習(xí)有所幫助，也希望大家多多支持腳本之家。