大家好，我是小黑，一個在網際網路苟且偷生的農民工。
在開始講今天的內容之前，先問一個問題，使用int型別做加減操作是不是執行緒安全的呢？比如 i++ ，++i，i=i+1這樣的操作在併發情況下是否會有問題？
我們透過執行程式碼來看一下。
public class AtomicDemo { public static void main（String［］ args） throws InterruptedException { Data data = new Data（）； Thread a = new Thread（（） -> { for （int i = 0； i < 100000； i++） { System。out。println（Thread。currentThread（）。getName（）+“_”+data。increment（））； } }， “A”）； Thread b = new Thread（（） -> { for （int i = 0； i < 100000； i++） { System。out。println（Thread。currentThread（）。getName（）+“_”+data。increment（））； } }， “B”）； a。start（）； b。start（）； // 等待A，B執行緒執行完畢 a。join（）； b。join（）； System。out。println（data。getI（））； }}class Data { private volatile int i = 0； public int increment（） { i++； return i； } public int getI（） { return i； }}
以上程式碼比較簡單，透過A，B兩個執行緒同時對Data物件中的i執行++操作，各自執行100000次，最後輸出，如果說i++操作時執行緒安全的，那麼最後輸出的結果應該是200000，但是我們執行程式碼會看到如下結果：
我們發現最後輸出的並不是200000，而是199982，如果多執行幾次的話，這個結果會發生變化，並且大多數情況下不會是200000。這主要是因為int型別的++操作不是原子的，i++同等於i=i+1，也就是加1這一步和對i重新賦值這一步不是同時完成的，不具備原子性，所以我們得出結論int型別的操作不是執行緒安全的。
在很多實際場景中都需要對一個數據進行併發操作，比如電商的秒殺活動中，對一個商品數量的扣減，那麼我們想保證安全性應該怎麼做呢？
首先我們可以想到的就是使用synchronized關鍵字對increment（）這個方法加鎖，這樣就能保證每次只有一個執行緒能訪問。
但是之前的文章中我們有講到synchronized是一個重量級的悲觀鎖，我們的業務場景的併發可能是一段時間內的，多數情況下可能並不會有很多競爭，所以有沒有更好的處理方式呢，答案就是透過
AtomicInteger
。
AtomicInteger
AtomicInteger是java。util。concurrent。atomic包中的一個類。我們看官方文件對於這個包的描述，說它是支援單個變數上的無鎖執行緒安全程式設計的工具包，好像和我們期望的一樣，在不加鎖的情況下達到執行緒安全。
我們來修改一下上面例子的程式碼。
class Data { private volatile AtomicInteger i = new AtomicInteger（0）； public int increment（） { return i。incrementAndGet（）； } public int getI（） { return i。get（）； }}
很簡單，將原來的int修改為AtomicInteger，在執行increment（）方法進行增加操作時，呼叫incrementAndGet（）方法就可以了。同樣我們執行程式碼，會發現，不管執行多少次，程式碼最後執行的結果都是一樣的，200000。所以我們說AtomicInteger是執行緒安全的。除了incrementAndGet（）方法以外，還有很多其他的操作，比如decrementAndGet（），getAndIncrement（），getAndDecrement（），getAndAdd（int delta），addAndGet（int delta）等等，實際上就是對i++，++i，i=i+n，i+=n這些操作的原子實現。
除了AtomicInteger以外，java。util。concurrent。atomic包中還有一些其他型別，比如AtomicBoolean，AtomicLong等。
實現原理
那麼AtomicInteger是如何實現在不使用synchronized的情況下保證原子性的呢？我們來看一下原始碼。
public class AtomicInteger extends Number implements java。io。Serializable { private static final Unsafe unsafe = Unsafe。getUnsafe（）； // value在記憶體中的地址偏移值 private static final long valueOffset； static { try { valueOffset = unsafe。objectFieldOffset （AtomicInteger。class。getDeclaredField（“value”））； } catch （Exception ex） { throw new Error（ex）； } } // value為volatile的保證記憶體可見性 private volatile int value； public final int incrementAndGet（） { return unsafe。getAndAddInt（this， valueOffset， 1） + 1； } }public final class Unsafe { public final int getAndAddInt（Object var1， long var2， int var4） { int var5； do { // 獲取volatile的Int，保證拿到的值是最新的 var5 = this。getIntVolatile（var1， var2）； // compareAndSwapInt 比較並交換 native方法 } while（！this。compareAndSwapInt（var1， var2， var5， var5 + var4））； return var5； }}
透過原始碼我們看到在incrementAndGet（）方法中呼叫了Unsafe類的getAndAddInt方法，在這個方法內部對value進行compareAndSwapInt操作。透過這個方法名我們就可以看出是比較並交換，也就是我們之前提到過的
CAS
。也就是在執行賦值操作時，先看一下當前值是不是我加之前的值，如果不是，那我就重新加一次之後再進行比較，是一個迴圈的過程，這個過程也稱作
自旋
。
CAS這種處理方式雖然很高效地解決了原子操作，但是它仍然存在三個問題，在實際開發中一定要注意，結合自己的實際業務場景使用。
ABA問題
什麼是ABA問題呢，通俗理解，就是你大爺還是你大爺，你大媽已經不是你大媽了~
什麼意思呢？就是當執行緒1取到A之後，有另一個執行緒2把A變成了B，又變成了A，當執行緒1再修改完值進行CAS比較時，發現值還是A，和自己取到的一樣，就直接更新了，但是在這個過程中，這個A中間是發生過變化的。就好比一個小偷，偷了別人家錢然後再還回來，還是原來的錢嗎？雖然你的錢沒變，但是這個小偷已經觸犯了法律，而你自己還不知道。
為了解決這個問題，atomic包中提供了一個類，我們看下是如何解決的。
public static void main（String［］ args） throws InterruptedException { AtomicStampedReference
我們可以看到AtomicStampedReference的compareAndSet（）方法有4個引數：
expectedReference：表示期望的引用值
newReference：表示要修改後的新引用值
expectedStamp：表示期望的戳（版本號）
newStamp：表示修改後新的戳（版本號）
什麼意思呢？就是在修改時不光比較值是不是和獲取到的一樣，還要比較版本號。這樣的話，每次操作時都對版本號加1，那麼就算值從A改為B再改回A，但是版本號從0改成了1又改成了2，並沒有變回0，就可以避免ABA問題的發生。
迴圈時間變長
在併發非常大的情況下，使用CAS可能會存在一些執行緒一直迴圈修改不成功，導致迴圈時間變長，會給CPU帶來很大的執行開銷。並且由於AtomicReference中的引用是volatile的，為了保證記憶體可見性，需要保證快取一致性，透過匯流排傳輸資料，當有大量的CAS迴圈時，會產生
匯流排風暴
。
只能保證一個變數的原子操作
CAS的第三個問題就是AtomicReference中只能存放一個變數，如果需要保證多個變數操作的原子性，是做不到的。對於這種情況只能使用synchronized或者juc包中的Lock工具。
小結
簡單做個小結，使用int型別在併發場景下存線上程安全問題，可以用AtomicInteger來保證原子性操作，Atomic是透過CAS做到無鎖執行緒安全的。但是CAS有三個問題，第一ABA問題，可以透過AtomicStampedReference解決；第二競爭激烈情況下迴圈時間會變長，會產生匯流排風暴；第三隻能保證一個變數的原子操作。
具體業務場景中是使用synchronized，Lock等鎖工具還是使用Atomic的CAS無鎖操作，還是要結合場景考慮。
好的，今天的內容就到這裡，我們下期見。
