我经常听到Java原子类型（java.util.concurrent.atomic）超级快，可以很好地与高度并发的代码一起使用。 在大多数情况下，原子以健壮和高效的方式发挥作用。 但是，在某些情况下，原子类型上非托管争用的隐藏成本成为严重的性能问题。 让我们看一下如何实现java.util.concurrent.atomic.Atomic *类型以及该设计的含义。

所有原子类型，例如AtomicLong，AtomicBoolean，AtomicReference等，本质上都是易失值的包装器。 附加值来自内部使用的sun.misc.Unsafe ，可为这些类型提供CAS功能。

本质上， CAS（比较和交换）是由现代CPU硬件实现的原子指令，它允许以安全有效的方式进行无阻塞的多线程数据操作。 与锁定相比，CAS的巨大优势在于，由于没有套利，CAS不会在内核级别上产生任何开销。 而是，编译器发出CPU指令，例如锁cmpxchg，锁xadd，锁addq等。这与从JVM角度调用指令所获得的速度一样快。

在许多情况下，低成本的CAS提供了一种有效的方法来锁定基元，但是在满足场景的情况下使用CAS的成本呈指数级增长。

Dave Dice，Danny Hendler和Ilya Mirsky在一项非常有趣的研究中对这个问题进行了研究 。 我强烈建议您阅读全文，因为它比这篇简短的文章包含了更多有价值的信息。

我从论文中复制了一些概念，并对其进行了测试。 由于人们对原子（CAS）性能存在普遍的误解，因此许多Java程序员应该发现结果很能说明问题。

实现退避竞争管理的代码非常简单。 它回退了很短的时间，而不是遍历失败的比较和交换，让其他线程尝试更新。

import java.util.concurrent.atomic.AtomicLong;
import java.util.concurrent.locks.LockSupport;public class BackOffAtomicLong {public static long bk;private final AtomicLong value = new AtomicLong(0L);public long get() {return value.get();}public long incrementAndGet() {for (;;) {long current = get();long next = current + 1;if (compareAndSet(current, next))return next;}}public boolean compareAndSet(final long current, final long next) {if (value.compareAndSet(current, next)) {return true;} else {LockSupport.parkNanos(1L);return false;}}public void set(final long l) {value.set(l);}}

该测试是在64位Linux 3.5.0（x86_64）和Intel®CoreTM i7-3632QM CPU @ 2.20GHz（8个逻辑内核）上使用64位Hotspot Java 1.7.0_25-b15执行的。

不出所料，对于高负载争用，两种实现之间没有太大的区别：

但是，在商店竞争激烈的情况下，它变得更加有趣。 这种情况暴露了Hotspot的AtomicLong实现所采用的乐观重试方法的弱点。

同样，在读写器混合竞争的情况下，轻量级访问管理的好处也显而易见。

当涉及套接字间通信时，结果会有很大的不同，但是不幸的是，我在某种程度上失去了针对基于Intel Xeon的硬件进行测试的输出。 随时发布不同架构/ JVM的结果。

翻译自: https://www.javacodegeeks.com/2014/01/want-to-get-faster-with-atomiclong-make-it-wait.html