1. 引言

在現(xiàn)代多核處理器架構(gòu)下，Java并發(fā)編程已成為構(gòu)建高性能、高吞吐量應(yīng)用的關(guān)鍵技術(shù)。然而，線程間的同步與協(xié)作帶來(lái)了巨大的挑戰(zhàn)，其中最核心的問(wèn)題是如何在保證數(shù)據(jù)一致性的前提下，最大限度地減少同步開銷。傳統(tǒng)的阻塞鎖（如synchronized和ReentrantLock）通過(guò)掛起和喚醒線程來(lái)管理競(jìng)爭(zhēng)，但這涉及用戶態(tài)到內(nèi)核態(tài)的切換，帶來(lái)了不可忽視的性能成本。為了應(yīng)對(duì)這一挑戰(zhàn)，Java引入了更為輕量級(jí)的同步機(jī)制，其中，CAS操作和自旋鎖扮演了至關(guān)重要的角色。

2. 比較并交換 (Compare-and-Swap, CAS) 核心原理

CAS是一種非阻塞的原子性操作，是現(xiàn)代并發(fā)算法的基石，尤其在無(wú)鎖（Lock-Free）數(shù)據(jù)結(jié)構(gòu)的設(shè)計(jì)中占據(jù)核心地位。

2.1 CAS 操作的定義與工作流程

CAS操作包含三個(gè)核心操作數(shù)：

1. 內(nèi)存位置 V (Memory Location) ：需要被更新的變量的內(nèi)存地址。
2. 預(yù)期值 A (Expected Value) ：線程認(rèn)為該內(nèi)存位置當(dāng)前應(yīng)該持有的值。
3. 新值 B (New Value) ：如果內(nèi)存位置的值與預(yù)期值A(chǔ)相匹配，將被寫入的新值。

其工作流程是一個(gè)不可分割的原子步驟：當(dāng)且僅當(dāng)內(nèi)存位置V的當(dāng)前值等于預(yù)期值A(chǔ)時(shí)，處理器才會(huì)原子地將V的值更新為B。否則，處理器不做任何操作。 無(wú)論更新是否成功，操作都會(huì)返回V之前的值 。這種“比較后交換”的機(jī)制允許線程在不加鎖的情況下，安全地修改共享變量。

2.2 Java中CAS的實(shí)現(xiàn)機(jī)制

Java中的CAS并非憑空實(shí)現(xiàn)，它依賴于從硬件到JVM再到Java類庫(kù)的多層協(xié)同。

• 底層硬件支持：CAS的原子性最終由CPU硬件保證?，F(xiàn)代處理器都提供了專門的原子指令來(lái)支持CAS操作，例如在x86/x64架構(gòu)下是cmpxchg指令，并通常配合lock前綴來(lái)保證多核環(huán)境下的總線鎖定或緩存鎖定，從而確保操作的原子性。
• sun.misc.Unsafe 類：在JDK 8及之前，Unsafe類是Java實(shí)現(xiàn)CAS的“后門”。它是一個(gè)特殊的、不應(yīng)被開發(fā)者直接使用的類，但它提供了直接操作內(nèi)存的能力，包括一系列的compareAndSwap本地方法（如compareAndSwapInt, compareAndSwapObject），這些方法會(huì)直接調(diào)用JVM內(nèi)部的C++代碼，最終映射到CPU的原子指令。
• 原子類 (java.util.concurrent.atomic) ：Java并發(fā)包中的AtomicInteger, AtomicLong, AtomicBoolean, AtomicReference等原子類，是官方推薦的、對(duì)Unsafe中CAS操作的安全封裝。開發(fā)者通過(guò)調(diào)用這些類的compareAndSet等方法，間接地使用CAS來(lái)實(shí)現(xiàn)線程安全的計(jì)數(shù)器、狀態(tài)標(biāo)志等，而無(wú)需直接處理Unsafe的復(fù)雜性和風(fēng)險(xiǎn)。
• VarHandle (JDK 9+) ：為了提供一個(gè)更安全、更標(biāo)準(zhǔn)化的替代方案來(lái)取代Unsafe，Java 9引入了java.lang.invoke.VarHandle。VarHandle提供了對(duì)字段和數(shù)組元素的強(qiáng)類型、面向?qū)ο蟮脑L問(wèn)方式，并支持包括CAS在內(nèi)的多種原子操作和內(nèi)存排序模式，是未來(lái)Java中進(jìn)行底層并發(fā)操作的主流方式。

