Java進階專題(十一) 探究JMM
前言html
JMM即java內存模型，JMM研究的就是多線程下Java代碼的執行順序，共享變量的讀寫。它定義了Java虛擬機在計算機內存中的工做方式。從抽象角度看，JMM定義了線程和主存之間的抽象關係：線程以前的共享變量存儲在主內存中，每一個線程有個私有的本地內存，本地內存中存儲了該線程讀寫共享變量的副本。本地內存是JMM的一個抽象概念，並不真實存在。它涵蓋了緩存、寫緩衝區、寄存器以及其餘硬件和編譯器優化。java
先拋出兩個問題：node
- 你寫的代碼必定是實際運行的代碼嗎？
- 代碼的編寫順序，必定是實際執行的順序嗎？
參考文獻:c++
Java Language Specification Chapter 17. Threads and Locksgit
JSR-133: JavaTM Memory Model and Thread Specification程序員
Doug Lea' s JSR-133 cookbook算法
書籍：《Java Concurrency in Practice》sql
併發測試框架：jcstressshell
多線程讀寫共享變量
問題演示
猜猜一下代碼在多線程的狀況下，會發生什麼樣的狀況？數組
永遠的循環
boolean stop;
@Actor
public void a1() {
while(!stop){
}
}
@Signal
void a2() {
stop = true;
}
加加減減
int balance = 10;
@Actor
public void deposit() {
balance += 5;
}
@Actor
public void withdraw() {
balance -= 5;
}
@Arbiter
public void query(I_Result r) {
r.r1 = balance;
}
第四種可能
int a;
int b;
@Actor
public void actor1(II_Result r) {
b = 1;
r.r2 = a;
}
@Actor
public void actor2(II_Result r) {
a = 2;
r.r1 = b;
}
問題解密
循環問題-揭祕
爲了方便測試，改造下代碼：
package com.study.demo6;
import java.util.concurrent.TimeUnit;
public class WhileTest {
static boolean stop;
public static void a1() {
while (true) {
boolean b = stop;
if (b) {
break;
}
}
}
public static void main(String[] args) {
new Thread(() -> {
try {
TimeUnit.SECONDS.sleep(1);
} catch (InterruptedException e) {
e.printStackTrace();
}
stop = true;
System.out.println("stop>>>>>>>true!");
}).start();
a1();
}
}
運行結果:
發現main主線程中，調用了啊a1()方法，子線程1秒後，對stop修改了true，按正常邏輯，死循環應該會break終止了，可是實際上運行，咱們發現，一直在循環中，並未終止！
提示：
先用 -XX:+PrintCompilation 來查看即時編譯狀況（% 的含義 On-Stack-Replacement（OSR））
再嘗試用 -Xint 強制解釋執行
加加減減問題-解密
代碼演示
package com.study.demo6;
import java.util.Arrays;
import java.util.List;
public class AddSubTest {
static int balance = 10;
private static void add(){
balance+=5;
}
private static void sub(){
balance-=5;
}
public static void main(String[] args) throws InterruptedException {
List<Thread> threadList = Arrays.asList(new Thread(AddSubTest::add), new Thread(AddSubTest::sub));
threadList.forEach(Thread::start);
for (Thread thread : threadList) {
thread.join();
}
System.out.println(balance);
}
}
這回用一下ASM 工具，能夠看到源碼第10 行的 balance += 5 的字節碼以下
LINENUMBER 8 L0 GETSTATIC TestAddSub.balance : I ICONST_5 IADD PUTSTATIC TestAddSub.balance : I
而第13 行的 balance -= 5 字節碼以下
LINENUMBER 12 L0 GETSTATIC TestAddSub.balance : I ICONST_5 ISUB PUTSTATIC TestAddSub.balance : I
換成僞代後
static int balance = 10;
private static void add(){
//balance+=5;
int b = balance;
b += 5;
balance = b;
}
private static void sub(){
//balance-=5;
int c = balance;
c -= 5;
balance = c;
}
可能出現的執行順序以下:
case1: 線程1和2串行
int b = balance; // 線程1 b += 5; // 線程1 balance = b; // 線程1 int c = balance; // 線程2 c -= 5; // 線程2 balance = c; // 線程2
case2:線程1和線程2同時拿到10,線程1執行完,線程2再執行完
int c = balance; // 線程2 int b = balance; // 線程1 b += 5; // 線程1 balance = b; // 線程1 c -= 5; // 線程2 balance = c; // 線程2
case3:線程1和線程2同時拿到10,線程2執行完,線程1再執行完
int b = balance; // 線程1 int c = balance; // 線程2 c -= 5; // 線程2 balance = c; // 線程2 b += 5; // 線程1 balance = b; // 線程1
第四種可能-揭祕
代碼演示:
package com.study.demo6;
public class FourthResultTest {
int a;
int b;
private void actor1(IIResult r){
b=1;
r.r2 = a;
}
private void actor2(IIResult r){
a=2;
r.r1 = b;
}
}
可能出現的結果
case1:
b = 1; // 線程1 r.r2 = a; // 線程1 a = 2; // 線程2 r.r1 = b; // 線程2 // 結果 r1==1, r2==0
case2:
a = 2; // 線程2 r.r1 = b; // 線程2 b = 1; // 線程1 r.r2 = a; // 線程1 // 結果 r1==0, r2==2
case3:
a = 2; // 線程2 b = 1; // 線程1 r.r2 = a; // 線程1 r.r1 = b; // 線程2 // 結果 r1==1, r2==2
case4:這種結果是否是超乎你的預期了?這是由於多是編譯器調整了指令執行順序
r.r2 = a; // 線程1 a = 2; // 線程2 r.r1 = b; // 線程2 b = 1; // 線程1 // 結果 r1==0, r2==0
思考爲何
-
若是讓一個線程老是佔用CPU 是不合理的，全部任務調度器會讓線程分時使用CPU
-
編譯器以及硬件層面都會作層層優化，提高性能
-
Compiler/JIT 優化
-
Processor 流水線優化
-
Cache 優化
編輯器優化
case1:
//優化前 x=1 y="universe" x=2 //優化後 y="universe" x=2
case2:
//優化前
for(i=0;i<max;i++){
z += a[i]
}
//優化後
t = z
for(i=0;i<max;i++){
t += a[i]
}
z = t
case3:
//優化前
if(x>=0){
y = 1;
// ...
}
//優化後
y = 1;
if(x>=0){
// ...
}
Processor優化
流水線在CPU 的一個時鐘週期內會執行多個指令的不一樣部分
非流水線操做
假設有三條指令
---|---|---| 1 2 3
每條指令執行花費300ps 時間，最後將結果存入寄存器須要20ps
一秒能運行的指令數爲
流水線操做
仔細分析就會發現，能夠把每一個指令細分爲三個階段
A|B|C| // 1 A|B|C| // 2 A|B|C| // 3
增長一些寄存器，緩存每一階段的結果，這樣就能夠在執行 指令1-C 階段時，同時執行 指令2-B 以及 指令3-A
一秒能運行的指令數爲
execute out of order
- 在按序執行中，一旦遇到指令依賴的狀況，流水線就會停滯
- 若是採用亂序執行，就能夠跳到下一個非依賴指令併發布它。這樣，執行單元就能夠老是處於工做狀態，把
時間浪費減到最少
緩存優化
MESI (CPU緩存一致性)協議 引入緩存的反作用在於同一份數據可能保存了副本，一致性該如何保證呢？
- Modified - 要向其它CPU 發送cache line 無效消息，並等待ack
- Exclusive - 獨佔、即將要執行修改
- Shared - 共享、通常讀取時的初始狀態
- Invalid - 一旦發現數據無效，須要從新加載數據
例子
就上文所說的第四種可能:r1 和r2 有沒有可能同時爲0
r.r1 = b; // 線程2 與 a = 2 重排 r.r2 = a; // 線程1 與 a = 1 重排 b = 1; // 線程1 a = 2; // 線程2
下面從緩存的角度分析，注意假定指令沒有重排
b = 1; // 線程1 - 寫入 CPU-0 的 store buffer a = 2; // 線程2 - 寫入 CPU-1 的 store buffer r.r1 = b; // 線程2 - 立刻執行 r.r2 = a; // 線程1 - 立刻執行 // 線程1 - 將 store buffer 中的 b = 1 寫入 cache, 晚了 // 線程2 - 將 store buffer 中的 a = 2 寫入 cache, 晚了
咱們關注問題的點
以上介紹了多線程讀寫共享變量可能發生的哪些問題?但對於程序員而言，咱們不該當關注到底是編譯器優化、Processor 優化、緩存優化。不然，就好像打開了潘多拉魔盒！
JMM內存模型
什麼是JMM
A memory model describes, given a program and an execution trace of that program, whether the execution trace is a legal execution of the program. A high level, informal overview of the memory model shows it to be a set of rules for when writes by one thread are visible to another thread.
多線程下，共享變量的讀寫順序是頭等大事，內存模型就是多線程下對共享變量的一組讀寫規則
- 共享變量值是否在線程間同步
- 代碼可能的執行順序
- 須要關注的操做就有兩種Load、Store
- Load 就是從緩存讀取到寄存器中，若是一級緩存中沒有，就會層層讀取二級、三級緩存，最後纔是Memory
- Store 就是從寄存器運算結果寫入緩存，不會直接寫入Memory，當Cache line 將被eject 時，會
writeback 到Memory
JMM規範
規則一 Race Condition
在多線程下，沒有關係依賴的代碼，在操做共享變量時（至少有一個線程寫），並不能保證按編寫順序（Program Order）執行，這稱爲發生了競態條件（Race Conditon）。
例如
有共享變量 x，線程 1 執行
r.r1 = y; r.r2 = x;
線程 2 執行
x = 1; y = 1;
最終的結果多是 r11 而 r20
競態條件是爲了更好的 data race free。
規則二 Syncronization Order
若要保證多線程下，每一個線程的執行順序（Synchronization Order）按編寫順序（Program Order）執行，那麼必須使用 Synchronization Actions 來保證，這些 SA 有
-
lock，unlock
-
volatile 方式讀寫變量
-
VarHandle 方式讀寫變量
Synchronization Order 也稱之爲 Total Order
例如
用 volatile 修飾共享變量 y，線程 1 執行
r.r1 = y; r.r2 = x;
線程 2 執行
x = 1; y = 1;
最終的結果就不可能是 r11 而 r20
SO並非阻止多線程切換
錯誤的認識，線程 1 執行
synchronized(LOCK) {
r1 = x; //1 處
r2 = x; //2 處
}
線程 2 執行
synchronized(LOCK) {
x = 1
}
並非說 //1 與 //2 處之間不能切換到線程 2，只是即便切換到了線程 2，由於線程 2 不能拿到 LOCK 鎖致使被阻塞，執行權又會輪到線程 1
volatile 只用了一半算 SO 嗎?
用例1
int x; volatile int y;
以後採用
x = 10; //1 處 y = 20; //2 處
此時 //1 處代碼毫不會重排到 //2 處以後（只寫了 volatile 變量）
用例 2
int x; volatile int y;
執行下面的測試用例
@Actor
public void a1(II_Result r) {
y = 1; //1 處
r.r2 = x; //2 處
}
@Actor
public void a2(II_Result r) {
x = 1; //3 處
r.r1 = y; //4 處
}
//1 //2 處的順序能夠保證（只寫了 volatile 變量），但 //3 //4 處的順序卻不能保證（只讀了 volatile 變量），仍會出現 r1r20 的問題
有時會很迷惑人，例以下面的例子
用例3
@Actor
public void a1(II_Result r) {
r.r2 = x; //1 處
y = 1; //2 處
}
@Actor
public void a2(II_Result r) {
r.r1 = y; //3 處
x = 1; //4 處
}
這回 //1 //2 （只寫了 volatile 變量）//3 //4 處（只讀了 volatile 變量）的順序均能保證了，毫不會出現r1r21 的狀況
此外將用例 2 中兩個變量均用 volatile 修飾就不會出現 r1r20 的問題，所以也把所有都用 volatile 修飾稱爲total order，部分變量用 volatile 修飾稱爲 partial order
規則三 Happens Before
如果變量讀寫時發生線程切換（例如，線程 1 寫入 x，切換至線程 2，線程 2 讀取 x）在這些邊界的處理上若是有action1 先於 action 2 發生，那麼代碼能夠按肯定的順序執行，這稱之爲 Happens-Before Order 規則(Happens-Before Order 也稱之爲 Partial Order).
用公式表達就是：
含義爲：若是 action1 先於 action2 發生，那麼 action1 以前的共享變量的修改對於 action2 可見，且代碼按 PO順序執行
具體規則
其中 $T_{n}$ 表明線程，而 x 未加說明，是普通共享變量，使用 volatile 會單獨說明
1）線程的啓動和運行邊界
2）線程的結束和join邊界
3）線程的打斷和得知打斷的邊界
4）unlock 與 lock 邊界
5）volatile write 與 volatile read 邊界
6）傳遞性
規則四 Causality
Causality 即因果律：代碼之間如存在依賴關係，即便沒有加 SA 操做，代碼的執行順序也是能夠預見的
回顧一下
多線程下，沒有依賴關係的代碼，在共享變量讀寫操做（至少有一個線程寫）時，並不能保證以編寫順序（Program Order）執行，這稱爲發生了競態條件（Race Condition）
若是有必定的依賴關係呢？
@JCStressTest
@Outcome(id = {"0", "0"}, expect = Expect.ACCEPTABLE, desc = "ACCEPTABLE")
@Outcome(expect = Expect.FORBIDDEN, desc = "FORBIDDEN")
@State
public class Case {
int x;
int y;
@Actor
public void a1(IIResult r) {
r.r1 = x;
y = r.r1;
}
@Actor
public void a2(IIResult r){
r.r2 = y;
x = r.r2;
}
}
x 的值來自於 y，y 的值來自於 x，而兩者的初始值都是 0，所以沒有可能有其餘結果
規則五安全發佈
若要安全構造對象，並將其共享使用，須要用 final 或 volatile 修飾其成員變量，並避免 this 溢出狀況(靜態成員變量能夠安全地發佈)
例如
class Holder{
int x1;
volatile int x2;
public Holder(int x) {
x1=x;
x2=x;
}
}
須要將它做爲全局使用
Holder f;
兩個線程，一個建立，一個使用
Holder holder;
@Actor
public void a1(){
holder = new Holder(1);
}
@Actor
public void a2(IIResult r){
Holder holder = this.holder;
if (holder != null){
r.r1 = holder.x1 +holder.x2;
}else {
r.r1 = -1;
}
}
可能看見未構造完整的對象
同步動做
前面沒有詳細展開從規則 2 以後的講解，是由於要理解規則，還需理解底層原理，即內存屏障
內存屏障
LoadLoad
-
防止 y 的 Load 重排到 x 的 Load 以前
if(x) { LoadLoad return y } -
意義：x == true 時，再去獲取 y，不然可能會因爲重排致使 y 的值相對於 x 是過時的
LoadStore
- 防止 y 的 Store 被重排到 x 的 Load 以前
StoreSotre
-
防止 A 的 Store 被重排到 B 的 Store 以後
A = x StoreStore B = true
-
意義：在 B 修改成 true 以前，其它線程別想看到 A 的修改
- 有點相似於 sql 中更新後，commit 以前，其它事務不能看到這些更新（B 的賦值會觸發 commit 並撤除屏障）
StoreLoad
- 意義：屏障前的改動都同步到主存 ，屏障後的 Load 獲取主存最新數據，發生在線程切換時，而且使得藍色線程全部的寫操做寫入主存，使得紅色線程能讀取到最新數據
- 防止屏障前全部的寫操做，被重排序到屏障後的任何的讀操做，能夠認爲此 store -> load 是連續的
- 有點相似於 git 中先 commit，再遠程 poll，並且這個動做是原子的
如何記憶
- LoadLoad + LoadStore = Acquire 即讓同一線程內讀操做以後的讀寫上不去，第一個 Load 能讀到主存最新值
- LoadStore + StoreStore = Release 即讓同一線程內寫操做以前的讀寫下不來，後一個 Store 能將改動都寫入主存
- StoreLoad 最爲特殊，還能用在線程切換時，對變量的寫操做 + 讀操做作同步，只要是對同一變量先寫後讀，那麼屏障就能生效
Volatile
本質
事實上對 volatile 而言 Store-Load 屏障最爲有用，簡化起見之後的分析省略部分其餘屏障
做用
- 保證單一變量的原子性
- 控制了可能的執行路徑： 線程內按屏障有序，線程切換時按HB有序
- 可見性：線程切換時若發生了讀寫則變量可見，順帶影響普通變量可見
volatile的用途
凡是須要cas操做的地方
好比AtomicInteger的源碼
public class AtomicInteger extends Number implements java.io.Serializable {
private static final Unsafe U = Unsafe.getUnsafe();
private static final long VALUE = U.objectFieldOffset(AtomicInteger.class, "value");
private volatile int value;
// ...
public final boolean compareAndSet(int expectedVal, int newVal) {
return U.compareAndSetInt(this, VALUE, expectedVal, newVal);
}
// ...
}
AbstractQueuedSynchronizer的源碼
public abstract class AbstractQueuedSynchronizer extends AbstractOwnableSynchronizer implements java.io.Serializable {
private transient volatile Node head;
private transient volatile Node tail;
private volatile int state;
protected final int getState() {
return state;
}
protected final boolean compareAndSetState(int e, int n) {
return U.compareAndSetInt(this, STATE, e, n);
}
final void enqueue(Node node) {
if (node != null) {
for (; ; ) {
Node t = tail;
node.setPrevRelaxed(t);
if (t == null) tryInitializeHead();
else if (casTail(t, node)) {
t.next = node;
if (t.status < 0) LockSupport.unpark(node.waiter);
break;
}
}
}
}
private void tryInitializeHead() {
Node h = new ExclusiveNode(); // 頭
if (U.compareAndSetReference(this, HEAD, null, h)) tail = h;
}
private boolean casTail(Node c, Node v) {
return U.compareAndSetReference(this, TAIL, c, v);
}
}
ConcurrentHashMap源碼
public class ConcurrentHashMap<K, V> extends AbstractMap<K, V> implements ConcurrentMap<K, V>, Serializable {
/**
* Table initialization and resizing control. When negative, the
* table is being initialized or resized: -1 for initialization,
* else -(1 + the number of active resizing threads). Otherwise,
* when table is null, holds the initial table size to use upon
* reation, or 0 for default. After initialization, holds the
* next element count value upon which to resize the table.
*/
private transient volatile int sizeCtl;
/**
* The array of bins. Lazily initialized upon first insertion.
* Size is always a power of two. Accessed directly by iterators.
*/
transient volatile Node<K, V>[] table;
private final Node<K, V>[] initTable() {
Node<K, V>[] tab;
int sc;
while ((tab = table) == null || tab.length == 0) {
if ((sc = sizeCtl) < 0) Thread.yield();
else if (U.compareAndSetInt(this, SIZECTL, sc, -1)) {
try {
if ((tab = table) == null || tab.length == 0) {
int n = (sc > 0) ? sc : DEFAULT_CAPACITY;
Node<K, V>[] nt = (Node<K, V>[]) new Node<?, ?>[n];
table = tab = nt;
sc = n - (n >>> 2);
}
} finally {
sizeCtl = sc;
}
break;
}
}
return tab;
}
// ...
}
volatile負責保證可見性，cas來保證原子
Synchronized
本質
起始synchronized本質就是通兩個JVM指令：monitorenter和monitorexit來實現了，咱們能夠經過下面一段代碼的來研究下，其原理
package com;
public class SynchronizedTest {
static int i = 0;
public static void main(String[] args) {
synchronized (SynchronizedTest.class){
i++;
}
}
}
經過反編譯看下
#......
public static void main(java.lang.String[]);
descriptor: ([Ljava/lang/String;)V
flags: ACC_PUBLIC, ACC_STATIC
Code:
stack=2, locals=3, args_size=1
0: ldc #2 // class com/SynchronizedTest
2: dup
3: astore_1
4: monitorenter
5: getstatic #3 // Field i:I
8: iconst_1
9: iadd
10: putstatic #3 // Field i:I
13: aload_1
14: monitorexit
15: goto 23
18: astore_2
19: aload_1
20: monitorexit
21: aload_2
22: athrow
23: return
#......
能夠看到就是經過jvm指令monitorenter、monitorexit實現的，結合上圖，具體步驟以下：
咱們知道synchronized是通加對象鎖來實現的，可是這個對象是否做爲鎖而存在呢？
- 當線程1執行synchronized時，jvm調用monitorenter時，就會先操做系統申請一個操做系統的Moniter鎖（底層由c++實現的），並把其地址存放在LOCK對象頭中。
- 當線程1根據LOCK對象頭找到Moniter鎖，判斷owner是否被佔用，沒有被佔用，就會修改其值，等於持有了鎖。
- 大概線程2一樣會執行monitorenter指令，根據LOCK對象頭找到Moniter鎖，判斷owner是否被佔用，發現已經被佔用，首先會自旋嘗試獲取，必定次數沒獲取到，就會進入EntryList隊列等待，並從運行狀態變成阻塞狀態，線程3也是如此。
- 當線程1執行完畢或出現異常時就會執行monitorexit，釋放owner並喚醒EntryList中的被阻塞線程，具體都隊列頭仍是隊列尾部去喚醒，這個根據具體算法實現，這裏不作贅述。
- 假如線程2被喚醒就會去獲取owner是否空閒，空閒了就佔用，線程3依然處於阻塞狀態。
相關內存屏障
優化（JDK1.6以後）
- 重量級
- 當有競爭時，仍會向系統申請 Monitor 互斥鎖
- 輕量級鎖
- 若是線程加鎖、解鎖時間上恰好是錯開的，這時候就可使用輕量級鎖，只是使用 cas 嘗試將對象頭替換爲該線程的鎖記錄地址，若是 cas 失敗，會鎖重入或觸發重量級鎖升級
- 偏向鎖
- 打個比方，輕量級鎖就比如用課本佔座，線程每次佔座前還得比較一下，課本是否是本身的（cas），頻繁 cas 性能也會受到影響
- 而偏向鎖就比如座位上已經刻好了線程的名字，線程【專用】這個座位，比 cas 更爲輕量
- 可是一旦其餘線程訪問偏向對象，那麼比較麻煩，須要把座位上的名字擦去，這稱之爲偏向鎖撤銷，鎖也升級爲輕量級鎖
- 偏向鎖撤銷也屬於昂貴的操做，怎麼減小呢，JVM 會記錄這一類對象被撤銷的次數，若是超過了 20 這個閾值，下次新線程訪問偏向對象時，就不用撤銷了，而是刻上新線程的名字，這稱爲重偏向
- 若是撤銷次數進一步增長，超過 40 這個閾值，JVM 會認爲這一類對象不適合採用偏向鎖，會對它們禁用偏向鎖，下次新建對象會直接加輕量級鎖
無鎖與有鎖
-
synchronized 更爲重量，申請鎖、鎖重入都要發起系統調用，頻繁調用性能會受影響
-
synchronized 若是沒法獲取鎖時，線程會陷入阻塞，引發的線程上下文切換成本高
-
雖然作了一系列優化，但輕量級鎖、偏向鎖都是針對無數據競爭場景的
-
若是數據的原子操做時間較長，仍應該讓線程阻塞，無鎖適合的是短頻快的共享數據修改操做主要用於計數器、中止標記、或是阻塞前的有限嘗試
VarHandle
目前無鎖問題實現
目前Java 中的無鎖技術主要體如今以AtomicInteger 爲表明的的原子操做類，它的底層使用Unsafe 實現，而Unsafe 的問題在於安全性和可移植性
此外，volatile 主要使用了Store-Load 屏障來控制順序，這個屏障仍是太強了，有沒有更輕量級的解決方法呢？
Varhandle快速上手
在Java9 中引入了VarHandle，來提供更細粒度的內存屏障，保證共享變量讀寫可見性、有序性、原子性。提供了更好的安全性和可移植性，替代Unsafe 的部分功能
建立
public class TestVarHandle {
int x;
static VarHandle X;
static {
try {
X = MethodHandles.lookup()
.findVarHandle(TestVarHandle.class, "x", int.class);
} catch (NoSuchFieldException | IllegalAccessException e) {
e.printStackTrace();
}
}
}
讀寫
| 方法名 | 做用 | 說明 |
|---|---|---|
| get | 獲取值 | 與普通變量取值同樣，會重排、有不可見現象 |
| set | 設置值 | |
| getOpaque | 獲取值 | 對其保護的變量，保證其不重排和可見性，但不使用屏障，不阻礙其它變量 |
| setOpaque | 設置值 | |
| getAcquire | 獲取值 | 至關於get 以後加LoadLoad + LoadStore |
| setRelease | 設置值 | 至關於set 以前加LoadStore + StoreStore |
| getVolatile | 獲取值 | 語義同volatile，至關於獲取以後加LoadLoad + LoadStore |
| setVolatile | 設置值 | 語義同volatile，至關於設置以前加LoadStore + StoreStore，設置以後加StoreLoad |
| compareAndSet | 原子賦值 | 原子賦值，成功返回true，失敗返回false |
更多安全問題
單個變量讀寫原子性
-
64 位系統vs 32 位系統
若是須要保證long 和double 在32 位系統中原子性，須要用volatile 修飾 -
JMM9 以前
JMM9 32 位系統下double 和long 的問題，double 沒有問題，long 在-server -XX:+UnlockExperimentalVMOptions -XX:-AlwaysAtomicAccesses 纔有問題
Object alignment
你或許據說過對象對齊，它的一個主要目的就是爲了單個變量讀寫的原子性，可使用jol 工具查看java 對象的內存佈局
<dependency> <groupId>org.openjdk.jol</groupId> <artifactId>jol-core</artifactId> <version>0.10</version> </dependency>
測試類
public class TestJol {
public static void main(String[] args) {
String layout = ClassLayout.parseClass(Test.class).toPrintable();
System.out.println(layout);
}
public static class Test {
private byte a;
private byte b;
private byte c;
private long e;
}
}
開啓對象頭壓縮（默認）輸出
com.itheima.test.TestJol$Test object internals: OFFSET SIZE TYPE DESCRIPTION VALUE 0 12 (object header) N/A 12 1 byte Test.a N/A 13 1 byte Test.b N/A 14 1 byte Test.c N/A 15 1 (alignment/padding gap) 16 8 long Test.e N/A Instance size: 24 bytes Space losses: 1 bytes internal + 0 bytes external = 1 bytes total
不開啓對象頭壓縮 -XX:-UseCompressedOops 輸出
com.itheima.test.TestJol$Test object internals: OFFSET SIZE TYPE DESCRIPTION VALUE 0 16 (object header) N/A 16 8 long Test.e N/A 24 1 byte Test.a N/A 25 1 byte Test.b N/A 26 1 byte Test.c N/A 27 5 (loss due to the next object alignment) Instance size: 32 bytes Space losses: 0 bytes internal + 5 bytes external = 5 bytes total
字分裂
前面也看到了，Java 可以保證單個共享變量讀寫是原子的，相似的數組元素的讀寫，也會提供這樣的保證
byte[8] [0][1][2][3] [0][1][2][3]
若是上述效果不能保證，則稱之爲發生了字分裂現象，java 中沒有字分裂，但Java 中某些實現會有相似字分裂現象，例如BitSet、Unsafe 讀寫等
數組元素讀寫測試
@JCStressTest
@Outcome(id = {"0", "-1"}, expect = Expect.ACCEPTABLE, desc = "ACCEPTABLE")
@Outcome(expect = Expect.FORBIDDEN, desc = "FORBIDDEN")
@State
public static class Case4 {
byte[] b = new byte[256];
int off = ThreadLocalRandom.current().nextInt(256);
@Actor
public void actor1() {
b[off] = (byte) 0xFF;
}
@Actor
public void actor2(I_Result r) {
r.r1 = b[off];
}
}
BigSet讀寫測試
@JCStressTest
@Outcome(id = "true, true", expect = Expect.ACCEPTABLE, desc = "ACCEPTABLE")
@Outcome(expect = Expect.ACCEPTABLE_INTERESTING, desc = "INTERESTING")
@State
public static class Case6 {
BitSet b = new BitSet();
@Actor
public void a() {
b.set(0);
}
@Actor
public void b() {
b.set(1);
}
@Arbiter
public void c(ZZ_Result r) {
r.r1 = b.get(0);
r.r2 = b.get(1);
}
}
Unsafe 直接操做內存
public class TestUnsafe {
public static final long ARRAY_BASE_OFFSET =
UnsafeHolder.U.arrayBaseOffset(byte[].class);
static byte[] ss = new byte[8];
public static void main(String[] args) {
System.out.println(ARRAY_BASE_OFFSET);
UnsafeHolder.U.putInt(ss, ARRAY_BASE_OFFSET, 0xFFFFFFFF);
System.out.println(Arrays.toString(ss));
}
}
輸出
16 [-1, -1, -1, -1, 0, 0, 0, 0]
來個壓測
@JCStressTest
@Outcome(id = "0", expect = Expect.ACCEPTABLE, desc = "ACCEPTABLE")
@Outcome(id = "-1", expect = Expect.ACCEPTABLE, desc = "ACCEPTABLE")
@Outcome(expect = Expect.ACCEPTABLE_INTERESTING, desc = "INTERESTING")
@State
public static class Case5 {
byte[] ss = new byte[256];
long base = UnsafeHolder.U.arrayBaseOffset(byte[].class);
long off = base + ThreadLocalRandom.current().nextInt(256 - 4);
@Actor
public void writer() {
UnsafeHolder.U.putInt(ss, off, 0xFFFF_FFFF);
}
@Actor
public void reader(I_Result r) {
r.r1 = UnsafeHolder.U.getInt(ss, off);
}
}
結果:
Observed state Occurrences Expectation Interpretation -1 25,591,098 ACCEPTABLE ACCEPTABLE -16777216 877 ACCEPTABLE_INTERESTING INTERESTING -256 923 ACCEPTABLE_INTERESTING INTERESTING -65536 925 ACCEPTABLE_INTERESTING INTERESTING 0 5,093,890 ACCEPTABLE ACCEPTABLE 16777215 1,673 ACCEPTABLE_INTERESTING INTERESTING 255 1,758 ACCEPTABLE_INTERESTING INTERESTING 65535 1,707 ACCEPTABLE_INTERESTING INTERESTING
安全發佈
構造也不安全
@JCStressTest
@Outcome(id = {"16", "-1"}, expect = Expect.ACCEPTABLE, desc = "ACCEPTABLE")
@Outcome(expect = Expect.ACCEPTABLE_INTERESTING, desc = "INTERESTING")
@State
public static class Case1 {
Holder f;
int v = 1;
@Actor
public void a1() {
f = new Holder(v);
}
@Actor
void a2(I_Result r) {
Holder o = this.f;
if (o != null) {
r.r1 = o.x8 + o.x7 + o.x6 + o.x5 + o.x4 + o.x3 + o.x2 + o.x1;
r.r1 += o.y8 + o.y7 + o.y6 + o.y5 + o.y4 + o.y3 + o.y2 + o.y1;
} else {
r.r1 = -1;
}
}
static class Holder {
int x1, x2, x3, x4;
int x5, x6, x7, x8;
int y1, y2, y3, y4;
int y5, y6, y7, y8;
public Holder(int v) {
x1 = v;
x2 = v;
x3 = v;
x4 = v;
x5 = v;
x6 = v;
x7 = v;
x8 = v;
y1 = v;
y2 = v;
y3 = v;
y4 = v;
y5 = v;
y6 = v;
y7 = v;
y8 = v;
}
}
}
緣由分析
好比有個Student類代碼以下:
public class Student{
final String name;
int age;
public Student(name,age){
this.name =name;
this.age = age;
}
}
Student stu爲共享變量
stu = new Student("zhangsan",18);
name若是沒有final修飾
t =new Student(name,age) stu = t this.name = name this.age =age
name若是有final修飾,位置任意
t=new Student(name,age) this.name=name this.age=age >----StoreStore----< stu = t
使用volatile改進
name 有volatile 修飾，注意位置必須在最後
t=new Student(name,age) this.age=age this.name=name >----Store Load----< stu =t
總結
- JMM 是研究的是
- 多線程下Java 代碼的執行順序，實際代碼的執行順序與你編寫的代碼順序不一樣
- 共享變量的讀寫操做，在競態條件下，須要考慮共享變量讀寫的原子性、可見性、有序性
- 共享變量的問題原由
- 原子性是因爲操做系統的分時機制，線程切換所致
- 有序性和可見性可能來自於編譯器優化、處理器優化、緩存優化
- JMM 制定了一些規則，理解這些規則，才能寫出正確的線程安全代碼
- 競態條件會致使代碼順序被重排
- 利用synchronized、volatile 一些SA，能夠控制線程內代碼的執行順序
- 線程切換時的執行順序與可見性，遵照HB 規則
- HB 規則還不足夠，須要因果律做爲補充
- 能夠經過final 或volatile 實現對象的安全發佈
- 從底層理解volatile 與synchronized
- 內存屏障
- synchronized 是如何解決原子性、可見性、有序性問題的，有哪些優化
- volatile 是如何解決可見性、有序性問題的，與cas 結合的威力
- VarHandle 是如何解決可見性、有序性問題的
- 更多安全問題
- 單個變量、數組元素的讀寫原子性
- 可以列舉字分裂的幾個相關例子
- 構造方法什麼狀況下會線程不安全，如何改進
- 完全掌握DCL 安全單例
- 1. Java進階(5) - 併發(JMM)
- 2. 大型Java進階專題(一) 前言
- 3. Java進階專題(十九) 消息中間件架構體系（1）-- ActiveMQ研究
- 4. Java進階專題(二十) 消息中間件架構體系（2）-- RabbitMQ研究
- 5. Java進階專題(二十六) 數據庫原理研究與優化
- 6. Java進階專題(十七) 系統緩存架構設計 (上)
- 7. Java進階專題(十八) 系統緩存架構設計 (下)
- 8. 專題1-3-java內存模型JMM
- 9. Java內存模型（JMM Java Memory Model）探究
- 10. Dagger2進階-Scope的源碼探究
- 更多相關文章...
- • Scala 高階函數 - Scala教程
- • Markdown 標題 - Markdown 教程
- • 爲了進字節跳動，我精選了29道Java經典算法題，帶詳細講解
- • Java Agent入門實戰（一）-Instrumentation介紹與使用
-
每一个你不满意的现在，都有一个你没有努力的曾经。