日韩无码专区无码一级三级片|91人人爱网站中日韩无码电影|厨房大战丰满熟妇|AV高清无码在线免费观看|另类AV日韩少妇熟女|中文日本大黄一级黄色片|色情在线视频免费|亚洲成人特黄a片|黄片wwwav色图欧美|欧亚乱色一区二区三区

RELATEED CONSULTING
相關(guān)咨詢
選擇下列產(chǎn)品馬上在線溝通
服務(wù)時(shí)間：8:30-17:00
你可能遇到了下面的問(wèn)題
關(guān)閉右側(cè)工具欄

新聞中心

這里有您想知道的互聯(lián)網(wǎng)營(yíng)銷解決方案
Java中ConcurrentHashMap原理分析

一.Java并發(fā)基礎(chǔ)

在南昌等地區(qū)，都構(gòu)建了全面的區(qū)域性戰(zhàn)略布局，加強(qiáng)發(fā)展的系統(tǒng)性、市場(chǎng)前瞻性、產(chǎn)品創(chuàng)新能力，以專注、極致的服務(wù)理念，為客戶提供成都做網(wǎng)站、成都網(wǎng)站設(shè)計(jì)、成都外貿(mào)網(wǎng)站建設(shè) 網(wǎng)站設(shè)計(jì)制作定制網(wǎng)站,公司網(wǎng)站建設(shè),企業(yè)網(wǎng)站建設(shè),品牌網(wǎng)站制作,成都全網(wǎng)營(yíng)銷,外貿(mào)網(wǎng)站制作,南昌網(wǎng)站建設(shè)費(fèi)用合理。

當(dāng)一個(gè)對(duì)象或變量可以被多個(gè)線程共享的時(shí)候，就有可能使得程序的邏輯出現(xiàn)問(wèn)題。 在一個(gè)對(duì)象中有一個(gè)變量i=0，有兩個(gè)線程A，B都想對(duì)i加1，這個(gè)時(shí)候便有問(wèn)題顯現(xiàn)出來(lái)，關(guān)鍵就是對(duì)i加1的這個(gè)過(guò)程不是原子操作。要想對(duì)i進(jìn)行遞增， ***步就是獲取i的值，當(dāng)A獲取i的值為0，在A將新的值寫(xiě)入A之前，B也獲取了A的值0，然后A寫(xiě)入，i變成1，然后B也寫(xiě)入i，i這個(gè)時(shí)候依然是1. 當(dāng)然java的內(nèi)存模型沒(méi)有上面這么簡(jiǎn)單，在Java Memory Model中，Memory分為兩類，main memory和working memory，main memory為所有線程共享，working memory中存放的是線程所需要的變量的拷貝（線程要對(duì)main memory中的內(nèi)容進(jìn)行操作的話，首先需要拷貝到自己的working memory，一般為了速度，working memory一般是在cpu的cache中的）。Volatile的變量在被操作的時(shí)候不會(huì)產(chǎn)生working memory的拷貝，而是直接操作main memory，當(dāng)然volatile雖然解決了變量的可見(jiàn)性問(wèn)題，但沒(méi)有解決變量操作的原子性的問(wèn)題，這個(gè)還需要synchronized或者CAS相關(guān)操作配合進(jìn)行。

多線程中幾個(gè)重要的概念:

可見(jiàn)性

也就說(shuō)假設(shè)一個(gè)對(duì)象中有一個(gè)變量i，那么i是保存在main memory中的，當(dāng)某一個(gè)線程要操作i的時(shí)候，首先需要從main memory中將i 加載到這個(gè)線程的working memory中，這個(gè)時(shí)候working memory中就有了一個(gè)i的拷貝，這個(gè)時(shí)候此線程對(duì)i的修改都在其working memory中，直到其將i從working memory寫(xiě)回到main memory中，新的i的值才能被其他線程所讀取。從某個(gè)意義上說(shuō)，可見(jiàn)性保證了各個(gè)線程的working memory的數(shù)據(jù)的一致性。 可見(jiàn)性遵循下面一些規(guī)則：

  • 當(dāng)一個(gè)線程運(yùn)行結(jié)束的時(shí)候，所有寫(xiě)的變量都會(huì)被flush回main memory中。

  • 當(dāng)一個(gè)線程***次讀取某個(gè)變量的時(shí)候，會(huì)從main memory中讀取***的。

  • volatile的變量會(huì)被立刻寫(xiě)到main memory中的，在jsr133中，對(duì)volatile的語(yǔ)義進(jìn)行增強(qiáng)，后面會(huì)提到

  • 當(dāng)一個(gè)線程釋放鎖后，所有的變量的變化都會(huì)flush到main memory中，然后一個(gè)使用了這個(gè)相同的同步鎖的進(jìn)程，將會(huì)重新加載所有的使用到的變量，這樣就保證了可見(jiàn)性。

