背景

近年來，在并發(fā)算法領(lǐng)域的大多數(shù)研究都側(cè)重于非阻塞算法，這種算法用底層的原子機(jī)器指令（例如比較并發(fā)交換指令）代替鎖來確保數(shù)據(jù)在并發(fā)訪問中的一致性。非阻塞算法被廣泛的用于在操作系統(tǒng)和JVM中實(shí)現(xiàn)線程/進(jìn)程調(diào)度機(jī)制、垃圾回收機(jī)制以及鎖和其他并發(fā)數(shù)據(jù)結(jié)構(gòu)。

與基于鎖的方案相比，非阻塞算法在設(shè)計(jì)和實(shí)現(xiàn)上都要復(fù)雜的多，但他們在可伸縮性和活躍性上卻擁有巨大的優(yōu)勢，由于非阻塞算法可以使多個(gè)線程在競爭相同數(shù)據(jù)時(shí)不會(huì)發(fā)生阻塞，因此它能在粒度更細(xì)的層次上面進(jìn)行協(xié)調(diào)，并且極大的減少調(diào)度開銷。鎖雖然Java語言鎖定語法比較簡潔，但JVM操作和管理鎖時(shí)，需要完成的工作缺并不簡單，在實(shí)現(xiàn)鎖定時(shí)需要遍歷JVM中一條復(fù)雜的代碼路徑，并可能導(dǎo)致操作系統(tǒng)級的鎖定、線程掛起以及上下文切換等操作。

非阻塞算法

在基于鎖的算法中可能會(huì)發(fā)生各種活躍性故障，如果線程在持有鎖時(shí)由于阻塞I/O，內(nèi)存頁缺失或其他延遲執(zhí)行，那么很可能所有線程都不能繼續(xù)執(zhí)行下去。如果在某種算法中，一個(gè)線程的失敗或掛起不會(huì)導(dǎo)致其他線程也失敗或掛起，那么這種算法就稱為非阻塞算法。如果在算法的每個(gè)步驟中都存在某個(gè)線程能夠執(zhí)行下去，那么這種算法也被稱為無鎖算法。如果在算法中僅將CAS用于協(xié)調(diào)線程之間的操作，并且能夠正確的實(shí)現(xiàn)，那么他既是一種無阻塞算法，又是一種無鎖算法。

Java對非阻塞算法的支持：從Java5.0開始，底層可以使用原子變量類（例如AtomicInteger和AtoMicReference）來構(gòu)建高效的非阻塞算法，底層實(shí)現(xiàn)采用的是一個(gè)比較并交換指令（CAS）。

比較并交換（CAS）

CAS包括了三個(gè)操作數(shù)，需要讀寫的內(nèi)存位置V，進(jìn)行比較的值A(chǔ)和擬寫入的新值B。當(dāng)且僅當(dāng)V的值等于A時(shí)，CAS才會(huì)通過原子方式用新值B來更新A的值，否則不會(huì)執(zhí)行任何操作。無論V的值是否等于A，都將返回V原有的值。CAS的含義是：我認(rèn)為V的值應(yīng)該是A，如果是那么將V的值更新為B，否則不修改并告訴V的值實(shí)際為多少。

原子變量類