2.3 CAS的內(nèi)存順序保證

為了在多線程環(huán)境中正確工作，CAS不僅需要保證原子性，還必須提供嚴(yán)格的內(nèi)存可見性和有序性保證。

• volatile 語(yǔ)義：Atomic系列類中compareAndSet方法的內(nèi)存效果，等同于對(duì)一個(gè)volatile變量的讀和寫 。這意味著：
  • 可見性：當(dāng)一個(gè)線程通過(guò)CAS成功修改了變量的值，這個(gè)修改會(huì)立即對(duì)其他所有線程可見。
  • 有序性：CAS操作前后的代碼不會(huì)被重排序到CAS操作的另一側(cè)，這有助于建立線程間的“Happens-Before”關(guān)系。
• 內(nèi)存屏障：這種volatile語(yǔ)義是通過(guò)在底層實(shí)現(xiàn)中插入內(nèi)存屏障（Memory Fences/Barriers）來(lái)實(shí)現(xiàn)的。內(nèi)存屏障是一種CPU指令，用于阻止處理器對(duì)內(nèi)存操作進(jìn)行重排序，并強(qiáng)制將本地緩存中的數(shù)據(jù)刷新到主內(nèi)存或從主內(nèi)存加載最新的數(shù)據(jù)。一個(gè)完整的CAS操作通常隱含了“LoadLoad”、“LoadStore”、“StoreLoad”和“StoreStore”四種屏障的效果，確保了最強(qiáng)的內(nèi)存排序。
• VarHandle 的精細(xì)化控制：VarHandle提供了更細(xì)粒度的內(nèi)存排序模式，如compareAndExchangeAcquire和compareAndExchangeRelease。這兩種模式對(duì)應(yīng)內(nèi)存模型中的Acquire/Release語(yǔ)義，允許開發(fā)者在特定場(chǎng)景下使用比volatile更弱但足夠安全的內(nèi)存排序，從而獲得潛在的性能提升。

2.4 CAS的局限性

盡管功能強(qiáng)大，但CAS并非萬(wàn)能，它存在一些固有的問(wèn)題：

• ABA問(wèn)題：如果一個(gè)值從A變?yōu)锽，然后又變回A，CAS在檢查時(shí)會(huì)發(fā)現(xiàn)它的值仍然是A，從而錯(cuò)誤地認(rèn)為變量沒有被修改過(guò)并執(zhí)行更新。在某些業(yè)務(wù)場(chǎng)景下這可能導(dǎo)致嚴(yán)重錯(cuò)誤。解決方案是使用AtomicStampedReference，它將版本號(hào)（或標(biāo)記）與引用捆綁在一起，每次更新都同時(shí)檢查值和版本號(hào)。
• 自旋開銷：當(dāng)多個(gè)線程同時(shí)嘗試更新同一個(gè)變量時(shí)，只有一個(gè)線程能成功，其他線程會(huì)失敗。失敗的線程通常需要在一個(gè)循環(huán)中不斷重試（即“自旋”），直到成功為止。在高并發(fā)競(jìng)爭(zhēng)下，這種持續(xù)的自旋會(huì)消耗大量的CPU資源 。
• 單一變量原子性：CAS操作本身只能保證對(duì)單個(gè)共享變量的原子操作。如果需要原子地更新多個(gè)變量，就需要將這些變量封裝到一個(gè)對(duì)象中，然后使用AtomicReference對(duì)這個(gè)對(duì)象的引用進(jìn)行CAS操作。

3. 自旋鎖 (Spin Lock) 機(jī)制詳解

自旋鎖是一種基于“忙等待”（Busy-Waiting）的鎖機(jī)制，它在嘗試獲取鎖時(shí)表現(xiàn)出與傳統(tǒng)阻塞鎖截然不同的行為。

3.1 自旋鎖的基本概念