原子性

還拿上面的例子來(lái)說(shuō)，原子性就是當(dāng)某一個(gè)線程修改i的值的時(shí)候，從取出i到將新的i的值寫(xiě)給i之間不能有其他線程對(duì)i進(jìn)行任何操作。也就是說(shuō)保證某 個(gè)線程對(duì)i的操作是原子性的，這樣就可以避免數(shù)據(jù)臟讀。 通過(guò)鎖機(jī)制或者CAS（Compare And Set 需要硬件CPU的支持）操作可以保證操作的原子性。

有序性

假設(shè)在main memory中存在兩個(gè)變量i和j，初始值都為0，在某個(gè)線程A的代碼中依次對(duì)i和j進(jìn)行自增操作（i，j的操作不相互依賴）

i++;
j++;

由于，所以i,j修改操作的順序可能會(huì)被重新排序。那么修改后的ij寫(xiě)到main memory中的時(shí)候，順序可能就不是按照i，j的順序了，這就是所謂的reordering，在單線程的情況下，當(dāng)線程A運(yùn)行結(jié)束的后i，j的值都加1 了，在線程自己看來(lái)就好像是線程按照代碼的順序進(jìn)行了運(yùn)行（這些操作都是基于as-if-serial語(yǔ)義的），即使在實(shí)際運(yùn)行過(guò)程中，i，j的自增可能 被重新排序了，當(dāng)然計(jì)算機(jī)也不能幫你亂排序，存在上下邏輯關(guān)聯(lián)的運(yùn)行順序肯定還是不會(huì)變的。但是在多線程環(huán)境下，問(wèn)題就不一樣了，比如另一個(gè)線程B的代碼 如下

 
 
    
  
  
  1. if(j==1) { 
    2. 
  
  
  2.     System.out.println(i); 
    3. 
  
  
  3. } 
    4.

按照我們的思維方式，當(dāng)j為1的時(shí)候那么i肯定也是1，因?yàn)榇a中i在j之前就自增了，但實(shí)際的情況有可能當(dāng)j為1的時(shí)候i還是為0。這就是 reordering產(chǎn)生的不好的后果，所以我們?cè)谀承r(shí)候?yàn)榱吮苊膺@樣的問(wèn)題需要一些必要的策略，以保證多個(gè)線程一起工作的時(shí)候也存在一定的次序。 JMM提供了happens-before 的排序策略。這樣我們可以得到多線程環(huán)境下的as-if-serial語(yǔ)義。 這里不對(duì)happens-before進(jìn)行詳細(xì)解釋了,詳細(xì)的請(qǐng)看這里http://www.ibm.com/developerworks/cn /java/j-jtp03304/，這里主要講一下volatile在新的java內(nèi)存模型下的變化，在jsr133之前，下面的代碼可能會(huì)出現(xiàn)問(wèn)題

 
 
    
  
  
  1. Map configOptions; 
    2. 
  
  
  2. char[] configText; 
    3. 
  
  
  3. volatile boolean initialized = false; 
    4. 
  
  
  4. // In Thread A 
    5. 
  
  
  5. configOptions = new HashMap(); 
    6. 
  
  
  6. configText = readConfigFile(fileName); 
    7. 
  
  
  7. processConfigOptions(configText, configOptions); 
    8. 
  
  
  8. initialized = true; 
    9. 
  
  
  9. // In Thread B 
    10. 
  
  
  10. while (!initialized) 
    11. 
  
  
  11.   sleep(); 
    12. 
  
  
  12. // use configOptions 
    13.

jsr133之前，雖然對(duì) volatile 變量的讀和寫(xiě)不能與對(duì)其他 volatile 變量的讀和寫(xiě)一起重新排序，但是它們?nèi)匀豢梢耘c對(duì) nonvolatile 變量的讀寫(xiě)一起重新排序，所以上面的Thread A的操作，就可能initialized變成true的時(shí)候，而configOptions還沒(méi)有被初始化，所以initialized先于 configOptions被線程B看到，就產(chǎn)生問(wèn)題了。

