引言

大家好，我是你們的老伙計(jì)秀才！今天帶來(lái)的是[深入淺出Java多線程]系列的第十篇內(nèi)容：CAS。大家覺得有用請(qǐng)點(diǎn)贊，喜歡請(qǐng)關(guān)注！秀才在此謝過大家了！??！

在多線程編程中，對(duì)共享資源的安全訪問和同步控制是至關(guān)重要的。傳統(tǒng)的鎖機(jī)制，如synchronized關(guān)鍵字和ReentrantLock等，能夠有效防止多個(gè)線程同時(shí)修改同一數(shù)據(jù)導(dǎo)致的競(jìng)態(tài)條件（race condition），但同時(shí)也帶來(lái)了一定的性能開銷。尤其是在高并發(fā)場(chǎng)景下，頻繁的加鎖解鎖操作可能導(dǎo)致線程上下文切換加劇、系統(tǒng)響應(yīng)延遲等問題。

為了應(yīng)對(duì)這一挑戰(zhàn)，Java從JDK 1.5版本開始引入了基于CAS（Compare And Swap）機(jī)制的原子類庫(kù)，這些原子類不僅提供了一種無(wú)鎖化的并發(fā)控制策略，還能夠在不阻塞其他線程的情況下實(shí)現(xiàn)高效的內(nèi)存同步。CAS作為樂觀鎖的一種實(shí)現(xiàn)方式，其核心思想是在更新變量時(shí)僅當(dāng)該變量的當(dāng)前值與預(yù)期值相等時(shí)才會(huì)執(zhí)行更新操作，否則就放棄更新并允許線程繼續(xù)嘗試或采取其他策略。

例如，在一個(gè)簡(jiǎn)單的場(chǎng)景中，假設(shè)有一個(gè)被多個(gè)線程共享的整型變量i，若我們想要通過CAS將其從初始值5原子性地遞增到6，可以利用AtomicInteger類中的compareAndSet方法：

import?java.util.concurrent.atomic.AtomicInteger;

public?class?CASExample?{
????private?static?AtomicInteger?sharedValue?=?new?AtomicInteger(5);

????public?static?void?main(String[]?args)?throws?InterruptedException?{
????????Thread?t1?=?new?Thread(()?->?{
????????????while?(true)?{
????????????????int?oldValue?=?sharedValue.get();
????????????????if?(sharedValue.compareAndSet(oldValue,?oldValue?+?1))?{
????????????????????System.out.println("Thread?"?+?Thread.currentThread().getName()?+?"?updated?the?value?to?"?+?(oldValue?+?1));
????????????????????break;
????????????????}
????????????}
????????});

????????t1.start();
????????//?確保t1有機(jī)會(huì)更新值
????????t1.join();

????????//?輸出結(jié)果應(yīng)為：Thread?Thread-0?updated?the?value?to?6
????}
}

在這個(gè)示例中，如果sharedValue的當(dāng)前值確實(shí)是5，那么線程t1將成功地將它更改為6，并退出循環(huán)；如果有其他線程在此期間改變了sharedValue的值，則t1會(huì)不斷重試直至成功。由于CAS操作直接由CPU指令級(jí)別保證其原子性，因此不會(huì)出現(xiàn)因并發(fā)寫入導(dǎo)致的數(shù)據(jù)混亂。

通過深入探討Java多線程中的CAS技術(shù)，我們將揭示其背后的具體實(shí)現(xiàn)原理——Unsafe類及其native方法，剖析AtomicInteger等原子類如何借助CAS機(jī)制實(shí)現(xiàn)在無(wú)鎖環(huán)境下的高效并發(fā)操作，并進(jìn)一步討論在實(shí)際應(yīng)用中可能出現(xiàn)的問題，如ABA問題、循環(huán)自旋消耗過大以及只能針對(duì)單個(gè)變量進(jìn)行原子操作的局限性及其相應(yīng)的解決方案。

在多線程編程領(lǐng)域中，鎖機(jī)制是實(shí)現(xiàn)數(shù)據(jù)同步和避免并發(fā)問題的關(guān)鍵手段。其中，樂觀鎖與悲觀鎖作為兩種不同的并發(fā)控制策略，在處理共享資源時(shí)采用了截然不同的假設(shè)和操作方式。

悲觀鎖&樂觀鎖

悲觀鎖