自旋鎖是一種非阻塞鎖。當(dāng)一個(gè)線程嘗試獲取一個(gè)已被占用的自旋鎖時(shí)，該線程不會(huì)被操作系統(tǒng)掛起（進(jìn)入阻塞狀態(tài)），而是會(huì)執(zhí)行一個(gè)忙循環(huán)（自旋），反復(fù)檢查鎖是否已經(jīng)釋放。

這種機(jī)制的理論基礎(chǔ)是：如果鎖的持有時(shí)間非常短暫，那么線程自旋等待的CPU開銷，可能要小于線程阻塞和喚醒所涉及的上下文切換開銷。因此，自旋鎖特別適用于以下場(chǎng)景：

• 鎖保護(hù)的臨界區(qū)代碼執(zhí)行速度極快。
• 可以預(yù)見鎖的持有時(shí)間非常短。
• 運(yùn)行在多核處理器上（單核CPU上自旋沒有意義，因?yàn)槌钟墟i的線程無(wú)法被調(diào)度，自旋的線程將永遠(yuǎn)等待）。

3.2 Java中自旋鎖的實(shí)現(xiàn)方式

在Java中，開發(fā)者可以利用原子類來(lái)自定義簡(jiǎn)單的自旋鎖。

基于CAS的自定義實(shí)現(xiàn)：最常見的實(shí)現(xiàn)方式是使用AtomicBoolean或AtomicReference< Thread>。以AtomicBoolean為例，鎖的狀態(tài)可以用一個(gè)布爾值表示（true為鎖定，false為未鎖定）。lock()方法通過(guò)一個(gè)循環(huán)調(diào)用compareAndSet(false, true)來(lái)嘗試將狀態(tài)從未鎖定變?yōu)殒i定。如果成功，則獲取鎖；如果失敗，則繼續(xù)循環(huán)。unlock()方法則直接將狀態(tài)設(shè)置為false 。
一個(gè)簡(jiǎn)單的代碼示例如下 ：

public class SpinLock {
    private AtomicBoolean available = new AtomicBoolean(false); // false代表鎖可用

    public void lock() {
        // 使用compareAndSet進(jìn)行自旋，期望從false變?yōu)閠rue
        while (!available.compareAndSet(false, true)) {
            // 自旋等待
            // JDK 9+ 可以使用 Thread.onSpinWait(); 來(lái)提高效率
        }
    }

    public void unlock() {
        available.set(false);
    }
}

3.3 JVM內(nèi)置的自旋鎖優(yōu)化

Java虛擬機(jī)（JVM）自身在synchronized關(guān)鍵字的實(shí)現(xiàn)中，深度集成了自旋鎖作為一種重要的性能優(yōu)化手段。

• 輕量級(jí)鎖中的自旋：當(dāng)多個(gè)線程競(jìng)爭(zhēng)一個(gè)鎖時(shí)，synchronized會(huì)經(jīng)歷一個(gè)從偏向鎖到輕量級(jí)鎖再到重量級(jí)鎖的升級(jí)過(guò)程。當(dāng)一個(gè)線程嘗試獲取一個(gè)輕量級(jí)鎖失敗時(shí)，JVM不會(huì)立即將鎖膨脹為重量級(jí)鎖并阻塞線程，而是會(huì)讓該線程先進(jìn)行短暫的、固定次數(shù)的自旋，期望在自旋期間鎖被釋放 。
• 自適應(yīng)自旋（Adaptive Spinning）‍ ：從JDK 1.6開始，JVM引入了更為智能的自適應(yīng)自旋。JVM會(huì)根據(jù)上一次在同一個(gè)鎖上的自旋成功率以及鎖持有者的狀態(tài)，來(lái)動(dòng)態(tài)地決定自旋的次數(shù)。如果對(duì)于某個(gè)鎖，自旋很少成功，那么以后獲取這個(gè)鎖時(shí)就可能直接跳過(guò)自旋；反之，如果自旋經(jīng)常成功，JVM就會(huì)認(rèn)為自旋是值得的，并允許更長(zhǎng)時(shí)間的自旋 。
• JVM參數(shù)控制：在早期的JDK版本中，可以通過(guò)-XX:+UseSpinning來(lái)啟用自旋，并通過(guò)-XX:PreBlockSpin來(lái)設(shè)置自旋的次數(shù) 。但在引入自適應(yīng)自旋后，這些參數(shù)的作用被弱化甚至被廢棄 ，因?yàn)镴VM的動(dòng)態(tài)決策通常比靜態(tài)配置更高效。

