在學(xué)習(xí)多線程時(shí)，遇到了原子變量類，它是基于 CAS 和 volatile 實(shí)現(xiàn)的，能夠保障對(duì)共享變量進(jìn)行 read-modify-write 更新操作的原子性和可見性。于是我就寫了一段代碼試試，自認(rèn)為非常正確。

public class Test{ private static AtomicInteger ID = new AtomicInteger(0); public static int nextID(){ //返回的ID范圍為 1~100 if(ID.get() == 100) { //ID到達(dá)100時(shí)，則從1開始 ID.set(1); return ID.get(); // return ID = 1; } else return ID.incrementAndGet(); //++ID } public static void main(String[] args) throws Exception{ for(int i = 0; i < 5; i++){ new Thread(()->{for(int j = 0; j < 100; j++) nextID(); }).start(); } Thread.sleep(1000); //應(yīng)該輸出100才對(duì) System.out.println(ID); }}

用五個(gè)線程并發(fā)獲得ID，每個(gè)線程獲取100個(gè)，最后應(yīng)該輸出100才是，但試了好幾次都不是100。原子變量類不是能保障原子性和可見性嗎，為什么出現(xiàn)了競(jìng)態(tài)？

糾結(jié)了很久，還是很懵逼。后來發(fā)現(xiàn) get 方法相當(dāng)于讀取一個(gè) volatile 變量，而讀取一個(gè) volatile 變量時(shí)，不具備排他性！（AtomicInteger類內(nèi)部使用了volatile修飾了value值，而volatile關(guān)鍵字不具備排他性）

也就是說，當(dāng)一個(gè)線程剛讀取到了共享的 volatile 變量的值時(shí)，其他線程可會(huì)馬上對(duì)共享變量進(jìn)行修改。如，線程A讀取到ID的值為99時(shí)（還沒對(duì)ID進(jìn)行修改），其他線程可能馬上就將ID加1了，此時(shí)共享變量為100了，其他線程再獲取ID時(shí)，應(yīng)該令I(lǐng)D=1才是，但線程A已經(jīng)進(jìn)入了else分支，它還認(rèn)為ID=99，而不知道其他線程剛把ID加1變成了100，所以會(huì)吧ID加上1變成了101，這就出現(xiàn)了競(jìng)態(tài)。

《Java多線程編程實(shí)戰(zhàn)指南 - 核心篇》中，作者說：“可見性的保障僅僅意味著一個(gè)線程能夠讀取到共享變量的相對(duì)新值，而不能保障該線程能讀取到相應(yīng)變量的最新值”。如volatile對(duì)可見性的保障就是保障的相對(duì)新值，由于volatile不具備排他性，所以有可能讀線程剛讀到一個(gè)相對(duì)新值，寫線程就更改了共享變量，此時(shí)，讀線程剛剛讀取到的相對(duì)新值就不是最新的了。

作者對(duì)相對(duì)新值和最新值的定義：

對(duì)于同一個(gè)共享變量而言，一個(gè)線程更新了該變量的值之后，其他線程能夠讀取到這個(gè)更新后的值，那這個(gè)值就被稱為該變量的 相對(duì)新值。

如果讀取這個(gè)共享變量的線程在讀取并使用該變量的時(shí)候其他線程無法更新該變量的值，那么該線程讀取到的相對(duì)新值就被稱為該變量的 最新值。需要加鎖，才能讀取到最新值。

解決辦法，使用原子操作 compareAndSet：

private static int nextID(){ //返回的ID范圍為 1~100 ID.compareAndSet(100, 0); return ID.incrementAndGet();}

以上就是本文的全部?jī)?nèi)容，希望對(duì)大家的學(xué)習(xí)有所幫助，也希望大家多多支持好吧啦網(wǎng)。