Java 理論與實踐: 修復 Java 內存模型,第 2 部分 (VOLATILE, FINA...

活躍了將近三年的 JSR 133,近期發佈了關於如何修復 Java 內存模型(Java Memory Model, JMM)的公開建議。在本系列文章的 第 1 部分,專欄做者 Brian Goetz 主要介紹最初的 JMM 中的幾個嚴重缺陷,這些缺陷致使了一些難度高得驚人的概念語義,這些概念原來被認爲很簡單。這個月,他介紹在新 JMM 中 volatile 和 final 的語義是如何變化的,這些改變使它們的語義符合大多數開發人員的直覺。其中一些改變已經在 JDK 1.4 中出現了,另外一些改變則要等到 JDK 1.5。請您在本文的討論論壇上與做者及其餘讀者交流您的想法。

開始編寫併發代碼是一件困難的事情,語言不該當增長它的難度。雖然 Java 平臺從一開始就包括了對線程的支持,包括一個計劃爲正確同步的程序提供「一次編寫,處處運行」保證的、跨平臺的內存模型,可是原來的內存模型有一些漏洞。雖然許多 Java 平臺提供了比 JMM 所要求的更強的保證,可是 JMM 中的漏洞使得沒法容易地編寫能夠在任何平臺上運行的併發 Java 程序。因此在 2001 年 5 月,成立了以修復 Java 內存模型爲目的的 JSR 133。 上個月,我討論了其中一些漏洞,這個月,咱們將討論如何堵住它們。 緩存

修復後的可見性併發

理解 JMM 所須要的一個關鍵概念是 可見性(visibility)——如何知道當線程 A 執行 someVariable?=?3 時,其餘線程是否能夠看到線程 A 所寫的值 3?有一些緣由使其餘線程不能當即看到 someVariable 的值 3:多是由於編譯器爲了執行效率更高而從新排序了指令,也多是 someVariable 緩存在寄存器中,或者它的值寫到寫處理器的緩存中、可是尚未刷新到主存中,或者在讀處理器的緩存中有一個老的(或者無效的)值。內存模型決定何時一個線程能夠可靠地「看到」由其餘線程對變量的寫入。特別是,內存模型定義了保證內存操做跨線程的可見性的 volatile 、 synchronized 和 final 的語義線程

相關文章
相關標籤/搜索