具體介紹Java8中CAS的增強

幾天前，我偶然地將之前寫的用來測試AtomicInteger和synchronized的自增性能的程式碼跑了一下，意外地發現AtomicInteger的性能比synchronized更好了，經過一番原因查找，有了如下發現：

在jdk1.7中，AtomicInteger的getAndIncrement是這樣的：

public final int getAndIncrement() {
    for (;;) {
        int current = get();
        int next = current + 1;
        if (compareAndSet(current, next))
            return current;
    }
}
public final boolean compareAndSet(int expect, int update) {
    return unsafe.compareAndSwapInt(this, valueOffset, expect, update);
}

而在jdk1.8中，是這樣的：

public final int getAndIncrement() {
    return unsafe.getAndAddInt(this, valueOffset, 1);
}

可以看出，在jdk1.8中，直接使用了Unsafe的getAndAddInt方法，而在jdk1.7的Unsafe中，沒有此方法。 （PS:為了找出原因，我反編譯了Unsafe，發現CAS的失敗重試就是在getAndAddInt方法裡完成的，我用反射獲取到Unsafe實例，編寫了跟getAndAddInt相同的程式碼，但測試結果卻跟jdk1 .7的getAndIncrement一樣慢，不知道Unsafe裡面究竟玩了什麼黑魔法，還請高人不吝指點）（補充：文章末尾已有推論）

透過查看AtomicInteger的源碼可以發現，受影響的還有getAndAdd、addAndGet等大部分方法。

有了這次對CAS的增強，我們又多了一個使用非阻塞演算法的理由。

最後給出測試程式碼，需要注意的是，此測試方法簡單粗暴，compareAndSet的性能不如synchronized，並不能簡單地說synchronized就更好，兩者的使用方式是存在差異的，而且在實際使用中，還有業務處理，不可能有如此高的競爭強度，此對比僅作為一個參考，該測試能夠證明的是，AtomicInteger.getAndIncrement的性能有了大幅提升。

package performance;

import java.util.concurrent.CountDownLatch;
import java.util.concurrent.atomic.AtomicInteger;
import java.util.concurrent.locks.LockSupport;

public class AtomicTest {
	//测试规模，调用一次getAndIncreaseX视作提供一次业务服务，记录提供TEST_SIZE次服务的耗时
	private static final int TEST_SIZE = 100000000;
	//客户线程数
	private static final int THREAD_COUNT = 10;
	//使用CountDownLatch让各线程同时开始
	private CountDownLatch cdl = new CountDownLatch(THREAD_COUNT + 1);

	private int n = 0;
	private AtomicInteger ai = new AtomicInteger(0);
	private long startTime;

	public void init() {
		startTime = System.nanoTime();
	}

	/**
	 * 使用AtomicInteger.getAndIncrement，测试结果为1.8比1.7有明显性能提升
	 * @return
	 */
	private final int getAndIncreaseA() {
		int result = ai.getAndIncrement();
		if (result == TEST_SIZE) {
			System.out.println(System.nanoTime() - startTime);
			System.exit(0);
		}
		return result;
	}

	/**
	 * 使用synchronized来完成同步，测试结果为1.7和1.8几乎无性能差别
	 * @return
	 */
	private final int getAndIncreaseB() {
		int result;
		synchronized (this) {
			result = n++;
		}
		if (result == TEST_SIZE) {
			System.out.println(System.nanoTime() - startTime);
			System.exit(0);
		}
		return result;
	}

	/**
	 * 使用AtomicInteger.compareAndSet在java代码层面做失败重试（与1.7的AtomicInteger.getAndIncrement的实现类似），
	 * 测试结果为1.7和1.8几乎无性能差别
	 * @return
	 */
	private final int getAndIncreaseC() {
		int result;
		do {
			result = ai.get();
		} while (!ai.compareAndSet(result, result + 1));
		if (result == TEST_SIZE) {
			System.out.println(System.nanoTime() - startTime);
			System.exit(0);
		}
		return result;
	}

