Java內存模型描述了Java編程語言中的線程如何通過內存進行交互。 連同代碼的單線程執行描述一起，內存模型提供了Java編程語言的語義。 最初的Java內存模型開發于1995年，人們普遍認為它已損壞，從而阻止了許多運行時優化，并且沒有為代碼安全性提供足夠有力的保證。 它通過Java社區流程進行了更新，即Java規范請求133（JSR-133） （于2004年對Tiger（Java 5.0）生效）。
您可以在Java語言規范的“ 線程和鎖 ”一章以及此Java內存模型討論頁面中找到一些非常有用的信息。
現在，讓我們從“ The Khangaonkar Report ”中看到我們最新的JCG合作伙伴 Manoj提供的有關該主題的一些見解。
（注意：對原始帖子進行了少量編輯以提高可讀性）
Java內存模型描述了定義多個線程寫入和讀取變量時如何看待寫入內存的規則。
當線程讀取變量時，它不一定從內存中獲取最新值。 處理器可能返回一個緩存的值。 此外，即使程序員在編寫代碼時先寫入變量，然后讀取變量，但只要編譯器不改變程序語義，就可以對語句重新排序。 處理器和編譯器通常會這樣做以優化性能。 結果，線程可能看不到它期望看到的值。 這可能導致難以修復并發程序中的錯誤。
Java編程語言提供了“ synchronized”，“ volatile”和“ final”關鍵字來幫助編寫安全的多線程代碼。 但是，由于內存模型未指定，Java的早期版本存在一些問題。 JSR 133（Java內存模型和線程規范修訂版）修復了早期內存模型中的某些缺陷。
大多數程序員都熟悉這樣一個事實，即進入同步塊意味著在監視器上獲得一個鎖，以確保沒有其他線程可以進入同步塊。 不那么熟悉但同樣重要的事實是
（1）獲取鎖并輸入同步塊會強制線程從內存刷新數據。
（2）退出同步塊后，寫入的數據將刷新到內存中。
這確保了同步塊中的線程對同步塊中的其他線程可見。
有沒有聽說過Java上下文中的“ 發生在……之前 ”？ JSR 133引入了“之前發生”一詞，并為程序中動作的順序提供了一些保證。 這些保證是：
（1）線程中的每個動作都在該線程之后的所有其他動作之前發生。
（2）顯示器上的解鎖發生在同一顯示器上的后續鎖定之前
（3）對變量的易失性寫入發生在對同一變量的后續易失性讀取之前 （4）對Thread.start（）的調用發生在該線程中的任何其他語句之前 （5）線程中的所有動作發生在該線程上的其他任何線程從join（）返回之前
術語“動作”在Java語言規范的17.4.2節中定義為可以被其他線程檢測或影響的語句。 正常的讀/寫，易失性的讀/寫，鎖定/解鎖是一些動作。
規則1、4和5保證在單個線程中，所有動作將按照它們在創作程序中出現的順序執行。 規則2和4確保在處理共享數據的多個線程之間，保留同步塊的相對順序以及對易失變量的讀/寫順序。
規則2和規則4使volatile非常類似于同步塊。 在JSR 133之前，volatile仍然意味著對volatile變量的寫操作直接寫到內存中，而讀操作則從內存中讀取。 但是編譯器可能會對非易失性讀/寫進行重新排序，而非易失性讀/寫會導致錯誤的結果。 在JSR 133之后無法使用。
還有一點值得注意。 這與在類的構造函數中初始化的最終成員有關。 只要構造函數正確完成執行，其他線程就可以看到最終成員而無需同步。 但是，如果您從構造函數中共享對對象的引用，則所有選擇都將關閉。
提出的規范描述了線程，鎖，易失性變量和數據競爭的語義。 這包括所謂的Java內存模型 。
相關文章：
- Cajo，用Java完成分布式計算的最簡單方法
- Java最佳實踐–高性能序列化
- Java最佳實踐–字符串性能和精確字符串匹配
- Java最佳實踐– Vector vs ArrayList vs HashSet
- Java最佳實踐–隊列之戰和鏈接的ConcurrentHashMap
翻譯自: https://www.javacodegeeks.com/2011/02/java-memory-model-quick-overview-and.html
)
 ，加修改)
)
 helloworld)
 write_file())
)
)
)