悲觀鎖，顧名思義，采取保守的策略對(duì)待并發(fā)訪問。它假定每次對(duì)共享資源進(jìn)行操作時(shí)都可能發(fā)生沖突，因此在執(zhí)行任何更新前都會(huì)預(yù)先鎖定資源。例如，在Java中使用synchronized關(guān)鍵字或ReentrantLock等工具實(shí)現(xiàn)悲觀鎖時(shí)，一個(gè)線程在獲取鎖后才能進(jìn)入臨界區(qū)執(zhí)行代碼，其他線程則必須等待鎖釋放后才能獲得執(zhí)行機(jī)會(huì)。以下是一個(gè)簡(jiǎn)單的悲觀鎖示例：

public?class?PessimisticLockExample?{
????private?final?Lock?lock?=?new?ReentrantLock();

????public?void?decrementCounter()?{
????????lock.lock();?//?獲取悲觀鎖
????????try?{
????????????//?臨界區(qū)代碼
????????????int?count?=?this.count;
????????????if?(count?>?0)?{
????????????????this.count--;
????????????}
????????}?finally?{
????????????lock.unlock();?//?釋放悲觀鎖
????????}
????}

????//?共享資源變量
????private?int?count?=?10;
}

在這個(gè)例子中，當(dāng)一個(gè)線程試圖修改計(jì)數(shù)器時(shí)，會(huì)先鎖定整個(gè)方法，確保同一時(shí)間只有一個(gè)線程能夠執(zhí)行減一操作。這種機(jī)制雖然保證了數(shù)據(jù)一致性，但可能造成線程間的頻繁阻塞和上下文切換，尤其在高并發(fā)環(huán)境下性能損耗明顯。

樂觀鎖

相對(duì)而言，樂觀鎖則是基于積極樂觀的假設(shè)：認(rèn)為大部分情況下多個(gè)線程同時(shí)訪問同一資源并不會(huì)發(fā)生沖突。因此，樂觀鎖允許線程無(wú)須獲取鎖就可以執(zhí)行業(yè)務(wù)邏輯，僅在更新數(shù)據(jù)時(shí)采用CAS（Compare And Swap）原子操作檢查并更新數(shù)據(jù)。如果發(fā)現(xiàn)數(shù)據(jù)已被其它線程改變，則放棄本次更新，通常會(huì)重新讀取數(shù)據(jù)并再次嘗試。

以Java中的AtomicInteger為例，它利用CAS機(jī)制實(shí)現(xiàn)了樂觀鎖的特性：

public?class?OptimisticLockExample?{
????private?final?AtomicInteger?counter?=?new?AtomicInteger(10);

????public?void?incrementCounter()?{
????????while?(true)?{?//?自旋
????????????int?currentValue?=?counter.get();
????????????int?newValue?=?currentValue?+?1;
????????????if?(counter.compareAndSet(currentValue,?newValue))?{?//?使用CAS原子操作
????????????????break;?//?更新成功，退出循環(huán)
????????????}
????????}
????}
}

//?AtomicInteger?的?compareAndSet?方法源碼簡(jiǎn)化示意
public?final?boolean?compareAndSet(int?expect,?int?update)?{
????return?unsafe.compareAndSwapInt(this,?valueOffset,?expect,?update);
}

上述代碼展示了如何在一個(gè)循環(huán)內(nèi)連續(xù)嘗試原子地增加計(jì)數(shù)器值。只有當(dāng)當(dāng)前值等于預(yù)期值時(shí)，CAS操作才會(huì)成功，否則線程將不斷重試直至成功更新。由于樂觀鎖在沒有沖突的情況下不涉及線程掛起，故適用于“讀多寫少”的場(chǎng)景，能有效降低加鎖開銷，提高系統(tǒng)吞吐量。然而，若并發(fā)更新頻率較高，可能會(huì)導(dǎo)致大量的CAS失敗和重試，從而帶來(lái)額外的CPU消耗。

CAS原理

在并發(fā)編程中，CAS（Compare and Swap，比較并交換）是一種無(wú)鎖算法，它在不阻塞其他線程的情況下實(shí)現(xiàn)原子性的變量更新操作。在Java中，CAS的實(shí)現(xiàn)基于Unsafe類提供的native方法，這些方法直接與底層硬件交互，利用CPU級(jí)別的原子指令來(lái)保證數(shù)據(jù)更新的安全性。