3.4 AQS框架中的自旋行為

AbstractQueuedSynchronizer (AQS) 是java.util.concurrent包下眾多同步組件（如ReentrantLock, Semaphore）的基石。AQS在線程入隊(duì)等待之前，也會(huì)進(jìn)行一種“前置”的自旋嘗試。當(dāng)一個(gè)線程調(diào)用acquire方法嘗試獲取鎖失敗后，在被構(gòu)造成節(jié)點(diǎn)（Node）加入等待隊(duì)列之前，它會(huì)進(jìn)行有限次數(shù)的快速自旋嘗試，這給了線程一個(gè)在進(jìn)入漫長(zhǎng)等待前“插隊(duì)”成功的機(jī)會(huì)，從而減少了入隊(duì)和后續(xù)park/unpark的開銷 。在JDK 9之后，AQS的自旋邏輯中還可能調(diào)用Thread.onSpinWait()方法，這是一個(gè)給處理器的提示，表明當(dāng)前線程正在自旋，CPU可以據(jù)此進(jìn)行能耗或執(zhí)行流水線上的優(yōu)化 。

4. 自旋鎖與CAS的深層關(guān)系與區(qū)別

理解自旋鎖和CAS，關(guān)鍵在于辨析它們的層次和作用。

4.1 核心關(guān)系：CAS是自旋鎖的實(shí)現(xiàn)基礎(chǔ)

自旋鎖的實(shí)現(xiàn)離不開CAS。 自旋鎖的核心操作是“檢查鎖狀態(tài)并嘗試獲取鎖”，這個(gè)復(fù)合操作必須是原子的。如果使用非原子操作（如先讀后寫），在多線程環(huán)境下就會(huì)出現(xiàn)競(jìng)態(tài)條件。CAS恰好提供了這種原子性的“比較并設(shè)置”能力，完美地滿足了自旋鎖的需求。因此，無(wú)論是用戶自定義的自旋鎖，還是JVM內(nèi)部輕量級(jí)鎖的自旋，其本質(zhì)都是在一個(gè)循環(huán)中執(zhí)行CAS操作。

4.2 概念層次的區(qū)別

• CAS是原子操作：它處于一個(gè)非常低的層次，是一種硬件級(jí)別的指令或其軟件封裝。它本身不是鎖，而是一種實(shí)現(xiàn)同步的工具。
• 自旋鎖是鎖機(jī)制：它處于較高的抽象層次，是一種同步原語(yǔ)（Synchronization Primitive）。它利用CAS這個(gè)工具，構(gòu)建出一種用于保護(hù)臨界區(qū)、實(shí)現(xiàn)互斥訪問(wèn)的鎖定策略。

簡(jiǎn)而言之，可以說(shuō) 自旋鎖是一種使用CAS作為原子性保障的“忙等待”鎖算法。

4.3 目標(biāo)與用途的區(qū)別

• CAS的目標(biāo)是提供一種無(wú)鎖的、點(diǎn)對(duì)點(diǎn)的原子更新方案。它的應(yīng)用非常廣泛，是無(wú)鎖編程范式的核心，常用于實(shí)現(xiàn)高性能的無(wú)鎖數(shù)據(jù)結(jié)構(gòu)（如ConcurrentLinkedQueue）、原子變量、樂(lè)觀鎖等。
• 自旋鎖的目標(biāo)是作為一種替代傳統(tǒng)阻塞鎖的方案，在特定場(chǎng)景下（鎖持有時(shí)間極短）避免線程上下文切換的開銷，從而提高程序的響應(yīng)速度和吞吐量。它依然是一種“鎖”，遵循加鎖-執(zhí)行-解鎖的模式來(lái)保護(hù)一段代碼塊。

