所有的編程語言中都有記憶體模型這個概念，區別于微架構的記憶體模型，高級語言的記憶體模型包括了編譯器和微架構兩部分，我試圖了解了Java、C#和Go語言的記憶體模型，發現內容基本大同小異，只是這些語言在具體實作的時候略有不同，
我們來看看Java記憶體模型吧，提到Java記憶體模型大家對這個圖一定非常熟悉：
這張圖告訴我們在執行緒運行的時候有一個記憶體專用的一小塊記憶體，當Java程式會將變數同步到執行緒所在的記憶體，這時候會操作作業記憶體中的變數，而執行緒中變數的值何時同步回主記憶體是不可預期的，但同時Java記憶體模型又告訴我們通過使用關鍵詞“synchronized”或“volatile”可以讓Java保證某些約束：
“volatile” — 保證讀寫的都是主記憶體的變數
“synchronized” —保證在塊開始時都同步主記憶體的值到作業記憶體，而塊結束時將變數同步回主記憶體
通過以上描述我們就可以寫出執行緒安全的Java程式，JDK也同時幫我們屏蔽了很多底層的東西，
但當你深入了解JVM的時候你會發現根本就沒有作業記憶體這個東西，即記憶體中根本不會分配這么一塊空間來運行你的Java程式，那么作業記憶體到底是什么東西呢？
這個問題也曾經困擾了我很長時間，因為我從來沒有從JVM的實作中找到過和主記憶體同步的代碼，因為當使用“volatile”時我僅僅能從源代碼中呼叫了這行陳述句：
__asm__ volatile ("lock; addl $0,0(%%esp)" : : : "cc", "memory");
而這個指令在部分微架構上的主要功能就是防止指令重排，即這條指令前后的其它指令不會越過這個界限執行[注1]，
在現在的x86/x64微架構中讀寫記憶體的一致性都是通過MESI（Intel使用MESI-F，AMD使用MOESI）協議保證[注2]，MESI的狀態轉換圖如下：
那Java記憶體模型中所說的作業記憶體是什么呢？
我的理解是，首先“作業記憶體”是一個虛擬的概念，而承載這個概念主要是兩部分：
1. 編譯器
2. 微架構
作為編譯器肯定是執行速度越快越好，所以作為編譯器應當盡量減少從記憶體讀資料，如果一個資料在暫存器中，那么直接使用暫存器中的值無疑性能是最高的，但同時這也會導致可能讀不到最新的值，這里我們通過在Java語言中為變數加上“volatile”強制告訴編譯器這個變數一定要從記憶體獲得，這時編譯器即不會做此類優化【案例見參考資料5（是一個.Net的例子）】，
對于微架構來說，在x86/x64下，CPU會在執行指令時做指令重排，即編譯器生成的指令順序和真正在CPU執行的順序可能是不一致的，當我們用一個變數做信號的時候這種指令重排會帶來悲劇，即如果有如下代碼：
x = 0;
y = 0;
i = 0;
j = 0;
// thread A
y = 1;
x = 1;
// thread B
i = x;
j = y;
上面的代碼i和j的值會是多少呢？答案是：“00， 01， 10， 11”都是有可能的，
對于這種情況，如果我們想得到確定的結果則需要通過“synchronized”（或者j.c.u.locks）來做執行緒間同步，
所以，我個人對Java記憶體模型的理解是：在編譯器各種優化及多種型別的微架構平臺上，Java語言規范制定者試圖創建一個虛擬的概念并傳遞到Java程式員，讓他們能夠在這個虛擬的概念上寫出執行緒安全的程式來，而編譯器實作者會根據Java語言規范中的各種約束在不同的平臺上達到Java程式員所需要的執行緒安全這個目的，
最后
私信回復 資料 領取一線大廠Java面試題總結+阿里巴巴泰山手冊+各知識點學習思維導+一份300頁pdf檔案的Java核心知識點總結！
這些資料的內容都是面試時面試官必問的知識點，篇章包括了很多知識點，其中包括了有基礎知識、Java集合、JVM、多執行緒并發、spring原理、微服務、Netty 與RPC 、Kafka、日記、設計模式、Java演算法、資料庫、Zookeeper、分布式快取、資料結構等等，
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/100233.html
標籤：Java