Java內存模型實例分析

這篇文章主要介紹“Java內存模型實例分析”的相關知識，小編通過實際案例向大家展示操作過程，操作方法簡單快捷，實用性強，希望這篇“Java內存模型實例分析”文章能幫助大家解決問題。

所有的編程語言中都有內存模型這個概念，區別于微架構的內存模型，高級語言的內存模型包括了編譯器和微架構兩部分。我試圖了解了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內存模型實例分析”的內容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業相關的知識，可以關注億速云行業資訊頻道，小編每天都會為大家更新不同的知識點。