JSR 133 Expert Group 決定讓 volatile 讀寫(xiě)不能與其他內(nèi)存操作一起重新排序，新的內(nèi)存模型下，如果當(dāng)線程 A 寫(xiě)入 volatile 變量 V 而線程 B 讀取 V 時(shí)，那么在寫(xiě)入 V 時(shí)，A 可見(jiàn)的所有變量值現(xiàn)在都可以保證對(duì) B 是可見(jiàn)的。

結(jié)果就是作用更大的 volatile 語(yǔ)義，代價(jià)是訪問(wèn) volatile 字段時(shí)會(huì)對(duì)性能產(chǎn)生更大的影響。這一點(diǎn)在ConcurrentHashMap中的統(tǒng)計(jì)某個(gè)segment元素個(gè)數(shù)的count變量中使用到了。

二.線程安全的HashMap

什么時(shí)候我們需要使用線程安全的hashmap呢，比如一個(gè)hashmap在運(yùn)行的時(shí)候只有讀操作，那么很明顯不會(huì)有問(wèn)題，但是當(dāng)涉及到同時(shí)有改變 也有讀的時(shí)候，就要考慮線程安全問(wèn)題了，在不考慮性能問(wèn)題的時(shí)候，我們的解決方案有Hashtable或者 Collections.synchronizedMap(hashMap)，這兩種方式基本都是對(duì)整個(gè)hash表結(jié)構(gòu)做鎖定操作的，這樣在鎖表的期間， 別的線程就需要等待了，無(wú)疑性能不高。

三.ConcurrentHashMap實(shí)現(xiàn)原理

數(shù)據(jù)結(jié)構(gòu) ConcurrentHashMap的目標(biāo)是實(shí)現(xiàn)支持高并發(fā)、高吞吐量的線程安全的HashMap。當(dāng)然不能直接對(duì)整個(gè)hashtable加鎖，所以在ConcurrentHashMap中，數(shù)據(jù)的組織結(jié)構(gòu)和HashMap有所區(qū)別。

一個(gè)ConcurrentHashMap由多個(gè)segment組成，每一個(gè)segment都包含了一個(gè)HashEntry數(shù)組的 hashtable， 每一個(gè)segment包含了對(duì)自己的hashtable的操作，比如get，put，replace等操作，這些操作發(fā)生的時(shí)候，對(duì)自己的 hashtable進(jìn)行鎖定。由于每一個(gè)segment寫(xiě)操作只鎖定自己的hashtable，所以可能存在多個(gè)線程同時(shí)寫(xiě)的情況，性能無(wú)疑好于只有一個(gè) hashtable鎖定的情況。

源碼分析 在ConcurrentHashMap的remove，put操作還是比較簡(jiǎn)單的，都是將remove或者put操作交給key所對(duì)應(yīng)的segment去做的，所以當(dāng)幾個(gè)操作不在同一個(gè)segment的時(shí)候就可以并發(fā)的進(jìn)行。

 
 
    
  
  
  1. public V remove(Object key) { 
    2. 
  
  
  2.     int hash = hash(key.hashCode()); 
    3. 
  
  
  3.         return segmentFor(hash).remove(key, hash, null); 
    4. 
  
  
  4.     } 
    5.

