java中Atomic变量的实现原理是怎样的？
关注者
21
被浏览
1,546
关注问题写回答
添加评论
分享
邀请回答
5 个回答
默认排序
高级工程师，Coder，Teamleader
1 人赞同了该回答
这个问题我刚好研究过，还写了一篇文章：
Alex Wang：Java Concurrency代码实例之三原子变量zhuanlan.zhihu.com
赞同 11 条评论
分享
收藏感谢
3 人赞同了该回答
去看API会发现调用了sun的Unsafe类，顾名思义，Unsafe类中包含了很多Java认为不安全的操作，比如内存的直接分配等，Unsafe类还有一个compareAndSwapXX方法，它会调用底层的native方法，而这个native方法就是由现代大多数CPU都支持的CAS(Compare And Swap,比较并交换)指令提供硬件支持。典型的CAS操作有三个操作值:期望值:e,新值:n，以及内存中的实际值:x。首先检查e和x是否相等，如果不相等则线程自旋等待，如果相等则设置并返回。具体参加java.util.atomic。
赞同 3添加评论
分享
收藏感谢
知乎用户
1 人赞同了该回答
AtomicInteger
AtomicInteger中的incrementAndGet方法就是乐观锁的一个实现，使用自旋（循环检测更新）的方式来更新内存中的值并通过底层CPU执行来保证是更新操作是原子操作。方法如下：
public final int getAndAddInt(Object var1, long var2, int var4) {
int var5;
do {
var5 = this.getIntVolatile(var1, var2);
} while(!this.compareAndSwapInt(var1, var2, var5, var5 + var4));
//可以看做compareAndSwapInt(obj, offset, expect, update)
return var5;
}
首先这个方法通过getIntVolatile方法，使用对象的引用与值的偏移量得到当前值，然后调用compareAndSwapInt检测如果obj内的value和expect相等，就证明没有其他线程改变过这个变量，那么就更新它为update，如果这一步的CAS没有成功，那就采用自旋的方式继续进行CAS操作。
在赋值的时候保证原子操作的原理是通过CPU的cmpxchgl与lock指令的支持来实现AtomicInteger的CAS操作一定程度上的原子性，具体可参考这里，https://juejin.im/post/5a73cbbff265da4e807783f5
疑问：这个方法是先得到值，再更新值，所以必须保证更新的值是在原来的基础上更新的，所以采用CAS进行更新，那么为什么不使用直接更新值然后返回值的方式来做呢？因为更新值的前提是获取值，这是两部汇编级别的操作，仅仅更新值是无法获取到值的。
ABA问题
上面提到过lock指令，它能保证其他CPU无法参与进来，但是无法保证单个CPU的另一个线程执行更新操作。所以如果一个值原来是A，变成了B，又变成了A，那么使用CAS进行检查时会发现它的值没有发生变化，但是实际上却变化了。这就是CAS的ABA问题。
常见的解决思路是使用版本号。在变量前面追加上版本号，每次变量更新的时候把版本号加一，那么A-B-A 就会变成1A-2B-3A。
AtomicStampedReference来解决ABA问题。这个类的compareAndSet方法作用是首先检查当前引用是否等于预期引用，并且当前标志是否等于预期标志，如果全部相等，则以原子方式将该引用和该标志的值设置为给定的更新值。
循环时间长开销大问题
上面我们说过如果CAS不成功，则会原地自旋，如果长时间自旋会给CPU带来非常大的执行开销。
来源：http://www.wangtianyi.top/blog/2018/04/28/javagao-bing-fa-xi-lie-er-:xian-cheng-an-quan-xing/
赞同 1添加评论
分享
收藏感谢收起
程序员
1 人赞同了该回答
基于底层硬件的CAS做的。
赞同 1添加评论
分享
收藏感谢
IT行业
Atomic简介
Atomic包是java.util.concurrent下的另一个专门为线程安全设计的Java包，包含多个原子操作类。这个包里面提供了一组原子变量类。其基本的特性就是在多线程环境下，当有多个线程同时执行这些类的实例包含的方法时，具有排他性，即当某个线程进入方法，执行其中的指令时，不会被其他线程打断，而别的线程就像自旋锁一样，一直等到该方法执行完成，才由JVM从等待队列中选择一个另一个线程进入，这只是一种逻辑上的理解。实际上是借助硬件的相关指令来实现的，不会阻塞线程(或者说只是在硬件级别上阻塞了)。可以对基本数据、数组中的基本数据、对类中的基本数据进行操作。原子变量类相当于一种泛化的volatile变量，能够支持原子的和有条件的
传统锁的问题
我们先来看一个例子：计数器（Counter），采用Java里比较方便的锁机制synchronized关键字，初步的代码如下：
- class Counter {
- private int value;
- public synchronized int getValue() {
- return value;
- }
- public synchronized int increment() {
- return ++value;
- }
- public synchronized int decrement() {
- return --value;
- }
- }
其实像这样的锁机制，满足基本的需求是没有问题的了，但是有的时候我们的需求并非这么简单，我们需要更有效，更加灵活的机制，synchronized关键字是基于阻塞的锁机制，也就是说当一个线程拥有锁的时候，访问同一资源的其它线程需要等待，直到该线程释放锁，这里会有些问题：首先，如果被阻塞的线程优先级很高很重要怎么办？其次，如果获得锁的线程一直不释放锁怎么办？（这种情况是非常糟糕的）。还有一种情况，如果有大量的线程来竞争资源，那CPU将会花费大量的时间和资源来处理这些竞争（事实上CPU的主要工作并非这些），同时，还有可能出现一些例如死锁之类的情况，最后，其实锁机制是一种比较粗糙，粒度比较大的机制，相对于像计数器这样的需求有点儿过于笨重，因此，对于这种需求我们期待一种更合适、更高效的线程安全机制。
硬件同步策略
现在的处理器都支持多重处理，当然也包含多个处理器共享外围设备和内存，同时，加强了指令集以支持一些多处理的特殊需求。特别是几乎所有的处理器都可以将其他处理器阻塞以便更新共享变量。
Compare and swap(CAS)
当前的处理器基本都支持CAS，只不过每个厂家所实现的算法并不一样罢了，每一个CAS操作过程都包含三个运算符：一个内存地址V，一个期望的值A和一个新值B，操作的时候如果这个地址上存放的值等于这个期望的值A，则将地址上的值赋为新值B，否则不做任何操作。CAS的基本思路就是，如果这个地址上的值和期望的值相等，则给其赋予新值，否则不做任何事儿，但是要返回原值是多少。我们来看一个例子，解释CAS的实现过程（并非真实的CAS实现）：
- class SimulatedCAS {
- private int value;
- public synchronized int getValue() {
- return value;
- }
- public synchronized int compareAndSwap(int expectedValue, int newValue) {
- int oldValue = value;
- if (value == expectedValue)
- value = newValue;
- return oldValue;
- }
- }
下面是一个用CAS实现的Counter
- public class CasCounter {
- private SimulatedCAS value;
- public int getValue() {
- return value.getValue();
- }
- public int increment() {
- int oldValue = value.getValue();
- while (value.compareAndSwap(oldValue, oldValue + 1) != oldValue)
- oldValue = value.getValue();
- return oldValue + 1;
- }
- }
Atomic类
在JDK5.0之前，想要实现无锁无等待的算法是不可能的，除非用本地库，自从有了Atomic变量类后，这成为可能。下面这张图是java.util.concurrent.atomic包下的类结构。
- 标量类：AtomicBoolean，AtomicInteger，AtomicLong，AtomicReference
- 数组类：AtomicIntegerArray，AtomicLongArray，AtomicReferenceArray
- 更新器类：AtomicLongFieldUpdater，AtomicIntegerFieldUpdater，AtomicReferenceFieldUpdater
- 复合变量类：AtomicMarkableReference，AtomicStampedReference
第一组AtomicBoolean，AtomicInteger，AtomicLong，AtomicReference这四种基本类型用来处理布尔，整数，长整数，对象四种数据，其内部实现不是简单的使用synchronized，而是一个更为高效的方式CAS (compare and swap) + volatile和native方法，从而避免了synchronized的高开销，执行效率大为提升。我们来看个例子，与我们平时i++所对应的原子操作为：getAndIncrement()
- public static void main(String[] args) {
- AtomicInteger ai = new AtomicInteger();
- System.out.println(ai);
- ai.getAndIncrement();
- System.out.println(ai);
- }
我们可以看一下AtomicInteger的实现：
- /**
- * Atomically increments by one the current value.
- *
- * @return the previous value
- */
- public final int getAndIncrement() {
- return unsafe.getAndAddInt(this, valueOffset, 1);
- }
这里直接调用一个叫Unsafe的类去处理，看来我们还需要继续看一下unsafe类的源码了。JDK8中sun.misc下UnSafe类，
从源码注释得知，这个类是用于执行低级别、不安全操作的方法集合。尽管这个类和所有的方法都是公开的（public），但是这个类的使用仍然受限，你无法在自己的java程序中直接使用该类，因为只有授信的代码才能获得该类的实例。所以我们平时的代码是无法使用这个类的，因为其设计的操作过于偏底层，如若操作不慎可能会带来很大的灾难，所以直接禁止普通代码的访问，当然JDK使用是没有问题的。
Atomic中的CAS
从前面的解释得知，CAS的原理是拿期望的值和原本的一个值作比较，如果相同则更新成新的值，此处这个“原本的一个值”怎么来，我们看看AtomicInteger里的实现：
- // setup to use Unsafe.compareAndSwapInt for updates
- private static final Unsafe unsafe = Unsafe.getUnsafe();
- private static final long valueOffset;
- static {
- try {
- valueOffset = unsafe.objectFieldOffset
- (AtomicInteger.class.getDeclaredField("value"));
- } catch (Exception ex) { throw new Error(ex); }
- }
- /**
- * Report the location of a given static field, in conjunction with {@link
- * #staticFieldBase}.
- * <p>Do not expect to perform any sort of arithmetic on this offset;
- * it is just a cookie which is passed to the unsafe heap memory accessors.
- *
- * <p>Any given field will always have the same offset, and no two distinct
- * fields of the same class will ever have the same offset.
- *
- * <p>As of 1.4.1, offsets for fields are represented as long values,
- * although the Sun JVM does not use the most significant 32 bits.
- * It is hard to imagine a JVM technology which needs more than
- * a few bits to encode an offset within a non-array object,
- * However, for consistency with other methods in this class,
- * this method reports its result as a long value.
- * @see #getInt(Object, long)
- */
- public native long objectFieldOffset(Field f);
这个方法是用来拿到我们上文提到的这个“原来的值”的内存地址。是一个本地方法，返回值是valueOffset。它的参数field就是AtomicInteger里定义的value属性：
- private volatile int value;
- /**
- * Creates a new AtomicInteger with the given initial value.
- *
- * @param initialValue the initial value
- */
- public AtomicInteger(int initialValue) {
- value = initialValue;
- }
- /**
- * Creates a new AtomicInteger with initial value {@code 0}.
- */
- public AtomicInteger() {
- }
value是一个volatile变量，在内存中可见，任何线程都不允许对其进行拷贝，因此JVM可以保证任何时刻任何线程总能拿到该变量的最新值。此处value的值，可以在AtomicInteger类初始化的时候传入，也可以留空，留空则自动赋值为0。
我们再回到CAS，看看getAndIncrement()方法是怎么利用CAS实现的。
- /**
- * Atomically increments by one the current value.
- *
- * @return the previous value
- */
- public final int getAndIncrement() {
- return unsafe.getAndAddInt(this, valueOffset, 1);
- }
继续：
- public final int getAndAddInt(Object o, long offset, int delta) {
- int v;
- do {
- v = getIntVolatile(o, offset);//------------0---------------
- } while (!compareAndSwapInt(o, offset, v, v + delta));//-------------1-------------
- return v;
- }
- /**
- * Atomically update Java variable to <tt>x</tt> if it is currently
- * holding <tt>expected</tt>.
- * @return <tt>true</tt> if successful
- */
- public final native boolean compareAndSwapInt(Object o, long offset,//---------------2--------------
- int expected,
- int x);
我稍微解释一下，其实compareAndSwapInt的注释解释的很明确，原子的将变量的值更新为x，如果成功了返回true，我们知道，如果我们创建AtomicInteger实例时不传入参数，则原始变量的值即为0，所以上面//----------0-----------处得到的v的值即为0,1处的代码为：
while(!compareAndSwapInt(o, offset, 0, 1))我们知道offset指向的地址对应的值就是原始变量的初值0，所以与期望的值0相同，所以将初值赋值为1，返回true，取反后为false，循环结束，返回v即更新之前的值0. 这就是类似于i++操作的原子操作的实现，当然最终CAS的实现都是native的，用C语言实现的，我们这里看不到源码，有时间我会反编译一下这段代码看看。
CAS线程安全
说了半天，我们要回归到最原始的问题了：这样怎么实现线程安全呢？请大家自己先考虑一下这个问题，其实我们在语言层面是没有做任何同步的操作的，大家也可以看到源码没有任何锁加在上面，可它为什么是线程安全的呢？这就是Atomic包下这些类的奥秘：语言层面不做处理，我们将其交给硬件—CPU和内存，利用CPU的多处理能力，实现硬件层面的阻塞，再加上volatile变量的特性即可实现基于原子操作的线程安全。所以说，CAS并不是无阻塞，只是阻塞并非在语言、线程方面，而是在硬件层面，所以无疑这样的操作会更快更高效！
总结
虽然基于CAS的线程安全机制很好很高效，但要说的是，并非所有线程安全都可以用这样的方法来实现，这只适合一些粒度比较小，型如计数器这样的需求用起来才有效，否则也不会有锁的存在了。
有问题请随时联系我，我会及时回复，欢迎一起探讨！
8680
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
