LongAdder介紹
之前有篇文章講過AtomicLong通過CAS提供了非阻塞的原子性操作瘾带，相比使用阻塞算法的同步器來說它的性能已經(jīng)很好了，但是JDK開發(fā)組并不滿足于此进每。使用AtomicLong時询刹，在高并發(fā)下大量線程會同時去競爭更新同一個原子變量烘跺，但是由于同時只有一個線程的CAS操作會成功，這就造成了大量線程競爭失敗后返弹，會通過無限循環(huán)不斷進行自旋嘗試CAS操作锈玉，而這會白白浪費CPU資源。
因此JDK8新增了一個原子性遞增或者遞減類LongAdder用來克服在高并發(fā)下使用AtomicLong的缺點义起。既然AtomicLong的性能瓶頸是由于多線程同時去競爭一個變量的更新而產(chǎn)生的嘲玫，那么如果把一個變量分解為多個變量，讓同樣多的線程去競爭多個資源并扇，是不是就解決了性能問題去团？是的，LongAdder就是這個思路穷蛹。下面通過一張的圖來理解兩者設計的不同之處土陪。
上圖為使用AtomicLong時，是多個線程同時競爭一個原子變量肴熏。
上圖所示鬼雀，使用LongAdder時，則是在內部維護多個Cell變量蛙吏，每個Cell里面有一個初始值為0的long類型變量源哩，這樣，在同等并發(fā)量的情況下鸦做，爭奪單個變量更新操作的線程就會減少励烦，這變相地減少了爭奪共享資源的并發(fā)量。另外泼诱，多個線程在爭奪同一個Cell原子變量時如果失敗了坛掠，它并不是在當前Cell變量上一直自旋CAS重試，而是嘗試在其他Cell的變量上進行CAS嘗試治筒，這個改變增加了當前線程重試CAS成功的可能性屉栓。最后在獲取LongAdder當前值時，是把所有Cell變量的value值累加后再加上base返回的耸袜。
LongAdder維護了一個延遲初始化的原子性更新數(shù)組(默認情況下Cell數(shù)組是null)和一個基值變量base友多。由于Cells占用的內存是相對比較大的，所以一開始并不創(chuàng)建它堤框，而是在需要創(chuàng)建時域滥，也就是懶加載纵柿。
當一開始判斷Cell數(shù)組是null并且并發(fā)較少時，所有的累加操作都是對base變量進行的骗绕。保持Cell數(shù)組的大小為2的N次方藐窄，在初始化時Cell數(shù)組中的Cell元素個數(shù)為2资昧，數(shù)組里面的變量實體是Cell類型酬土。Cell類型是AtomicLong的一個改進，用來減少緩存的征用格带，也就是解決偽共享問題撤缴。
對于大多數(shù)孤立的多個原子操作進行字節(jié)填充是浪費的，原因原子性操作都是無規(guī)律地分散在內存中的(也就是說多個原子性變量的內存地址不是連續(xù)的)叽唱，多個原子變量被放入同一個緩存行的可能性很小屈呕。但是原子性數(shù)組的內存地址是連續(xù)的，所對數(shù)組內多個元素能經(jīng)常共享緩存行棺亭，因此這里使用@sun.misc.Contended注解對Cell類進行字節(jié)填充虎眨，這放置了數(shù)組中多個元素共享一個緩存行，在性能上是一個提升镶摘。