原子變量（對應(yīng)內(nèi)存模型中的原子性）比鎖的粒度更細(xì)。量級更輕，并且對于在多處理器系統(tǒng)上實(shí)現(xiàn)高性能的并發(fā)代碼來說是非常關(guān)鍵的。原子變量將發(fā)生競爭的范圍縮小到單個(gè)變量上面，這是你獲得的粒度最細(xì)的情況。更新原子變量的快速（非競爭）路徑不會(huì)被獲得鎖的快速路徑慢，并且通常會(huì)更快，而它的慢速路徑肯定比鎖的慢速路徑塊，因?yàn)樗恍枰獟炱鸹蛘咧匦抡{(diào)度線程。在使用基于原子變量而非鎖的算法中，線程在執(zhí)行時(shí)更不易出現(xiàn)延遲，并且如果遇到競爭，也更容易恢復(fù)過來。

Java中的13個(gè)原子操作類

Java從JDK1.5開始提供了java.util.concurrent.atomic包（以下簡稱Atomic包），這個(gè)包中的原子操作類提供了一種用法簡單、性能高效、線程安全地更新一個(gè)變量的方式。因?yàn)樽兞康念愋陀泻芏喾N，所以在Atomic包里一共提供了13個(gè)類，屬于4種類型的原子更新方式，分別是原子更新基本類型、原子更新數(shù)組、原子更新引用和原子更新屬性（字段）。Atomic包里的類基本都是使用Unsafe實(shí)現(xiàn)的包裝類。

• 原子更新基本類型類
  

使用原子的方式更新基本類型，Atomic包提供了以下3個(gè)類。

1.AtomicBoolean：原子更新布爾類型。
2.AtomicInteger：原子更新整型。
3.AtomicLong：原子更新長整型。

• 原子更新數(shù)組
  

通過原子的方式更新數(shù)組里的某個(gè)元素，Atomic包提供了以下4個(gè)類。

1.AtomicIntegerArray：原子更新整型數(shù)組里的元素。
2.AtomicLongArray：原子更新長整型數(shù)組里的元素。
3.AtomicReferenceArray：原子更新引用類型數(shù)組里的元素。

• 原子更新引用類型
  

原子更新基本類型的AtomicInteger，只能更新一個(gè)變量，如果要原子更新多個(gè)變量，就需要使用這個(gè)原子更新引用類型提供的類。Atomic包提供了以下3個(gè)類。

1.AtomicReference：原子更新引用類型。
2.AtomicReferenceFieldUpdater：原子更新引用類型里的字段。
3.AtomicMarkableReference：原子更新帶有標(biāo)記位的引用類型?？梢栽痈乱粋€(gè)布爾類型的標(biāo)記位和引用類型。構(gòu)造方法是AtomicMarkableReference（V initialRef，booleaninitialMark）。

• 原子更新字段類
  

如果需原子地更新某個(gè)類里的某個(gè)字段時(shí)，就需要使用原子更新字段類，Atomic包提供了以下3個(gè)類進(jìn)行原子字段更新。

1.AtomicIntegerFieldUpdater：原子更新整型的字段的更新器。
2.AtomicLongFieldUpdater：原子更新長整型字段的更新器。
3.AtomicStampedReference：原子更新帶有版本號(hào)的引用類型。該類將整數(shù)值與引用關(guān)聯(lián)起來，可用于原子的更新數(shù)據(jù)和數(shù)據(jù)的版本號(hào)，可以解決使用CAS進(jìn)行原子更新時(shí)可能出現(xiàn)的
4.ABA問題。

AtomicLong源碼分析

上面的4種原子類型都是基于CAS實(shí)現(xiàn)，低層借助于unsafe實(shí)現(xiàn)原子操作。接下來結(jié)合源碼，看一下比較有代表性的AtomicLong源碼

初始化

//保存AtomicLong的實(shí)際值，用volatile 修飾保證可見性
private volatile long value;
 
// 獲取value的內(nèi)存地址的邏輯操作
  static {
    try {
      valueOffset = unsafe.objectFieldOffset
        (AtomicLong.class.getDeclaredField("value"));
    } catch (Exception ex) { throw new Error(ex); }
  }
 
 
//根據(jù)傳入的參數(shù)初始化實(shí)際值，默認(rèn)值為0
public AtomicLong(long initialValue) {
    value = initialValue;
  }

接下來我們主要看一下幾個(gè)更新方法

//以原子方式更新值為傳入的newValue，并返回更新之前的值
public final long getAndSet(long newValue) {
    return unsafe.getAndSetLong(this, valueOffset, newValue);
  }
 
 