CAS流程

在CAS操作中涉及三個(gè)關(guān)鍵值：V（要更新的變量），E（預(yù)期值），N（新值）。當(dāng)需要對(duì)一個(gè)共享變量進(jìn)行修改時(shí)，線程首先檢查該變量當(dāng)前值是否等于預(yù)期值E。如果相等，則將變量值更新為新值N；如果不等，則說明已經(jīng)有其他線程更新了該變量，此時(shí)當(dāng)前線程放棄更新操作，保持原值不變。

以AtomicInteger為例，我們可以通過以下代碼片段理解CAS的工作過程：

import?java.util.concurrent.atomic.AtomicInteger;

public?class?CASTest?{
????private?AtomicInteger?counter?=?new?AtomicInteger(5);

????public?void?increment()?{
????????int?expectedValue?=?counter.get();
????????while?(!counter.compareAndSet(expectedValue,?expectedValue?+?1))?{
????????????//?當(dāng)前線程獲取到的值已經(jīng)被其他線程改變，重新獲取最新值
????????????expectedValue?=?counter.get();
????????}
????}
}

在這個(gè)例子中，compareAndSet方法會(huì)不斷嘗試將計(jì)數(shù)器從舊值遞增1，直到成功為止。當(dāng)多個(gè)線程同時(shí)嘗試增加計(jì)數(shù)器時(shí)，只有一個(gè)線程能夠通過CAS成功更新，其余線程將繼續(xù)循環(huán)直至其看到的預(yù)期值和實(shí)際值匹配后再嘗試更新。

原子性和操作系統(tǒng)

CAS的核心優(yōu)勢(shì)在于其原子性——即整個(gè)比較和交換的操作作為一個(gè)不可分割的整體執(zhí)行。在現(xiàn)代多核CPU架構(gòu)下，諸如cmpxchg指令這樣的原子指令能夠確保在沒有外部干預(yù)的情況下完成這一系列步驟。在Linux X86系統(tǒng)中，cmpxchgl指令配合lock前綴可以確保在同一時(shí)刻僅有一個(gè)處理器能成功更新內(nèi)存位置，從而避免了并發(fā)問題。

ABA問題

盡管CAS機(jī)制在大多數(shù)情況下表現(xiàn)優(yōu)異，但存在一種特殊情況——ABA問題。假設(shè)一個(gè)變量初始值為A，被更改為B后又改回A，這種情況下使用單純的CAS檢查將會(huì)誤判為未發(fā)生過變化。為了應(yīng)對(duì)ABA問題，JDK提供了一個(gè)名為AtomicStampedReference的類，它在每個(gè)對(duì)象引用上附加了一個(gè)版本號(hào)或時(shí)間戳，使得每次更改不僅檢查引用本身，還檢查版本號(hào)，只有兩者都匹配時(shí)才會(huì)進(jìn)行替換。

import?java.util.concurrent.atomic.AtomicStampedReference;

public?class?ABATest?{
????private?AtomicStampedReference<Integer>?ref?=?new?AtomicStampedReference<>(1,?0);

????public?void?update(int?newValue,?int?newStamp)?{
????????while?(true)?{
????????????int?currentStamp?=?ref.getStamp();
????????????if?(ref.compareAndSet(1,?newValue,?currentStamp,?newStamp))?{
????????????????break;?//?更新成功
????????????}?else?{
????????????????//?失敗則重試，獲取最新的stamp
????????????}
????????}
????}
}

在上述代碼中，compareAndSet方法不僅要比較引用對(duì)象的值，還要比較并更新相關(guān)聯(lián)的版本信息，因此有效防止了ABA問題的發(fā)生。

綜上所述，CAS作為一種高效的無(wú)鎖同步機(jī)制，在Java多線程編程中扮演著重要角色，通過直接調(diào)用CPU指令實(shí)現(xiàn)了并發(fā)環(huán)境下的原子操作，但也需要注意潛在的ABA問題以及長(zhǎng)時(shí)間自旋帶來(lái)的性能開銷等問題，并選擇合適的解決方案。

Unsafe類

