成人免费xxxxx在线视频软件_久久精品久久久_亚洲国产精品久久久_天天色天天色_亚洲人成一区_欧美一级欧美三级在线观看

從LongAdder看更高效的無鎖實現(xiàn)

開發(fā) 后端
LongAdder確實用了很多心思減少并發(fā)量,并且,每一步都是在”沒有更好的辦法“的時候才會選擇更大開銷的操作,從而盡可能的用最最簡單的辦法去完成操作。追求簡單,但是絕對不粗暴。

接觸到AtomicLong的原因是在看guava的LoadingCache相關代碼時,關于LoadingCache,其實思路也非常簡單清晰:用模板模式解決了緩存不命中時獲取數(shù)據(jù)的邏輯,這個思路我早前也正好在項目中使用到。

言歸正傳,為什么說LongAdder引起了我的注意,原因有二:

  1. 作者是Doug lea ,地位實在舉足輕重。
  2. 他說這個比AtomicLong高效。

我們知道,AtomicLong已經(jīng)是非常好的解決方案了,涉及并發(fā)的地方都是使用CAS操作,在硬件層次上去做 compare and set操作。效率非常高。

因此,我決定研究下,為什么LongAdder比AtomicLong高效。

首先,看LongAdder的繼承樹:

la1

繼承自Striped64,這個類包裝了一些很重要的內部類和操作。稍候會看到。

 

正式開始前,強調下,我們知道,AtomicLong的實現(xiàn)方式是內部有個value 變量,當多線程并發(fā)自增,自減時,均通過CAS 指令從機器指令級別操作保證并發(fā)的原子性。

再看看LongAdder的方法:

la2
怪不得可以和AtomicLong作比較,連API都這么像。我們隨便挑一個API入手分析,這個API通了,其他API都大同小異,因此,我選擇了add這個方法。事實上,其他API也都依賴這個方法。

la3
LongAdder中包含了一個Cell 數(shù)組,Cell是Striped64的一個內部類,顧名思義,Cell 代表了一個最小單元,這個單元有什么用,稍候會說道。先看定義:

la4
Cell內部有一個非常重要的value變量,并且提供了一個CAS更新其值的方法。

回到add方法:

la3

這里,我有個疑問,AtomicLong已經(jīng)使用CAS指令,非常高效了(比起各種鎖),LongAdder如果還是用CAS指令更新值,怎么可能比AtomicLong高效了? 何況內部還這么多判斷!??!

這是我開始時***的疑問,所以,我猜想,難道有比CAS指令更高效的方式出現(xiàn)了? 帶著這個疑問,繼續(xù)。

***if 判斷,***次調用的時候cells數(shù)組肯定為null,因此,進入casBase方法:

la5
原子更新base沒啥好說的,如果更新成功,本地調用開始返回,否則進入分支內部。

什么時候會更新失??? 沒錯,并發(fā)的時候,好戲開始了,AtomicLong的處理方式是死循環(huán)嘗試更新,直到成功才返回,而LongAdder則是進入這個分支。

分支內部,通過一個Threadlocal變量threadHashCode 獲取一個HashCode對象,該HashCode對象依然是Striped64類的內部類,看定義:

la6
有個code變量,保存了一個非0的隨機數(shù)隨機值。

回到add方法:

la3

拿到該線程相關的HashCode對象后,獲取它的code變量,as[(n-1)&h] 這句話相當于對h取模,只不過比起取模,因為是 與 的運算所以效率更高。

計算出一個在Cells 數(shù)組中當先線程的HashCode對應的 索引位置,并將該位置的Cell 對象拿出來用CAS更新它的value值。

當然,如果as 為null 并且更新失敗,才會進入retryUpdate方法。

