<rt id="bn8ez"></rt>
<label id="bn8ez"></label>

  • <span id="bn8ez"></span>

    <label id="bn8ez"><meter id="bn8ez"></meter></label>

    lqxue

    常用鏈接

    統(tǒng)計

    book

    tools

    最新評論

    java內(nèi)存模型

    內(nèi)存模型 (memory model)
    內(nèi)存模型描述的是程序中各變量(實例域、靜態(tài)域和數(shù)組元素)之間的關(guān)系,以及在實際計算機系統(tǒng)中將變量存儲到內(nèi)存和從內(nèi)存取出變量這樣的低層細節(jié).

    不同平臺間的處理器架構(gòu)將直接影響內(nèi)存模型的結(jié)構(gòu).

    在C或C++中, 可以利用不同操作平臺下的內(nèi)存模型來編寫并發(fā)程序. 但是, 這帶給開發(fā)人員的是, 更高的學習成本.
    相比之下, java利用了自身虛擬機的優(yōu)勢, 使內(nèi)存模型不束縛于具體的處理器架構(gòu), 真正實現(xiàn)了跨平臺.
    (針對hotspot jvm, jrockit等不同的jvm, 內(nèi)存模型也會不相同)

    內(nèi)存模型的特征:
    a, Visibility 可視性 (多核,多線程間數(shù)據(jù)的共享)
    b, Ordering 有序性 (對內(nèi)存進行的操作應該是有序的)



    java 內(nèi)存模型 ( java memory model )
    根據(jù)Java Language Specification中的說明, jvm系統(tǒng)中存在一個主內(nèi)存(Main Memory或Java Heap Memory),Java中所有變量都儲存在主存中,對于所有線程都是共享的。

    每條線程都有自己的工作內(nèi)存(Working Memory),工作內(nèi)存中保存的是主存中某些變量的拷貝,線程對所有變量的操作都是在工作內(nèi)存中進行,線程之間無法相互直接訪問,變量傳遞均需要通過主存完成。



    其中, 工作內(nèi)存里的變量, 在多核處理器下, 將大部分儲存于處理器高速緩存中, 高速緩存在不經(jīng)過內(nèi)存時, 也是不可見的.

    jmm怎么體現(xiàn) 可視性(Visibility) ?
    在jmm中, 通過并發(fā)線程修改變量值, 必須將線程變量同步回主存后, 其他線程才能訪問到.

    jmm怎么體現(xiàn) 有序性(Ordering) ?

    通過java提供的同步機制或volatile關(guān)鍵字, 來保證內(nèi)存的訪問順序.



    緩存一致性(cache coherency)

    什么是緩存一致性?
    它是一種管理多處理器系統(tǒng)的高速緩存區(qū)結(jié)構(gòu),其可以保證數(shù)據(jù)在高速緩存區(qū)到內(nèi)存的傳輸中不會丟失或重復。(來自wikipedia)

    舉例理解:
    假如有一個處理器有一個更新了的變量值位于其緩存中,但還沒有被寫入主內(nèi)存,這樣別的處理器就可能會看不到這個更新的值.

    解決緩存一致性的方法?
    a, 順序一致性模型:
    要求某處理器對所改變的變量值立即進行傳播, 并確保該值被所有處理器接受后, 才能繼續(xù)執(zhí)行其他指令.

    b, 釋放一致性模型: (類似jmm cache coherency)
    允許處理器將改變的變量值延遲到釋放鎖時才進行傳播.



    jmm緩存一致性模型 - "happens-before ordering(先行發(fā)生排序)"

    一般情況下的示例程序:

    x = 0;
    y = 0;
    i = 0;
    j = 0;

    // thread A
    y = 1;
    x = 1;

    // thread B
    i = x;
    j = y;

    在如上程序中, 如果線程A,B在無保障情況下運行, 那么i,j各會是什么值呢?

    答案是, 不確定. (00,01,10,11都有可能出現(xiàn))
    這里沒有使用java同步機制, 所以 jmm 有序性和可視性 都無法得到保障.

    happens-before ordering( 先行發(fā)生排序) 如何避免這種情況?
    排序原則已經(jīng)做到:
    a, 在程序順序中, 線程中的每一個操作, 發(fā)生在當前操作后面將要出現(xiàn)的每一個操作之前.
    b, 對象監(jiān)視器的解鎖發(fā)生在等待獲取對象鎖的線程之前.
    c, 對volitile關(guān)鍵字修飾的變量寫入操作, 發(fā)生在對該變量的讀取之前.
    d,
    對一個線程的 Thread.start() 調(diào)用 發(fā)生在啟動的線程中的所有操作之前.
    e, 線程中的所有操作 發(fā)生在從這個線程的 Thread.join()成功返回的所有其他線程之前.

    為了實現(xiàn)
    happends-before ordering原則, java及jdk提供的工具:
    a, synchronized關(guān)鍵字
    b, volatile關(guān)鍵字
    c, final變量
    d, java.util.concurrent.locks包(since jdk 1.5)
    e, java.util.concurrent.atmoic包(since jdk 1.5)
    ...

    使用了happens-before ordering的例子:





    (1) 獲取對象監(jiān)視器的鎖(lock)

    (2) 清空工作內(nèi)存數(shù)據(jù), 從主存復制變量到當前工作內(nèi)存, 即同步數(shù)據(jù) (read and load)

    (3) 執(zhí)行代碼,改變共享變量值 (use and assign)

    (4) 將工作內(nèi)存數(shù)據(jù)刷回主存 (store and write)

    (5) 釋放對象監(jiān)視器的鎖 (unlock)

    注意: 其中4,5兩步是同時進行的.

    這邊最核心的就是第二步, 他同步了主內(nèi)存,即前一個線程對變量改動的結(jié)果,可以被當前線程獲知!(利用了happens-before ordering原則)

    對比之前的例子
    如果多個線程同時執(zhí)行一段未經(jīng)鎖保護的代碼段,很有可能某條線程已經(jīng)改動了變量的值,但是其他線程卻無法看到這個改動,依然在舊的變量值上進行運算,最終導致不可預料的運算結(jié)果。



    經(jīng)典j2ee設計模式Double-Checked Locking失效問題
    雙重檢查鎖定失效問題,一直是JMM無法避免的缺陷之一.了解DCL失效問題, 可以幫助我們深入JMM運行原理.

    要展示DCL失效問題, 首先要理解一個重要概念- 延遲加載(lazy loading).

    非單例的單線程延遲加載示例:
    class Foo
    {
    private Resource res = null;
    public Resource getResource()
    {
        // 普通的延遲加載
    if (res == null)
            res = new Resource();
    return res;
    }
    }

    非單例的 多線程延遲加載示例:
    Class Foo
    {
    Private Resource res = null;
    Public synchronized Resource getResource()
    {
          // 獲取實例操作使用同步方式, 性能不高
    If (res == null) res = new Resource();
    return res;
    }
    }

    非單例的 DCL多線程延遲加載示例:
    Class Foo
    {
    Private Resource res = null;
    Public Resource getResource()
    {
    If (res == null)
    {
           //只有在第一次初始化時,才使用同步方式.
    synchronized(this)
    {
    if(res == null)
    {
    res = new Resource();
    }
    }
    }
    return res;
    }
    }

    Double-Checked Locking看起來是非常完美的。但是很遺憾,根據(jù)Java的語言規(guī)范,上面的代碼是不可靠的。

    出現(xiàn)上述問題, 最重要的2個原因如下:
    1, 編譯器優(yōu)化了程序指令, 以加快cpu處理速度.
    2, 多核cpu動態(tài)調(diào)整指令順序, 以加快并行運算能力.

    問題出現(xiàn)的順序:
    1, 線程A, 發(fā)現(xiàn)對象未實例化, 準備開始實例化
    2, 由于編譯器優(yōu)化了程序指令, 允許對象在構(gòu)造函數(shù)未調(diào)用完前, 將
    共享變量的引用指向 部分構(gòu)造的對象, 雖然對象未完全實例化, 但已經(jīng)不為null了.
    3, 線程B, 發(fā)現(xiàn)部分構(gòu)造的對象已不是null, 則直接返回了該對象.

    不過, 一些著名的開源框架, 包括jive,lenya等也都在使用DCL模式, 且未見一些極端異常.
    說明, DCL失效問題的出現(xiàn)率還是比較低的.
    接下來就是性能與穩(wěn)定之間的選擇了?

    DCL的替代
    Initialize-On-Demand :

    public class Foo {
        // 似有靜態(tài)內(nèi)部類, 只有當有引用時, 該類才會被裝載
        private static class LazyFoo {
           public static Foo foo = new Foo();
        }

        public static Foo getInstance() {
           return LazyFoo.foo;
        }
    }


    維基百科的DCL解釋:
    http://en.wikipedia.org/wiki/Double-checked_locking

    DCL的完美解決方案:
    http://www.theserverside.com/patterns/thread.tss?thread_id=39606


    總結(jié):
    多線程編程, 針對有寫操作的變量, 必須 保證其所有引用點與主存中數(shù)據(jù)一致(考慮采用同步或volatile)
    .

    多核線程筆記-volatile原理與技巧

    posted on 2008-11-05 16:39 lqx 閱讀(296) 評論(0)  編輯  收藏 所屬分類: java

    主站蜘蛛池模板: 无码国产精品一区二区免费式影视| 午夜亚洲国产精品福利| 99精品视频在线视频免费观看 | 国产偷国产偷亚洲清高APP| 24小时日本在线www免费的| 亚洲乱色熟女一区二区三区蜜臀| 最近中文字幕免费mv视频7| 亚洲中文字幕久久精品无码VA| 免费精品国产自产拍在线观看图片| 亚洲午夜精品一区二区公牛电影院| 91福利免费体验区观看区| 亚洲午夜成激人情在线影院| 97无码免费人妻超级碰碰碰碰| 亚洲欧洲AV无码专区| 免费在线观看a级毛片| jizz免费一区二区三区| 久久久久亚洲精品美女| 91九色精品国产免费| 一区二区亚洲精品精华液| 男人的天堂亚洲一区二区三区| 亚洲精品乱码久久久久久蜜桃图片| 国产成人高清精品免费软件| 无码人妻一区二区三区免费视频 | 久久精品视频免费播放| 亚洲剧场午夜在线观看| 日韩一品在线播放视频一品免费| 一边摸一边爽一边叫床免费视频| 国产精品亚洲аv无码播放| 精品福利一区二区三区免费视频| 亚洲成aⅴ人片久青草影院按摩| 亚洲av手机在线观看| 久久成人免费电影| 亚洲自国产拍揄拍| 亚洲午夜激情视频| 国产精品视频免费观看| 四虎精品成人免费视频| 亚洲视频手机在线| 中文字幕无码亚洲欧洲日韩| 亚洲国产成人久久综合一区77| 性xxxxx大片免费视频| 丰满亚洲大尺度无码无码专线|