在Java中，為了能夠直接與底層硬件進(jìn)行交互并執(zhí)行原子操作，如CAS，Java使用了一個(gè)名為sun.misc.Unsafe的類。由于該類提供了一些不受JVM訪問控制約束的方法，并允許開發(fā)者直接操作內(nèi)存和執(zhí)行非安全但高效的原語(yǔ)操作，因此被稱為“Unsafe”。盡管這個(gè)類不在公共API中，但在并發(fā)包java.util.concurrent.atomic中的原子類，如AtomicInteger等，都依賴于Unsafe類提供的CAS操作來(lái)保證線程間的原子性和可見性。

Unsafe類與CAS方法 Unsafe類包含了一系列native方法，這些方法用于執(zhí)行原子性的CAS操作，例如：

public?native?boolean?compareAndSwapObject(Object?o,?long?offset,?Object?expected,?Object?x);
public?native?boolean?compareAndSwapInt(Object?o,?long?offset,?int?expected,?int?x);
public?native?boolean?compareAndSwapLong(Object?o,?long?offset,?long?expected,?long?x);

這些方法分別用于比較并交換對(duì)象引用、整型值以及長(zhǎng)整型值。參數(shù)含義如下：

• o：一個(gè)對(duì)象實(shí)例，CAS操作將作用在其內(nèi)部的一個(gè)字段上。
• offset：指定字段相對(duì)于對(duì)象起始地址的偏移量，由objectFieldOffset()方法計(jì)算得出。
• expected：期望的舊值，只有當(dāng)字段當(dāng)前值等于此預(yù)期值時(shí)，才會(huì)進(jìn)行更新。
• x：新值，如果條件滿足，則用新值替換舊值。

以AtomicInteger為例，其getAndAddInt方法就利用了Unsafe類的compareAndSwapInt方法實(shí)現(xiàn)原子遞增：

public?final?int?getAndAddInt(Object?o,?long?offset,?int?delta)?{
????int?v;
????do?{
????????v?=?getIntVolatile(o,?offset);?//?獲取當(dāng)前值
????}?while?(!weakCompareAndSetInt(o,?offset,?v,?v?+?delta));?//?使用CAS嘗試更新
????return?v;?//?返回更新前的值
}

這里首先獲取到共享變量的當(dāng)前值v，然后在一個(gè)循環(huán)中不斷嘗試通過CAS指令將變量從v更新為v+delta，直到成功為止。

CPU級(jí)別的原子操作 值得注意的是，CAS操作在Java中的實(shí)現(xiàn)實(shí)際上調(diào)用了操作系統(tǒng)和CPU提供的原子指令。在Linux X86系統(tǒng)下，是通過cmpxchgl這樣的CPU指令實(shí)現(xiàn)的，而在多處理器環(huán)境中，為了確?？缍鄠€(gè)CPU核心的原子性，還需要配合lock前綴指令鎖定總線或緩存行，防止其他處理器同時(shí)修改同一數(shù)據(jù)。

弱版本CAS與強(qiáng)版本CAS的區(qū)別 從JDK 9開始，Unsafe類提供了兩個(gè)看似相似但實(shí)際上可能有不同實(shí)現(xiàn)策略的方法：compareAndSetInt和weakCompareAndSetInt。雖然在早期版本中它們的行為一致，但在某些情況下，weakCompareAndSet系列方法可能只保留了volatile變量本身的特性，而放棄了happens-before規(guī)則帶來(lái)的內(nèi)存語(yǔ)義保障。這意味著weakCompareAndSet無(wú)法確保除了目標(biāo)volatile變量以外的其他變量的操作順序和可見性，從而有可能帶來(lái)更高的性能，但也可能需要開發(fā)人員更小心地處理并發(fā)邏輯。

總之，Java通過Unsafe類實(shí)現(xiàn)了對(duì)CAS原子操作的支持，使得程序員可以在高級(jí)語(yǔ)言層面上利用底層硬件的原子指令，構(gòu)建出高效且無(wú)鎖化的并發(fā)程序。然而，這也要求開發(fā)者具備對(duì)并發(fā)編程機(jī)制深刻的理解，以便正確解決潛在的問題，比如ABA問題，以及合理應(yīng)對(duì)CAS自旋可能導(dǎo)致的性能開銷。

AtomicInteger源碼簡(jiǎn)析

Java并發(fā)包中的java.util.concurrent.atomic.AtomicInteger類是一個(gè)基于CAS實(shí)現(xiàn)的線程安全整數(shù)容器，它提供了一系列原子操作方法，如get、set、incrementAndGet等。以getAndAdd(int delta)方法為例，該方法用于獲取當(dāng)前值并原子性地將值增加指定的delta。