看到這里我想應該有很多人明白為什么LongAdder會比AtomicLong更高效了,沒錯,唯一會制約AtomicLong高效的原因是高并發(fā),高并發(fā)意味著CAS的失敗幾率更高, 重試次數(shù)更多,越多線程重試,CAS失敗幾率又越高,變成惡性循環(huán),AtomicLong效率降低。 那怎么解決? LongAdder給了我們一個非常容易想到的解決方案:減少并發(fā),將單一value的更新壓力分擔到多個value中去,降低單個value的 “熱度”,分段更新?。。?/strong>

這樣,線程數(shù)再多也會分擔到多個value上去更新,只需要增加value就可以降低 value的 “熱度”  AtomicLong中的 惡性循環(huán)不就解決了嗎? cells 就是這個 “段” cell中的value 就是存放更新值的, 這樣,當我需要總數(shù)時,把cells 中的value都累加一下不就可以了么?。?/strong>

當然,聰明之處遠遠不僅僅這里,在看看add方法中的代碼,casBase方法可不可以不要,直接分段更新,上來就計算 索引位置,然后更新value?

答案是不好,不是不行,因為,casBase操作等價于AtomicLong中的CAS操作,要知道,LongAdder這樣的處理方式是有壞處的,分段操作必然帶來空間上的浪費,可以空間換時間,但是,能不換就不換,看空間時間都節(jié)約~! 所以,casBase操作保證了在低并發(fā)時,不會立即進入分支做分段更新操作,因為低并發(fā)時,casBase操作基本都會成功,只有并發(fā)高到一定程度了,才會進入分支,所以,Doug Lea對該類的說明是: 低并發(fā)時LongAdder和AtomicLong性能差不多,高并發(fā)時LongAdder更高效!

la7

但是,Doung Lea 還是沒這么簡單,聰明之處還沒有結束……

如此,retryUpdate中做了什么事,也基本略知一二了,因為cell中的value都更新失敗(說明該索引到這個cell的線程也很多,并發(fā)也很高時) 或者cells數(shù)組為空時才會調用retryUpdate,

因此,retryUpdate里面應該會做兩件事:

  1. 擴容,將cells數(shù)組擴大,降低每個cell的并發(fā)量,同樣,這也意味著cells數(shù)組的rehash動作。
  2.  給空的cells變量賦一個新的Cell數(shù)組。

是不是這樣呢? 繼續(xù)看代碼:

代碼比較長,變成文本看看,為了方便大家看if else 分支,對應的  { } 我用相同的顏色標注出來。可以看到,這個時候Doug Lea才愿意使用死循環(huán)保證更新成功~!

  1. final void retryUpdate(long x, HashCode hc, boolean wasUncontended) {   
  2.       int h = hc.code;   
  3.       boolean collide = false;                // True if last slot nonempty   
  4.       for (;;) {   
  5.           Cell[] as; Cell a; int n; long v;   
  6.           if ((as = cells) != null && (n = as.length) > 0) {// 分支1   
  7.               if ((a = as[(n - 1) & h]) == null) {   
  8.                   if (busy == 0) {            // Try to attach new Cell   
  9.                       Cell r = new Cell(x);   // Optimistically create   
  10.                       if (busy == 0 && casBusy()) {   
  11.                           boolean created = false;   
  12.                           try {               // Recheck under lock   
  13.                               Cell[] rs; int m, j;   
  14.                               if ((rs = cells) != null &&   
  15.                                       (m = rs.length) > 0 &&   
  16.                                       rs[j = (m - 1) & h] == null) {   
  17.                                   rs[j] = r;   
  18.                                   created = true;   
  19.                               }   
  20.                           } finally {   
  21.                               busy = 0;   
  22.                           }   
  23.                           if (created)   
  24.                               break;   
  25.                           continue;           // Slot is now non-empty   
  26.                       }   
  27.                   }   
  28.                   collide = false;   
  29.               }   
  30.               else if (!wasUncontended)       // CAS already known to fail   
  31.                   wasUncontended = true;      // Continue after rehash   
  32.               else if (a.cas(v = a.value, fn(v, x)))   
  33.                   break;   
  34.               else if (n >= NCPU || cells != as)   
  35.                   collide = false;            // At max size or stale   
  36.               else if (!collide)   
  37.                   collide = true;   
  38.               else if (busy == 0 && casBusy()) {   
  39.                   try {   
  40.                       if (cells == as) {      // Expand table unless stale   
  41.                           Cell[] rs = new Cell[n << 1];   
  42.                           for (int i = 0; i < n; ++i)   
  43.                               rs[i] = as[i];   
  44.                           cells = rs;   
  45.                       }   
  46.                   } finally {   
  47.                       busy = 0;   
  48.                   }   
  49.                   collide = false;   
  50.                   continue;                   // Retry with expanded table   
  51.               }   
  52.               h ^= h << 13;                   // Rehash  h ^= h >>> 17;   
  53.               h ^= h << 5;   
  54.           }   
  55.           else if (busy == 0 && cells == as && casBusy()) {//分支2   
  56.               boolean init = false;   
  57.               try {                           // Initialize table   
  58.                   if (cells == as) {   
  59.                       Cell[] rs = new Cell[2];   
  60.                       rs[h & 1] = new Cell(x);   
  61.                       cells = rs;   
  62.                       init = true;   
  63.                   }   
  64.               } finally {   
  65.                   busy = 0;   
  66.               }   
  67.               if (init)   
  68.                   break;   
  69.           }   
  70.           else if (casBase(v = base, fn(v, x)))   
  71.               break;                          // Fall back on using base   
  72.       }   
  73.       hc.code = h;                            // Record index for next time   
  74.   } 

