JVM原子操作的实现与一点改进想法

"原子操作（atomic operation）是不需要synchronized"，这是Java多线程编程的老生常谈了。所谓原子操作是指不会被线程调度机制打断的操作；这种操作一旦开始，就一直运行到结束，中间不会有任何 context switch （切换到另一个线程）。原子操作是不可分割的，在执行完毕之前不会被任何其它任务或事件中断。

在单处理器系统（UniProcessor）中，能够在单条指令中完成的操作都可以认为是" 原子操作"，因为中断只能发生于指令之间。但是，在对称多处理器（Symmetric Multi-Processor）结构中就不同了，由于系统中有多个处理器在独立地运行，即使能在单条指令中完成的操作也有可能受到干扰。

在x86 平台上，CPU提供了在指令执行期间对总线加锁的手段。CPU芯片上有一条引线#HLOCK pin，如果汇编语言的程序中在一条指令前面加上前缀"LOCK"，经过汇编以后的机器代码就使CPU在执行这条指令的时候把#HLOCK pin的电位拉低，持续到这条指令结束时放开，从而把总线锁住，这样同一总线上别的CPU就暂时不能通过总线访问内存了，保证了这条指令在多处理器环境中的原子性。

那么原子操作到底用在哪里呢，下面先从一个简单的JAVA例子入手：

3 import java.util.concurrent.atomic.*;

4

5 public class VolatileTest

6 {

7 public static volatile int race = 0;

8 final static AtomicInteger value = new AtomicInteger(0);

9 public static void increase()

10 {

11 value.incrementAndGet();

12 race++;

13 }

14 private static final int THREADS_COUNT = 20;

15

16 public static void main(String[] args)

17 {

18 Thread[] threads = new Thread[THREADS_COUNT];

19 for (int i=0; i<THREADS_COUNT; i++)

20 {

21 threads[i] = new Thread(new Runnable() {

22 @Override

23 public void run() {

24 for (int i=0; i<10000; i++)

25 {

26 increase();

27 }

28 }

29 });

30 threads[i].start();

31 }

32

33 while (Thread.activeCount() > 1)

34 Thread.yield();

35

36 System.out.println(race);

37 System.out.println(value.get());

38 }

39 }

上面例子的执行结果是：

195333

200000

不过多运行几次大家就会发现race的值并不固定，因为increase方法没有加synchronized，但是value的值每次都能保证正确，这是因为value用到了原子操作。到这里大家又要问了，既然synchronized可以保障同步，那么要原子操作干啥，这个是处于效率考虑，大量的线程切换会带来效率上的损失，或许jvm对于synchronized做了一些优化，但是也很难达到原子的效率，再者，为了一个变量的++就考虑使用全方法甚至全对象synchronized是不是太奢侈了。

下面我们来剖析一下incrementAndGet的实现，incrementAndGet->compareAndSet->compareAndSwapInt->Unsafe_CompareAndSwapInt
->Atomic::cmpxchg

public final int incrementAndGet() {

for (;;) {

int current = get(); // 获得value当前值

int next = current + 1;

if (compareAndSet(current, next)) // 此方法比较current跟此时对象value值，如果相等，将next的值赋值给value；如果不相等，说明正在有人改变value，则返回FALSE，循环下次继续

return next;

}

}

public final boolean compareAndSet(int expect, int update) {

return unsafe.compareAndSwapInt(this, valueOffset, expect, update);

}

//比较成功，此函数即返回TRUE

UNSAFE_ENTRY(jboolean, Unsafe_CompareAndSwapInt(JNIEnv *env, jobject unsafe, jobject obj, jlong offset, jint e, jint x))

UnsafeWrapper("Unsafe_CompareAndSwapInt");

oop p = JNIHandles::resolve(obj);

jint* addr = (jint *) index_oop_from_field_offset_long(p, offset);

return (jint)(Atomic::cmpxchg(x, addr, e)) == e;

inline jint Atomic::cmpxchg (jint exchange_value, volatile jint* dest, jint compare_value) {

// alternative for InterlockedCompareExchange

int mp = os::is_MP();

__asm {

mov edx, dest

mov ecx, exchange_value

mov eax, compare_value // eax一般存放函数返回值，即compare_value为返回值

LOCK_IF_MP(mp)

cmpxchg dword ptr [edx], ecx // [edx]与eax如果相等，ecx->[edx]；否则[edx]->eax

}

}

以上是几个主要函数，前面两个JAVA代码方法应该不是难懂，compareAndSwapInt到 Unsafe_CompareAndSwapInt 已经不是直接的调用关系了，这一步是JVM的解释器进行的，也就是说Unsafe_CompareAndSwapInt以下就不是java的代码了。两个c++、汇编实现的函数也不是太难理解，其实在X86下就是使用cmpxchg指令实现CAS(比较并交换)，不过LOCK_IF_MP这个宏用的还是很精炼的，为了让大家加深Atomic的理解，我们再看一下Atomic中inc（实现原子的++操作）的代码，这个相对简单些：

#define LOCK_IF_MP(mp) __asm cmp mp, 0 \ // mp与0比较

__asm je L0 \ // mp为0则跳到L0标记

__asm _emit 0xF0 \ // _emit伪指令，作用嵌入0xF0到当前代码处，0xF0其实就是lock指令的机器码

__asm L0:

inline void Atomic::inc (volatile jint* dest)

{

// alternative for InterlockedIncrement

int mp = os::is_MP(); // 判断是否为对称多处理器（0为单核，1为多核）

__asm // C/C++中嵌入汇编

{

mov edx, dest; // 地址赋值给edx寄存器

LOCK_IF_MP(mp) // 宏（用法类似函数），详见上面注释

add dword ptr [edx], 1; // [edx]加1

}

}

有了上面的注释，这段代码应该不难理解，效果等价于以下伪代码：

If (单核)

｛

__asm // C/C++中嵌入汇编

{

mov edx, dest; // 地址赋值给edx寄存器

add dword ptr [edx], 1; // [edx]加1

}

｝

else

{

__asm // C/C++中嵌入汇编

{

mov edx, dest; // 地址赋值给edx寄存器

lock add dword ptr [edx], 1; // [edx]加1

}

}

或许90%的以上的汇编程序员能写出此伪码，但是只有不到10%的程序员会想到用_emit 嵌入指令，很不幸的是，我也在这90%之中，万幸的是，当我第一次看到此代码，立刻就意识到0xF0是lock的机器码。

除了直接提供给java使用之外，Atomic还充斥着jvm的几乎任何其他地方，只是我们平时没注意罢了，可以这样认为，我们的java代码运行时无时无刻都有大量Atomic的方法被调用，也即无时无刻都有大量LOCK_IF_MP被调用（宏毕竟不是函数，这里讲调用不是很恰当，知其意即可），这样就带来了这样一个思索，LOCK_IF_MP这个宏的确写的不错，但是这或许不是一个最恰当的方法，个人认为，在我们java程序运行的时候一般不会发生CPU核心数变化的情况，完全可以使用预编译方式来代替这个无时无刻都要进行的判断，换句话说，单核上使用单核原子版本，多核上使用多核原子版本，在我们安装jdk的时候判断CPU核心数然后安装相应版本就可以了。

后记：如果大家仔细看到这里，会发现一个问题，java中所谓的原子++实际上使用的是CAS，即类似自旋锁之类的机制，而C++中实现原子++并不依赖CAS，很显然，后者效率更高一些，至于为何java中AtomicInteger不用后者的方式来实现原子++，或许是解释执行的时候技术所限，这点需要我们有时间去继续挖掘了。