Java 17下的Atomic類：

首先，我們觀察到getAndAdd(int delta)方法調(diào)用了Unsafe類的getAndAddInt()方法：

public?final?int?getAndAdd(int?delta)?{
????return?U.getAndAddInt(this,?VALUE,?delta);
}

這里的U是Unsafe類的一個(gè)實(shí)例，其內(nèi)部字段VALUE存儲(chǔ)了AtomicInteger類中value變量相對(duì)于對(duì)象起始地址的偏移量。objectFieldOffset()方法用于計(jì)算這個(gè)偏移量：

private?static?final?long?VALUE?=?U.objectFieldOffset(AtomicInteger.class,?"value");

然后，深入到Unsafe類的getAndAddInt()方法實(shí)現(xiàn)：

public?final?int?getAndAddInt(Object?o,?long?offset,?int?delta)?{
????int?v;
????do?{
????????v?=?getIntVolatile(o,?offset);?//?獲取volatile類型的舊值
????}?while?(!weakCompareAndSetInt(o,?offset,?v,?v?+?delta));?//?使用CAS更新新值
????return?v;?//?返回更新前的值
}

這段代碼展示了典型的CAS循環(huán)模式。首先通過getIntVolatile()讀取內(nèi)存中AtomicInteger實(shí)例的volatile變量value的當(dāng)前值，并保存在局部變量v中。接下來(lái)進(jìn)入一個(gè)do-while循環(huán)，在循環(huán)體內(nèi)嘗試使用weakCompareAndSetInt()執(zhí)行CAS操作。只有當(dāng)value的當(dāng)前值等于我們剛讀取到的v時(shí)，才會(huì)將value設(shè)置為v+delta。如果此時(shí)value已經(jīng)被其他線程更改，則CAS失敗，程序會(huì)再次讀取新的value值，并重新進(jìn)行CAS嘗試，直到成功為止。

值得注意的是，這里雖然使用了weakCompareAndSetInt()方法，但在JDK 8及之前版本中，compareAndSetInt()和weakCompareAndSetInt()的功能實(shí)際上是相同的。而在JDK 9及以上版本中，weakCompareAndSetInt()可能具有更弱的內(nèi)存語(yǔ)義保證，即不強(qiáng)制滿足happens-before規(guī)則，這有助于提升性能但要求開發(fā)者對(duì)并發(fā)編程有更深的理解。

通過這種方式，AtomicInteger借助Unsafe提供的底層支持實(shí)現(xiàn)了無(wú)鎖的原子操作，不僅避免了傳統(tǒng)鎖機(jī)制帶來(lái)的上下文切換開銷，還確保了在多線程環(huán)境下的數(shù)據(jù)一致性。同時(shí)，通過對(duì)源碼的分析，我們可以更加深入地理解Java如何利用CAS機(jī)制來(lái)解決并發(fā)問題。

常見問題與解決方案

循環(huán)自旋開銷問題及其解決方案

使用CAS通常伴隨著循環(huán)重試機(jī)制，即當(dāng)CAS失敗時(shí)，線程會(huì)不斷嘗試再次執(zhí)行CAS操作直至成功。然而，在高競(jìng)爭(zhēng)條件下，這可能導(dǎo)致線程長(zhǎng)時(shí)間處于“自旋”狀態(tài)，占用大量CPU資源且無(wú)實(shí)質(zhì)性工作進(jìn)展。

為了解決這一問題，JVM支持處理器提供的pause指令，比如在HotSpot虛擬機(jī)中，可以插入適當(dāng)?shù)膒ause指令來(lái)降低自旋等待過程中的CPU消耗。pause指令可以使CPU暫時(shí)放棄當(dāng)前線程的執(zhí)行，并讓其他線程有機(jī)會(huì)運(yùn)行，從而減少空轉(zhuǎn)帶來(lái)的性能損失。此外，現(xiàn)代JVM還通過自適應(yīng)自旋策略調(diào)整自旋次數(shù)，以達(dá)到更好的性能效果。

單變量原子操作局限及其擴(kuò)展方案

雖然CAS能很好地保證單個(gè)共享變量的原子性，但在涉及多個(gè)變量的操作場(chǎng)景下，單純的CAS將顯得力不從心。為了應(yīng)對(duì)這種情況，有以下兩種解決方案：

