當(dāng)然，聰明之處遠(yuǎn)遠(yuǎn)不僅僅這里，在看看add方法中的代碼，casBase方法可不可以不要，直接分段更新,上來就計(jì)算 索引位置，然后更新value？

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

但是，Doung Lea 還是沒這么簡單，聰明之處還沒有結(jié)束……

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

因此，retryUpdate里面應(yīng)該會做兩件事：

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

是不是這樣呢？ 繼續(xù)看代碼：

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

final void retryUpdate(long x, HashCode hc, boolean wasUncontended) {   
      int h = hc.code;   
      boolean collide = false;                // True if last slot nonempty   
      for (;;) {   
          Cell[] as; Cell a; int n; long v;   
          if ((as = cells) != null && (n = as.length) > 0) {// 分支1   
              if ((a = as[(n - 1) & h]) == null) {   
                  if (busy == 0) {            // Try to attach new Cell   
                      Cell r = new Cell(x);   // Optimistically create   
                      if (busy == 0 && casBusy()) {   
                          boolean created = false;   
                          try {               // Recheck under lock   
                              Cell[] rs; int m, j;   
                              if ((rs = cells) != null &&   
                                      (m = rs.length) > 0 &&   
                                      rs[j = (m - 1) & h] == null) {   
                                  rs[j] = r;   
                                  created = true;   
                              }   
                          } finally {   
                              busy = 0;   
                          }   
                          if (created)   
                              break;   
                          continue;           // Slot is now non-empty   
                      }   
                  }   
                  collide = false;   
              }   
              else if (!wasUncontended)       // CAS already known to fail   
                  wasUncontended = true;      // Continue after rehash   
              else if (a.cas(v = a.value, fn(v, x)))   
                  break;   
              else if (n >= NCPU || cells != as)   
                  collide = false;            // At max size or stale   
              else if (!collide)   
                  collide = true;   
              else if (busy == 0 && casBusy()) {   
                  try {   
                      if (cells == as) {      // Expand table unless stale   
                          Cell[] rs = new Cell[n << 1];   
                          for (int i = 0; i < n; ++i)   
                              rs[i] = as[i];   
                          cells = rs;   
                      }   
                  } finally {   
                      busy = 0;   
                  }   
                  collide = false;   
                  continue;                   // Retry with expanded table   
              }   
              h ^= h << 13;                   // Rehash  h ^= h >>> 17;   
              h ^= h << 5;   
          }   
          else if (busy == 0 && cells == as && casBusy()) {//分支2   
              boolean init = false;   
              try {                           // Initialize table   
                  if (cells == as) {   
                      Cell[] rs = new Cell[2];   
                      rs[h & 1] = new Cell(x);   
                      cells = rs;   
                      init = true;   
                  }   
              } finally {   
                  busy = 0;   
              }   
              if (init)   
                  break;   
          }   
          else if (casBase(v = base, fn(v, x)))   
              break;                          // Fall back on using base   
      }   
      hc.code = h;                            // Record index for next time   
  } 

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

分支1分支中，略復(fù)雜一點(diǎn)點(diǎn)：

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

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

否則更新 標(biāo)示沖突的標(biāo)志位wasUncontended 為 true ，重試。

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

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

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

#p#

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

***留給大家思考的兩個(gè)問題：

1）是不是AtomicLong可以被廢了？

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

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

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

我們 發(fā)現(xiàn)的問題有這么幾個(gè)（包括以上的問題），自己簡單總結(jié)下，歡迎大家討論：

1. jdk 1.7中是不是有這個(gè)類？

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

2. base有沒有參與匯總？

base在調(diào)用intValue等方法的時(shí)候是會匯總的：

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

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

4. AtomicLong可不可以廢掉？

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

（全文完）

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