更快的AtomicInteger

感谢同事【空蒙】的投稿

之前看了java8的longadder实现，最近又看到一篇文章介绍longadder实现的。其实现思路也是分段，最后需要get的时候，再进行sum计算。其核心思路就是减少并发，但之前老的Atomic，难道就没有提升的空间了吗？昨晚进行了一次测试。测试代码如下：

/**
* Atomically increments by one the current value.
*
*@return the updated value
*/
public final int incrementAndGet() {

  for(;;) {

   int current = get();

    int next = current + 1;

    if(compareAndSet(current, next))

    return next;

   }
}

以incrementAndGet为例，在非常高的并发下，compareAndSet会很大概率失败，因此导致了此处cpu不断的自旋，对cpu资源的浪费

既然知道此地是高并发的瓶颈，有什么办法呢？

public class AtomicBetter {

      AtomicInteger ai=new AtomicInteger();

      public int incrementAndGet() {

             for(;;) {

                    int current =ai.get();

                    int next = current + 1;

                    if(compareAndSet(current, next))

                           return next;

              }

       }

      /**

       *如果cas失败，线程park

       *@paramcurrent

       *@paramnext

       *@return

       */

      private boolean compareAndSet(intcurrent,intnext) {

             if(ai.compareAndSet(current, next)) {

                    return true;

              }else{

                     LockSupport.parkNanos(1);

                    return false;

              }

       }

}

很简单，当cas失败后，对线程park，减少多线程竞争导致的频繁cas失败，更进一步的导致cpu自旋，浪费cpu的运算能力。在4核虚拟机，Intel(R) Xeon(R) CPU E5-2630 0 @ 2.30GHz  linux 2.6.32，（注意，老版本的内核，不支持高的精度ns级） 进行测试，同样都起4个线程，每个线程里面对AtomicInteger进行5kw次的incrementAndGet。原生的AtomicInteger，耗时14232ms，进行了35870次上下文切换，总共87967770955次时钟周期。那prak 1ns下呢，耗时5195ms，进行了19779次上下文切换，总共36187480878次时钟周期，明显性能上比原生的AtomicInteger更好，那这个park多少合适呢？那就只有人肉测试了

本机环境下，park 1ms下，相对耗时，cs次数来说是最好的。因此这种优化要达到最佳效果，还要看cpu的情况而定，不是一概而定的

两个问题：

1、cas失败对线程park的副作用是什么。

2、如果park的时间继续加大，那会是这么样的结果呢。