//輸入期望值和更新值，如果輸入的值等于預(yù)期值，則以原子方式更新該值為輸入的值
public final boolean compareAndSet(long expect, long update) {
    return unsafe.compareAndSwapLong(this, valueOffset, expect, update);
  }
 
//返回當(dāng)前值原子加1后的值
public final long getAndIncrement() {
    return unsafe.getAndAddLong(this, valueOffset, 1L);
  }
 
//返回當(dāng)前值原子減1后的值
public final long getAndDecrement() {
    return unsafe.getAndAddLong(this, valueOffset, -1L);
  }
 
//返回當(dāng)前值原子增加delta后的值
public final long getAndAdd(long delta) {
    return unsafe.getAndAddLong(this, valueOffset, delta);
  }

上面列出來主要用的一些方法，可以看出基本都是調(diào)用unsafe.getAndAddLong方法，接下來我們具體看下

public native long getLongVolatile(Object var1, long var2); 
 
 
public final native boolean compareAndSwapLong(Object var1, long var2, long var4, long var6);
 
/*
unsafe.getAndAddLong(this, valueOffset, 1L)
var1 當(dāng)前值
var2 value值在AtomicLong對象中的內(nèi)存偏移地址
*/
 
public final long getAndAddLong(Object var1, long var2, long var4) {
    long var6;
    do {
      //根據(jù)var1和var2得出當(dāng)前變量的值，以便接下來執(zhí)行更新操作
      var6 = this.getLongVolatile(var1, var2);
 
      //如果當(dāng)前值為var6，則將值加var4，這樣做是確保每次更新時(shí)，變量的值是沒有被其他線
//程修改過的值，如果被修改，則重新獲取最新值更新，直到更新成功
    } while(!this.compareAndSwapLong(var1, var2, var6, var6 + var4));
 
    return var6;
  }

從源碼可以看出，獲取當(dāng)前值getLongVolatile方法，比較并交換compareAndSwapLong方法都是native方法。說明不是采用java實(shí)現(xiàn)原子操作的，具體各位同學(xué)可以繼續(xù)去查看底層源碼（應(yīng)該是c++）實(shí)現(xiàn)，這里不在深入了（能力有限）。

比較并交換的缺陷

1、通過源碼可以看出，原子更新時(shí)，會(huì)先獲取當(dāng)前值，確保當(dāng)前值沒被修改過后在進(jìn)行更新操作，這也意味著如果競爭十分激烈，CAS的效率是有可能比鎖更低的（一般在實(shí)際中不會(huì)出現(xiàn)這種情況），JDK后面推出了LongAdd，粒度更小，競爭也會(huì)被分散到更低，具體實(shí)現(xiàn)各位同學(xué)可以自行了解。

2、ABA是談到CAS不可避免的話題，比較并交換，會(huì)存在這樣一個(gè)場景，當(dāng)變量為值A(chǔ)時(shí)，將值執(zhí)行更新。然而在實(shí)際中，有可能其他線程將值先改為B，然后又將值改回A，此時(shí)還是能夠成功執(zhí)行更新操作的（對于某些不在乎過程的沒啥影響，對于鏈表之類的就不滿足了）。解決方式是給變量打上版本號(hào)，如果版本號(hào)和值一致才執(zhí)行更新操作（可使用AtomicReference）。

總結(jié)

非阻塞算法通過底層的并發(fā)原語（例如比較交換而不是鎖）來維持線程的安全性。這些底層的原語通過原子變量類向外公開，這些類也用做一種“更好的volatile變量”，從而為整數(shù)和對象引用提供原子的更新操作。

參考書籍：

《JAVA并發(fā)編程實(shí)戰(zhàn)》

《JAVA并發(fā)編程的藝術(shù)》

以上就是本文的全部內(nèi)容，希望對大家的學(xué)習(xí)有所幫助，也希望大家多多支持腳本之家。

最新評論