5. 性能對(duì)比與場(chǎng)景選擇

在實(shí)際開發(fā)中，選擇CAS、自旋鎖還是阻塞鎖，需要對(duì)應(yīng)用場(chǎng)景的并發(fā)特性有清晰的認(rèn)識(shí)。

5.1 性能考量

• 低競(jìng)爭(zhēng)場(chǎng)景：在這種情況下，線程之間很少發(fā)生沖突。
  • CAS/自旋鎖：性能表現(xiàn)最佳。線程通常在第一次嘗試時(shí)就能通過(guò)CAS成功獲取鎖或完成更新，幾乎沒有額外開銷 。
  • synchronized：由于JVM的偏向鎖和輕量級(jí)鎖優(yōu)化，此時(shí)的synchronized幾乎沒有鎖競(jìng)爭(zhēng)，開銷也極低，性能接近CAS。
• 高競(jìng)爭(zhēng)場(chǎng)景：大量線程同時(shí)爭(zhēng)搶同一資源。
  • 自旋鎖：性能會(huì)急劇惡化。大量線程空轉(zhuǎn)，不僅浪費(fèi)CPU周期，還會(huì)因?yàn)榉磸?fù)嘗試CAS操作而導(dǎo)致總線流量劇增，引發(fā)緩存一致性協(xié)議的頻繁通信（緩存行失效），嚴(yán)重影響整體性能。
  • CAS：性能同樣會(huì)下降，因?yàn)槭『椭卦嚨拇螖?shù)增多，但通常比純粹的自旋鎖表現(xiàn)要好，因?yàn)樗皇且环N操作，而非一種持續(xù)占用的狀態(tài)。
  • 阻塞鎖（synchronized重量級(jí)鎖, ReentrantLock）‍ ：盡管線程上下文切換有固定開銷，但在高競(jìng)爭(zhēng)下，讓無(wú)法獲取鎖的線程進(jìn)入阻塞狀態(tài)并讓出CPU，反而是一種更優(yōu)的選擇。這避免了CPU資源的無(wú)效消耗，可以提供更穩(wěn)定和可預(yù)測(cè)的吞吐量。

5.2 場(chǎng)景選擇指南

1. 優(yōu)先選擇原子類（基于CAS）‍ ：當(dāng)你的同步需求僅限于對(duì)單個(gè)共享變量（如計(jì)數(shù)器、狀態(tài)標(biāo)志）的原子更新時(shí)，java.util.concurrent.atomic包下的類是首選。它簡(jiǎn)單、高效且不易出錯(cuò)。

2. 審慎選擇自旋鎖：僅在你確信鎖的持有時(shí)間極短（通常在幾十個(gè)納秒級(jí)別），臨界區(qū)內(nèi)不包含任何可能導(dǎo)致線程阻塞的操作（如I/O），且運(yùn)行在多核環(huán)境下時(shí)，才考慮使用自定義自旋鎖。在大多數(shù)情況下，JVM對(duì)synchronized的自適應(yīng)自旋優(yōu)化已經(jīng)足夠好。

3. 常規(guī)選擇synchronized或ReentrantLock：對(duì)于絕大多數(shù)業(yè)務(wù)場(chǎng)景，特別是臨界區(qū)邏輯復(fù)雜、執(zhí)行時(shí)間不可控或存在激烈競(jìng)爭(zhēng)時(shí)，傳統(tǒng)的阻塞鎖是更安全、更健壯的選擇。得益于JVM多年來(lái)的鎖優(yōu)化（偏向鎖、輕量級(jí)鎖、自適應(yīng)自旋、鎖粗化、鎖消除），synchronized在許多場(chǎng)景下的性能已經(jīng)非常出色，并且語(yǔ)法簡(jiǎn)單。ReentrantLock則提供了更豐富的功能（如可中斷的等待、公平性選擇、嘗試獲取鎖等），適用于更復(fù)雜的同步需求 。

總結(jié) 

到此這篇關(guān)于Java中自旋鎖與CAS機(jī)制深層關(guān)系與區(qū)別的文章就介紹到這了,更多相關(guān)Java自旋鎖與CAS機(jī)制內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評(píng)論