而segment中的remove操作除了加鎖之外和HashMap中的remove操作基本無(wú)異。

 
 
    
  
  
  1. /** 
    2. 
  
  
  2.          * Remove; match on key only if value null, else match both. 
    3. 
  
  
  3.          */ 
    4. 
  
  
  4.         V remove(Object key, int hash, Object value) { 
    5. 
  
  
  5.             lock(); 
    6. 
  
  
  6.             try { 
    7. 
  
  
  7.                 int c = count - 1; 
    8. 
  
  
  8.                 HashEntry[] tab = table; 
    9. 
  
  
  9.                 int index = hash & (tab.length - 1); 
    10. 
  
  
  10.                 HashEntry first = tab[index]; 
    11. 
  
  
  11.                 HashEntry e = first; 
    12. 
  
  
  12.                 while (e != null && (e.hash != hash || !key.equals(e.key))) 
    13. 
  
  
  13.                     e = e.next; 
    14. 
  
  
  14.  
    15. 
  
  
  15.                 V oldValue = null; 
    16. 
  
  
  16.                 if (e != null) { 
    17. 
  
  
  17.                     V v = e.value; 
    18. 
  
  
  18.                     if (value == null || value.equals(v)) { 
    19. 
  
  
  19.                         oldValue = v; 
    20. 
  
  
  20.                         // All entries following removed node can stay 
    21. 
  
  
  21.                         // in list, but all preceding ones need to be 
    22. 
  
  
  22.                         // cloned. 
    23. 
  
  
  23.                         ++modCount; 
    24. 
  
  
  24.                         HashEntry newFirst = e.next; 
    25. 
  
  
  25.                         for (HashEntry p = first; p != e; p = p.next) 
    26. 
  
  
  26.                             newFirst = new HashEntry(p.key, p.hash, 
    27. 
  
  
  27.                                                           newFirst, p.value); 
    28. 
  
  
  28.                         tab[index] = newFirst; 
    29. 
  
  
  29.                         count = c; // write-volatile 
    30. 
  
  
  30.                     } 
    31. 
  
  
  31.                 } 
    32. 
  
  
  32.                 return oldValue; 
    33. 
  
  
  33.             } finally { 
    34. 
  
  
  34.                 unlock(); 
    35. 
  
  
  35.             } 
    36. 
  
  
  36.         } 
    37.

上面的代碼中關(guān)于volatile類型的變量count值得一提，這里充分利用了Java 5中對(duì)volatile語(yǔ)義的增強(qiáng)，count = c的操作必須在modCount，table等操作的后面，這樣才能保證這些變量操作的可見(jiàn)性。 Segment類繼承于ReentrantLock，主要是為了使用ReentrantLock的鎖，ReentrantLock的實(shí)現(xiàn)比 synchronized在多個(gè)線程爭(zhēng)用下的總體開(kāi)銷小。 put操作和remove操作類似。

接下來(lái)我們來(lái)看下get操作。

 
 
    
  
  
  1. public V get(Object key) { 
    2. 
  
  
  2.         int hash = hash(key.hashCode()); 
    3. 
  
  
  3.         return segmentFor(hash).get(key, hash); 
    4. 
  
  
  4.     } 
    5. 
  
  
  5.  
    6. 
  
  
  6. 也是使用了對(duì)應(yīng)的segment的get 
    7. 
  
  
  7.  
    8. 
  
  
  8. V get(Object key, int hash) { 
    9. 
  
  
  9.             if (count != 0) { // read-volatile 
    10. 
  
  
  10.                 HashEntry e = getFirst(hash); 
    11. 
  
  
  11.                 while (e != null) { 
    12. 
  
  
  12.                     if (e.hash == hash && key.equals(e.key)) { 
    13. 
  
  
  13.                         V v = e.value; 
    14. 
  
  
  14.                         if (v != null) 
    15. 
  
  
  15.                             return v; 
    16. 
  
  
  16.                         return readValueUnderLock(e); // recheck 
    17. 
  
  
  17.                     } 
    18. 
  
  
  18.                     e = e.next; 
    19. 
  
  
  19.                 } 
    20. 
  
  
  20.             } 
    21. 
  
  
  21.             return null; 
    22. 
  
  
  22.         } 
    23.

上面的代碼中，一開(kāi)始就對(duì)volatile變量count進(jìn)行了讀取比較，這個(gè)還是java5對(duì)volatile語(yǔ)義增強(qiáng)的作用，這樣就可以獲取變 量的可見(jiàn)性。所以count != 0之后，我們可以認(rèn)為對(duì)應(yīng)的hashtable是***的，當(dāng)然由于讀取的時(shí)候沒(méi)有加鎖，在get的過(guò)程中，可能會(huì)有更新。當(dāng)發(fā)現(xiàn)根據(jù)key去找元素的時(shí) 候，但發(fā)現(xiàn)找得的key對(duì)應(yīng)的value為null，這個(gè)時(shí)候可能會(huì)有其他線程正在對(duì)這個(gè)元素進(jìn)行寫(xiě)操作，所以需要在使用鎖的情況下在讀取一下 value，以確保最終的值。

其他相關(guān)涉及讀取的操作也都類似。


本文標(biāo)題：Java中ConcurrentHashMap原理分析
分享鏈接：http://www.5511xx.com/article/cccejdi.html