分支2中,為cells為空的情況,需要new 一個Cell數(shù)組。

分支1分支中,略復雜一點點:

注意,幾個分支中都提到了busy這個方法,這個可以理解為一個CAS實現(xiàn)的鎖,只有在需要更新cells數(shù)組的時候才會更新該值為1,如果更新失敗,則說明當前有線程在更新cells數(shù)組,當前線程需要等待。重試。

回到分支1中,這里首先判斷當前cells數(shù)組中的索引位置的cell元素是否為空,如果為空,則添加一個cell到數(shù)組中。

否則更新 標示沖突的標志位wasUncontended 為 true ,重試。

否則,再次更新cell中的value,如果失敗,重試。

。。。。。。。一系列的判斷后,如果還是失敗,下下下策,reHash,直接將cells數(shù)組擴容一倍,并更新當前線程的hash值,保證下次更新能盡可能成功。

可以看到,LongAdder確實用了很多心思減少并發(fā)量,并且,每一步都是在”沒有更好的辦法“的時候才會選擇更大開銷的操作,從而盡可能的用最最簡單的辦法去完成操作。追求簡單,但是絕對不粗暴。

#p#

———————陳皓注————————

***留給大家思考的兩個問題:

1)是不是AtomicLong可以被廢了?

2)如果cell被創(chuàng)建后,原來的casBase就不走了,會不會性能更差?

———————liuinsect注————————

昨天和左耳朵耗子簡單討論了下,發(fā)現(xiàn)左耳朵耗子,耗哥對讀者思維的引導還是非常不錯的,在***次發(fā)現(xiàn)這個類后,對里面的實現(xiàn)又提出了更多的問題,引導大家思考,值得學習。

我們 發(fā)現(xiàn)的問題有這么幾個(包括以上的問題),自己簡單總結下,歡迎大家討論:

1. jdk 1.7中是不是有這個類?

我確認后,結果如下:    jdk-7u51 版本上還沒有  但是jdk-8u20版本上已經(jīng)有了。代碼基本一樣 ,增加了對double類型的支持和刪除了一些冗余的代碼。有興趣的同學可以去下載下JDK 1.8看看

2. base有沒有參與匯總?

base在調用intValue等方法的時候是會匯總的:

LA10