	public class MyTask implements Runnable {
		@Override
		public void run() {
			cdl.countDown();
			try {
				cdl.await();
			} catch (InterruptedException e) {
				e.printStackTrace();
			}
			while (true)
				getAndIncreaseA();// getAndIncreaseB();
		}
	}

	public static void main(String[] args) throws InterruptedException {
		AtomicTest at = new AtomicTest();
		for (int n = 0; n < THREAD_COUNT; n++)
			new Thread(at.new MyTask()).start();
		System.out.println("start");
		at.init();
		at.cdl.countDown();
	}
}

以下是在Intel(R) Core(TM) i7-4710HQ CPU @2.50GHz（四核心八線程）下的測試結果(波動較小，所以每項只測試了四五次，取其中一個較中間的值)：

jdk1.7

AtomicInteger.getAndIncrement 12,653,757,034
synchronized 4,146,813,462#And121,compare#Atomic,comparen5#12,compare#A#12,compare#A#12.
##jdk1.8

AtomicInteger.getAndIncrement 2,159,486,620synchronized 4,067,309,911

AtomicInteger.compare安德getAndAddInt的相關原始碼以及我的測試程式碼。

用jad反編譯jdk1.8中Unsafe得到的原始碼：

public final int getAndAddInt(Object obj, long l, int i)
{
    int j;
    do
        j = getIntVolatile(obj, l);
    while(!compareAndSwapInt(obj, l, j, j + i));
    return j;
}
public native int getIntVolatile(Object obj, long l);
public final native boolean compareAndSwapInt(Object obj, long l, int i, int j);

openjdk8的Unsafe原始碼：

public final int getAndAddInt(Object o, long offset, int delta) {
    int v;
    do {
        v = getIntVolatile(o, offset);
    } while (!compareAndSwapInt(o, offset, v, v + delta));
    return v;
}
public native int     getIntVolatile(Object o, long offset);
public final native boolean compareAndSwapInt(Object o, long offset,
int expected,
int x);

我的測試程式碼(提示：如果

eclipse

等ide報錯，那是因為使用了受限的Unsafe，可以將警告級別從error降為warning，具體百度即可)：

...
import sun.misc.Unsafe;
public class AtomicTest {
	....
	private Unsafe unsafe;
	private long valueOffset;
	public AtomicTest(){
		Field f;
		try {
			f = Unsafe.class.getDeclaredField("theUnsafe");
			f.setAccessible(true);
			unsafe = (Unsafe)f.get(null);
			valueOffset = unsafe.objectFieldOffset(AtomicInteger.class.getDeclaredField("value"));
		}catch(NoSuchFieldException e){
		...
		}
	}
	private final int getAndIncreaseD(){
		int result;
		do{
			result = unsafe.getIntVolatile(ai, valueOffset);
		}while(!unsafe.compareAndSwapInt(ai, valueOffset, result, result+1));
		if(result == MAX){
			System.out.println(System.nanoTime()-startTime);
			System.exit(0);
		}
		return result;
	}
	...
}

補充2：對於性能提升的原因，有以下推論，雖不敢說百分之百正確（因為沒有用jvm的源碼作為論據），但還是有很大把握的，感謝網友@周可人和@liuxinglanyue！

Unsafe是經過特殊處理的，不能理解成常規的java程式碼，差別在於：

在呼叫getAndAddInt的時候，如果系統底層支援fetch-and-add，那麼它執行的就是native方法，使用的是fetch-and-add；

如果不支持，就按照上面的所看到的getAndAddInt方法體那樣，以java程式碼的方式去執行，使用的是compare-and-swap；

這也正好跟openjdk8中Unsafe::getAndAddInt上方的

註解

相吻合：

// The following contain CAS-based Java implementations used on
// platforms not supporting native instructions

Unsafe的特殊處理也就是我上文所說的「黑魔法」。

以上是具體介紹Java8中CAS的增強的詳細內容。更多資訊請關注PHP中文網其他相關文章！