1. 使用AtomicReference類封裝對(duì)象 當(dāng)需要對(duì)包含多個(gè)變量的對(duì)象進(jìn)行原子性更新時(shí)，可以利用java.util.concurrent.atomic.AtomicReference類。將多個(gè)變量封裝到一個(gè)對(duì)象中，然后對(duì)整個(gè)對(duì)象進(jìn)行CAS操作，如：

   class?Data?{
   ????int?a;
   ????int?b;
   }
   AtomicReference<Data>?atomicData?=?new?AtomicReference<>(new?Data(1,?2));
   //?更新a和b字段的原子操作
   Data?newData?=?new?Data(3,?4);
   atomicData.compareAndSet(currentData,?newData);
   
   

2. 使用鎖保護(hù)臨界區(qū) 在一些復(fù)雜的多變量操作場(chǎng)景下，CAS可能無(wú)法直接滿足需求，此時(shí)可以選擇傳統(tǒng)的鎖機(jī)制，如synchronized關(guān)鍵字或ReentrantLock類來(lái)保護(hù)臨界區(qū)代碼，確保在給定時(shí)間內(nèi)只有一個(gè)線程能夠訪問并更新這些變量，從而實(shí)現(xiàn)多變量操作的原子性。

綜上所述，雖然CAS帶來(lái)了高效的無(wú)鎖并發(fā)控制機(jī)制，但也存在諸如ABA問題、循環(huán)自旋開銷過大以及只能處理單個(gè)變量等問題。針對(duì)這些問題，Java平臺(tái)提供了相應(yīng)的解決方案，如AtomicStampedReference類、pause指令優(yōu)化以及AtomicReference等工具，幫助開發(fā)者在復(fù)雜多樣的并發(fā)場(chǎng)景下更靈活地運(yùn)用CAS技術(shù)。

總結(jié)

在Java多線程編程中，CAS（Compare and Swap）機(jī)制扮演著至關(guān)重要的角色。作為樂觀鎖的一種實(shí)現(xiàn)方式，它通過比較并交換內(nèi)存位置的值來(lái)保證原子操作，避免了傳統(tǒng)悲觀鎖帶來(lái)的并發(fā)性能瓶頸和上下文切換開銷。在JDK的java.util.concurrent.atomic包中，諸如AtomicInteger、AtomicStampedReference等原子類庫(kù)就是基于Unsafe類提供的CAS原語(yǔ)構(gòu)建的。

以AtomicInteger為例，其getAndAdd方法利用CAS循環(huán)實(shí)現(xiàn)了無(wú)鎖的原子遞增操作，確保在高并發(fā)場(chǎng)景下變量更新的正確性和高效性。然而，CAS并非完美無(wú)缺，其中的ABA問題需要通過引入版本號(hào)或時(shí)間戳的方式來(lái)解決，如AtomicStampedReference通過比較引用與版本戳防止了兩次相同值之間的中間狀態(tài)被忽視。

針對(duì)循環(huán)自旋導(dǎo)致的CPU資源浪費(fèi)問題，現(xiàn)代JVM如HotSpot支持處理器pause指令，能夠在自旋失敗時(shí)降低CPU活動(dòng)頻率，減少不必要的消耗。同時(shí)，為了克服單個(gè)共享變量原子操作的局限性，Java提供了AtomicReference類，可以封裝多個(gè)變量作為一個(gè)整體進(jìn)行CAS操作，或者在必要時(shí)采用鎖機(jī)制，如synchronized關(guān)鍵字或ReentrantLock，確保多變量間的原子性。

綜上所述，CAS為Java開發(fā)者提供了一種強(qiáng)大的無(wú)鎖并發(fā)工具，但其使用需結(jié)合具體應(yīng)用場(chǎng)景和可能遇到的問題靈活選擇解決方案。只有充分理解并合理應(yīng)用CAS及其相關(guān)技術(shù)，才能在實(shí)際開發(fā)中編寫出高性能且線程安全的多線程代碼。盡管文檔中未給出具體的代碼實(shí)例，但上述分析和解釋已經(jīng)清晰描繪了如何在Java中運(yùn)用CAS實(shí)現(xiàn)原子操作以及應(yīng)對(duì)相關(guān)挑戰(zhàn)的過程。文章來(lái)源地址http://www.zghlxwxcb.cn/news/detail-838521.html