3. 如果cell被創(chuàng)建后,原來的casBase就不走了,會不會性能更差? base的順序可不可以調換?

    剛開始我想可不可以調換add方法中的判斷順序,比如,先做casBase的判斷? 仔細思考后認為還是 不調換可能更好,調換后每次都要CAS一下,在高并發(fā)時,失敗幾率非常高,并且是惡性循環(huán),比起一次判斷,后者的開銷明顯小很多,還沒有副作用(上一個問題,base變量在sum時base是會被統(tǒng)計的,并不會丟掉base的值)。因此,不調換可能會更好。

4. AtomicLong可不可以廢掉?

我的想法是可以廢掉了,因為,雖然LongAdder在空間上占用略大,但是,它的性能已經(jīng)足以說明一切了,無論是從節(jié)約空的角度還是執(zhí)行效率上,AtomicLong基本沒有優(yōu)勢了,具體看這個測試(感謝Lemon的回復):http://blog.palominolabs.com/2014/02/10/java-8-performance-improvements-longadder-vs-atomiclong/

 

(全文完)

原文鏈接:http://coolshell.cn/articles/11454.html

責任編輯:林師授 來源: 酷殼
相關推薦

2009-08-06 18:06:33

WebMethod框架

2021-02-07 09:36:20

LongAdderJDK8開發(fā)

2016-09-18 20:19:01

LinuxVimGitHub

2013-06-06 13:10:44

HashMap無鎖

2021-06-26 07:04:24

Epoll服務器機制

2010-01-14 16:35:31

C++優(yōu)化

2019-08-14 15:08:51

緩存存儲數(shù)據(jù)

2019-11-11 15:33:34

高并發(fā)緩存數(shù)據(jù)

2024-05-15 09:41:22

樂觀鎖編程

2017-12-21 14:36:10

大數(shù)據(jù)健身智慧

2018-05-08 14:58:07

戴爾

2016-10-27 17:49:07

群暉群暉科技NAS

2011-03-17 13:33:35

虛擬化網(wǎng)絡交換機H3C

2017-04-05 20:00:32

ChromeObjectJS代碼

2021-05-06 10:33:30

C++Napiv8

2024-06-11 00:01:00

并發(fā)validate場景

2019-04-19 08:47:00

前端監(jiān)控數(shù)據(jù)

2023-11-24 11:20:04

functoolsPython

2016-06-30 16:54:49

UCloud愛數(shù)云計算
點贊
收藏

51CTO技術棧公眾號

主站蜘蛛池模板: 国家aaa的一级看片 h片在线看 | 日本精品在线观看 | 在线观看av网站永久 | 日韩精品免费一区 | 欧美日韩一区二区三区视频 | 999久久久久久久久6666 | sese视频在线观看 | 国产精品一码二码三码在线 | 亚洲在线一区二区 | 五月天婷婷激情 | 成人精品国产 | 不卡一区二区三区四区 | 小草久久久久久久久爱六 | 在线资源视频 | 国产精品美女久久久 | 97视频成人 | 欧美一区二区三区在线播放 | 可以免费观看的av | 九九热这里只有精品6 | 精品国产第一区二区三区 | 日韩av在线一区二区 | 日本淫视频 | 麻豆久久久久 | 国产精品成人久久久久a级 久久蜜桃av一区二区天堂 | 亚洲一区二区三区视频免费观看 | 日韩在线视频一区 | 免费观看毛片 | 日韩欧美在线视频 | 精品1区2区3区 | 国内精品视频一区二区三区 | 日本午夜在线视频 | 亚洲欧美一区二区三区国产精品 | 色一情一乱一伦一区二区三区 | 国产剧情一区二区三区 | 亚洲一区二区三区视频在线 | 超碰成人在线观看 | 天天操天天干天天透 | 免费黄色在线观看 | 欧美日韩中文字幕在线 | 欧美一区二区三区的 | 亚洲狠狠爱一区二区三区 |