Categories
程式開發

聊聊 Java 的幾把 JVM 級鎖


簡介

在計算機行業有一個定律叫”摩爾定律”,在此定律下,計算機的性能突飛猛進,而且價格也隨之越來越便宜, CPU 從單核到了多核,緩存性能也得到了很大提升,尤其是多核CPU 技術的到來,計算機同一時刻可以處理多個任務。在硬件層面的發展帶來的效率極大提升中,軟件層面的多線程編程已經成為必然趨勢,然而多線程編程就會引入數據安全性問題,有矛必有盾,於是發明了“鎖”來解決線程安全問題。在這篇文章中,總結了 Java 中幾把經典的 JVM 級別的鎖。

synchronized

synchronized 關鍵字是一把經典的鎖,也是我們平時用得最多的。在JDK1.6 之前, syncronized 是一把重量級的鎖,不過隨著JDK 的升級,也在對它進行不斷的優化,如今它變得不那麼重了,甚至在某些場景下,它的性能反而優於輕量級鎖。在加了 syncronized 關鍵字的方法、代碼塊中,一次只允許一個線程進入特定代碼段,從而避免多線程同時修改同一數據。

synchronized 鎖有如下幾個特點:

有鎖升級過程

在JDK1.5 (含)之前, synchronized 的底層實現是重量級的,所以之前一致稱呼它為”重量級鎖”,在JDK1.5 之後,對synchronized 進行了各種優化,它變得不那麼重了,實現原理就是鎖升級的過程。我們先聊聊 1.5 之後的 synchronized 實現原理是怎樣的。說到 synchronized 加鎖原理,就不得不先說 Java 對像在內存中的佈局, Java 對象內存佈局如下:

聊聊 Java 的幾把 JVM 級鎖 1

如上圖所示,在創建一個對像後,在 JVM 虛擬機( HotSpot )中,對像在 Java 內存中的存儲佈局 可分為三塊:

對像頭區域此處存儲的信息包括兩部分

1、對象自身的運行時數據( MarkWord )

存儲hashCode、GC 分代年齡、鎖類型標記、偏向鎖線程ID 、 CAS 鎖指向線程LockRecord 的指針等, synconized 鎖的機制與這個部分( markwork )密切相關,用markword 中最低的三位代表鎖的狀態,其中一位是偏向鎖位,另外兩位是普通鎖位。

2、對像類型指針( Class Pointer )

對象指向它的類元數據的指針、 JVM 就是通過它來確定是哪個 Class 的實例。

實例數據區域

此處存儲的是對象真正有效的信息,比如對像中所有字段的內容

對齊填充區域

JVM 的實現HostSpot 規定對象的起始地址必須是8 字節的整數倍,換句話來說,現在64 位的OS 往外讀取數據的時候一次性讀取64bit 整數倍的數據,也就是8 個字節,所以HotSpot 為了高效讀取對象,就做了”對齊”,如果一個對象實際佔的內存大小不是8byte 的整數倍時,就”補位”到8byte 的整數倍。所以對齊填充區域的大小不是固定的。

當線程進入到 synchronized 處嘗試獲取該鎖時, synchronized 鎖升級流程如下:

聊聊 Java 的幾把 JVM 級鎖 2

如上圖所示, synchronized 鎖升級的順序為:偏向鎖->輕量級鎖->重量級鎖,每一步觸發鎖升級的情況如下:

偏向鎖

在 JDK1.8 中,其實默認是輕量級鎖,但如果設定了 -XX:BiasedLockingStartupDelay = 0 ,那在對一個 Object 做 syncronized 的時候,會立即上一把偏向鎖。當處於偏向鎖狀態時, markwork 會記錄當前線程 ID 。

升級到輕量級鎖

當下一個線程參與到偏向鎖競爭時,會先判斷 markword 中保存的線程 ID 是否與這個線程 ID 相等,如果不相等,會立即撤銷偏向鎖,升級為輕量級鎖。每個線程在自己的線程棧中生成一個LockRecord ( LR ),然後每個線程通過CAS (自旋)的操作將鎖對像頭中的markwork 設置為指向自己的LR 的指針,哪個線程設置成功,就意味著獲得鎖。關於 synchronized 中此時執行的 CAS 操作是通過 native 的調用 HotSpot 中 bytecodeInterpreter.cpp 文件 C++ 代碼實現的,有興趣的可以繼續深挖。

升級到重量級鎖

如果鎖競爭加劇(如線程自旋次數或者自旋的線程數超過某閾值, JDK1.6 之後,由 JVM 自己控制該規則),就會升級為重量級鎖。此時就會向操作系統申請資源,線程掛起,進入到操作系統內核態的等待隊列中,等待操作系統調度,然後映射回用戶態。在重量級鎖中,由於需要做內核態到用戶態的轉換,而這個過程中需要消耗較多時間,也就是”重”的原因之一。

可重入

synchronized 擁有強制原子性的內部鎖機制,是一把可重入鎖。因此,在一個線程使用 synchronized 方法時調用該對象另一個 synchronized 方法,即一個線程得到一個對象鎖後再次請求該對象鎖,是永遠可以拿到鎖的。在 Java 中線程獲得對象鎖的操作是以線程為單位的,而不是以調用為單位的。 synchronized 鎖的對像頭的 markwork 中會記錄該鎖的線程持有者和計數器,當一個線程請求成功後, JVM 會記下持有鎖的線程,並將計數器計為1。此時其他線程請求該鎖,則必須等待。而該持有鎖的線程如果再次請求這個鎖,就可以再次拿到這個鎖,同時計數器會遞增。當線程退出一個 synchronized 方法/塊時,計數器會遞減,如果計數器為 0 則釋放該鎖鎖。

悲觀鎖(互斥鎖、排他鎖)

synchronized 是一把悲觀鎖(獨占鎖),當前線程如果獲取到鎖,會導致其它所有需要鎖該的線程等待,一直等待持有鎖的線程釋放鎖才繼續進行鎖的爭搶。

ReentrantLock

ReentrantLock 從字面可以看出是一把可重入鎖,這點和synchronized 一樣,但實現原理也與syncronized 有很大差別,它是基於經典的AQS(AbstractQueueSyncronized) 實現的, AQS 是基於volitale 和CAS 實現的,其中AQS 中維護一個valitale 類型的變量state 來做一個可重入鎖的重入次數,加鎖和釋放鎖也是圍繞這個變量來進行的。 ReentrantLock 也提供了一些 synchronized 沒有的特點,因此比 synchronized 好用。

AQS模型如下圖

聊聊 Java 的幾把 JVM 級鎖 3

ReentrantLock 有如下特點:

1、可重入

ReentrantLock 和syncronized 關鍵字一樣,都是可重入鎖,不過兩者實現原理稍有差別, RetrantLock 利用AQS 的的state 狀態來判斷資源是否已鎖,同一線程重入加鎖, state 的狀態+1 ;同一線程重入解鎖, state 狀態-1 (解鎖必須為當前獨占線程,否則異常); 當state 為0 時解鎖成功。

2、需要手動加鎖、解鎖

synchronized 關鍵字是自動進行加鎖、解鎖的,而 ReentrantLock 需要 lock() 和 unlock() 方法配合 try/finally 語句塊來完成,來手動加鎖、解鎖。

3、支持設置鎖的超時時間

synchronized 關鍵字無法設置鎖的超時時間,如果一個獲得鎖的線程內部發生死鎖,那麼其他線程就會一直進入阻塞狀態,而ReentrantLock 提供tryLock 方法,允許設置線程獲取鎖的超時時間,如果超時,則跳過,不進行任何操作,避免死鎖的發生。

4、支持公平/非公平鎖

synchronized 關鍵字是一種非公平鎖,先搶到鎖的線程先執行。而ReentrantLock 的構造方法中允許設置true/false 來實現公平、非公平鎖,如果設置為true ,則線程獲取鎖要遵循”先來後到”的規則,每次都會構造一個線程Node ,然後到雙向鍊錶的”尾巴”後面排隊,等待前面的Node 釋放鎖資源。

5、可中斷鎖

ReentrantLock 中的lockInterruptibly() 方法使得線程可以在被阻塞時響應中斷,比如一個線程t1 通過lockInterruptibly() 方法獲取到一個可重入鎖,並執行一個長時間的任務,另一個線程通過interrupt() 方法就可以立刻打斷t1 線程的執行,來獲取t1持有的那個可重入鎖。而通過 ReentrantLock 的 lock() 方法或者 Synchronized 持有鎖的線程是不會響應其他線程的 interrupt() 方法的,直到該方法主動釋放鎖之後才會響應 interrupt() 方法。

ReentrantReadWriteLock

ReentrantReadWriteLock (讀寫鎖)其實是兩把鎖,一把是 WriteLock (寫鎖),一把是讀鎖, ReadLock 。讀寫鎖的規則是:讀讀不互斥、讀寫互斥、寫寫互斥。在一些實際的場景中,讀操作的頻率遠遠高於寫操作,如果直接用一般的鎖進行並發控制的話,就會讀讀互斥、讀寫互斥、寫寫互斥,效率低下,讀寫鎖的產生就是為了優化這種場景的操作效率。一般情況下獨占鎖的效率低來源於高並發下對臨界區的激烈競爭導致線程上下文切換。因此當並發不是很高的情況下,讀寫鎖由於需要額外維護讀鎖的狀態,可能還不如獨占鎖的效率高,因此需要根據實際情況選擇使用。

ReentrantReadWriteLock 的原理也是基於 AQS 進行實現的,與 ReentrantLock 的差別在於 ReentrantReadWriteLock 鎖擁有共享鎖、排他鎖屬性。讀寫鎖中的加鎖、釋放鎖也是基於 Sync (繼承於 AQS ),並且主要使用 AQS 中的 state 和 node 中的 waitState 變量進行實現的。實現讀寫鎖與實現普通互斥鎖的主要區別在於需要分別記錄讀鎖狀態及寫鎖狀態,並且等待隊列中需要區別處理兩種加鎖操作。 ReentrantReadWriteLock 中將 AQS 中的 int 類型的 state 分為高 16 位與第 16 位分別記錄讀鎖和寫鎖的狀態,如下圖所示:

聊聊 Java 的幾把 JVM 級鎖 4

WriteLock(寫鎖)是悲觀鎖(排他鎖、互斥鎖)

通過計算 state&((1<<16)-1) ,將 state 的高 16 位全部抹去,因此 state 的低位記錄著寫鎖的重入計數。

獲取寫鎖源碼:

/**
         * 获取写锁
           Acquires the write lock.
         *  如果此时没有任何线程持有写锁或者读锁,那么当前线程执行CAS操作更新status,
         *  若更新成功,则设置读锁重入次数为1,并立即返回
         * 

Acquires the write lock if neither the read nor write lock * are held by another thread * and returns immediately, setting the write lock hold count to * one. * 如果当前线程已经持有该写锁,那么将写锁持有次数设置为1,并立即返回 *

If the current thread already holds the write lock then the * hold count is incremented by one and the method returns * immediately. * 如果该锁已经被另外一个线程持有,那么停止该线程的CPU调度并进入休眠状态, * 直到该写锁被释放,且成功将写锁持有次数设置为1才表示获取写锁成功 *

If the lock is held by another thread then the current * thread becomes disabled for thread scheduling purposes and * lies dormant until the write lock has been acquired, at which * time the write lock hold count is set to one. */ public void lock() { sync.acquire(1); } /** * 该方法为以独占模式获取锁,忽略中断 * 如果调用一次该“tryAcquire”方法更新status成功,则直接返回,代表抢锁成功 * 否则,将会进入同步队列等待,不断执行“tryAcquire”方法尝试CAS更新status状态,直到成功抢到锁 * 其中“tryAcquire”方法在NonfairSync(公平锁)中和FairSync(非公平锁)中都有各自的实现 * * Acquires in exclusive mode, ignoring interrupts. Implemented * by invoking at least once {@link #tryAcquire}, * returning on success. Otherwise the thread is queued, possibly * repeatedly blocking and unblocking, invoking {@link * #tryAcquire} until success. This method can be used * to implement method {@link Lock#lock}. * * @param arg the acquire argument. This value is conveyed to * {@link #tryAcquire} but is otherwise uninterpreted and * can represent anything you like. */ public final void acquire(int arg) { if (!tryAcquire(arg) && acquireQueued(addWaiter(Node.EXCLUSIVE), arg)) selfInterrupt(); } protected final boolean tryAcquire(int acquires) { /* * Walkthrough: * 1、如果读写锁的计数不为0,且持有锁的线程不是当前线程,则返回false * 1. If read count nonzero or write count nonzero * and owner is a different thread, fail. * 2、如果持有锁的计数不为0且计数总数超过限定的最大值,也返回false * 2. If count would saturate, fail. (This can only * happen if count is already nonzero.) * 3、如果该锁是可重入或该线程在队列中的策略是允许它尝试抢锁,那么该线程就能获取锁 * 3. Otherwise, this thread is eligible for lock if * it is either a reentrant acquire or * queue policy allows it. If so, update state * and set owner. */ Thread current = Thread.currentThread(); //获取读写锁的状态 int c = getState(); //获取该写锁重入的次数 int w = exclusiveCount(c); //如果读写锁状态不为0,说明已经有其他线程获取了读锁或写锁 if (c != 0) { //如果写锁重入次数为0,说明有线程获取到读锁,根据“读写锁互斥”原则,返回false //或者如果写锁重入次数不为0,且获取写锁的线程不是当前线程,根据"写锁独占"原则,返回false // (Note: if c != 0 and w == 0 then shared count != 0) if (w == 0 || current != getExclusiveOwnerThread()) return false; //如果写锁可重入次数超过最大次数(65535),则抛异常 if (w + exclusiveCount(acquires) > MAX_COUNT) throw new Error("Maximum lock count exceeded"); //到这里说明该线程是重入写锁,更新重入写锁的计数(+1),返回true // Reentrant acquire setState(c + acquires); return true; } //如果读写锁状态为0,说明读锁和写锁都没有被获取,会走下面两个分支: //如果要阻塞或者执行CAS操作更新读写锁的状态失败,则返回false //如果不需要阻塞且CAS操作成功,则当前线程成功拿到锁,设置锁的owner为当前线程,返回true if (writerShouldBlock() || !compareAndSetState(c, c + acquires)) return false; setExclusiveOwnerThread(current); return true; }

釋放寫鎖源碼:

/*
  * Note that tryRelease and tryAcquire can be called by
  * Conditions. So it is possible that their arguments contain
  * both read and write holds that are all released during a
  * condition wait and re-established in tryAcquire.
  */
 protected final boolean tryRelease(int releases) {
     //若锁的持有者不是当前线程,抛出异常
     if (!isHeldExclusively())
         throw new IllegalMonitorStateException();
     //写锁的可重入计数减掉releases个
     int nextc = getState() - releases;
     //如果写锁重入计数为0了,则说明写锁被释放了
     boolean free = exclusiveCount(nextc) == 0;
     if (free)
        //若写锁被释放,则将锁的持有者设置为null,进行GC
        setExclusiveOwnerThread(null);
     //更新写锁的重入计数
     setState(nextc);
     return free;
 }

ReadLock(讀鎖)是共享鎖(樂觀鎖)

通過計算 state>>>16 進行無符號補 0 ,右移 16 位,因此 state 的高位記錄著寫鎖的重入計數.

讀鎖獲取鎖的過程比寫鎖稍微複雜些,首先判斷寫鎖是否為0 並且當前線程不佔有獨占鎖,直接返回;否則,判斷讀線程是否需要被阻塞並且讀鎖數量是否小於最大值並且比較設置狀態成功,若當前沒有讀鎖,則設置第一個讀線程firstReader 和firstReaderHoldCount ;若當前線程線程為第一個讀線程,則增加firstReaderHoldCount ;否則,將設置當前線程對應的HoldCounter 對象的值,更新成功後會在firstReaderHoldCount 中readHolds ( ThreadLocal 類型的)的本線程副本中記錄當前線程重入數,這是為了實現JDK1.6 中加入的getReadHoldCount ()方法的,這個方法能獲取當前線程重入共享鎖的次數( state 中記錄的是多個線程的總重入次數),加入了這個方法讓代碼複雜了不少,但是其原理還是很簡單的:如果當前只有一個線程的話,還不需要動用ThreadLocal ,直接往firstReaderHoldCount 這個成員變量裡存重入數,當有第二個線程來的時候,就要動用 ThreadLocal 變量 readHolds 了,每個線程擁有自己的副本,用來保存自己的重入數。

獲取讀鎖源碼:

/**
         * 获取读锁
         * Acquires the read lock.
         * 如果写锁未被其他线程持有,执行CAS操作更新status值,获取读锁后立即返回
         * 

Acquires the read lock if the write lock is not held by * another thread and returns immediately. * * 如果写锁被其他线程持有,那么停止该线程的CPU调度并进入休眠状态,直到该读锁被释放 *

If the write lock is held by another thread then * the current thread becomes disabled for thread scheduling * purposes and lies dormant until the read lock has been acquired. */ public void lock() { sync.acquireShared(1); } /** * 该方法为以共享模式获取读锁,忽略中断 * 如果调用一次该“tryAcquireShared”方法更新status成功,则直接返回,代表抢锁成功 * 否则,将会进入同步队列等待,不断执行“tryAcquireShared”方法尝试CAS更新status状态,直到成功抢到锁 * 其中“tryAcquireShared”方法在NonfairSync(公平锁)中和FairSync(非公平锁)中都有各自的实现 * (看这注释是不是和写锁很对称) * Acquires in shared mode, ignoring interrupts. Implemented by * first invoking at least once {@link #tryAcquireShared}, * returning on success. Otherwise the thread is queued, possibly * repeatedly blocking and unblocking, invoking {@link * #tryAcquireShared} until success. * * @param arg the acquire argument. This value is conveyed to * {@link #tryAcquireShared} but is otherwise uninterpreted * and can represent anything you like. */ public final void acquireShared(int arg) { if (tryAcquireShared(arg) < 0) doAcquireShared(arg); } protected final int tryAcquireShared(int unused) { /* * Walkthrough: * 1、如果已经有其他线程获取到了写锁,根据“读写互斥”原则,抢锁失败,返回-1 * 1.If write lock held by another thread, fail. * 2、如果该线程本身持有写锁,那么看一下是否要readerShouldBlock,如果不需要阻塞, * 则执行CAS操作更新state和重入计数。 * 这里要注意的是,上面的步骤不检查是否可重入(因为读锁属于共享锁,天生支持可重入) * 2. Otherwise, this thread is eligible for * lock wrt state, so ask if it should block * because of queue policy. If not, try * to grant by CASing state and updating count. * Note that step does not check for reentrant * acquires, which is postponed to full version * to avoid having to check hold count in * the more typical non-reentrant case. * 3、如果因为CAS更新status失败或者重入计数超过最大值导致步骤2执行失败 * 那就进入到fullTryAcquireShared方法进行死循环,直到抢锁成功 * 3. If step 2 fails either because thread * apparently not eligible or CAS fails or count * saturated, chain to version with full retry loop. */ //当前尝试获取读锁的线程 Thread current = Thread.currentThread(); //获取该读写锁状态 int c = getState(); //如果有线程获取到了写锁 ,且获取写锁的不是当前线程则返回失败 if (exclusiveCount(c) != 0 && getExclusiveOwnerThread() != current) return -1; //获取读锁的重入计数 int r = sharedCount(c); //如果读线程不应该被阻塞,且重入计数小于最大值,且CAS执行读锁重入计数+1成功,则执行线程重入的计数加1操作,返回成功 if (!readerShouldBlock() && r 0; } else { //如果当前线程不是第一个获取到读锁的线程(也就是说至少有有一个线程获取到了读锁) // if (rh == null) { rh = cachedHoldCounter; if (rh == null || rh.tid != getThreadId(current)) { rh = readHolds.get(); if (rh.count == 0) readHolds.remove(); } } if (rh.count == 0) return -1; } } /** *下面是既没有线程获取写锁,当前线程又不需要阻塞的情况 */ //重入次数等于最大重入次数,抛异常 if (sharedCount(c) == MAX_COUNT) throw new Error("Maximum lock count exceeded"); //如果执行CAS操作成功将读写锁的重入计数加1,则对当前持有这个共享读锁的线程的重入计数加1,然后返回成功 if (compareAndSetState(c, c + SHARED_UNIT)) { if (sharedCount(c) == 0) { firstReader = current; firstReaderHoldCount = 1; } else if (firstReader == current) { firstReaderHoldCount++; } else { if (rh == null) rh = cachedHoldCounter; if (rh == null || rh.tid != getThreadId(current)) rh = readHolds.get(); else if (rh.count == 0) readHolds.set(rh); rh.count++; cachedHoldCounter = rh; // cache for release } return 1; } } }

釋放讀鎖源碼:

/**
  * Releases in shared mode.  Implemented by unblocking one or more
  * threads if {@link #tryReleaseShared} returns true.
  *
  * @param arg the release argument.  This value is conveyed to
  *        {@link #tryReleaseShared} but is otherwise uninterpreted
  *        and can represent anything you like.
  * @return the value returned from {@link #tryReleaseShared}
  */
public final boolean releaseShared(int arg) {
    if (tryReleaseShared(arg)) {//尝试释放一次共享锁计数
        doReleaseShared();//真正释放锁
        return true;
    }
        return false;
}
/**
 *此方法表示读锁线程释放锁。
 *首先判断当前线程是否为第一个读线程firstReader,
 *若是,则判断第一个读线程占有的资源数firstReaderHoldCount是否为1,
  若是,则设置第一个读线程firstReader为空,否则,将第一个读线程占有的资源数firstReaderHoldCount减1;
  若当前线程不是第一个读线程,
  那么首先会获取缓存计数器(上一个读锁线程对应的计数器 ),
  若计数器为空或者tid不等于当前线程的tid值,则获取当前线程的计数器,
  如果计数器的计数count小于等于1,则移除当前线程对应的计数器,
  如果计数器的计数count小于等于0,则抛出异常,之后再减少计数即可。
  无论何种情况,都会进入死循环,该循环可以确保成功设置状态state
 */
protected final boolean tryReleaseShared(int unused) {
      // 获取当前线程
      Thread current = Thread.currentThread();
      if (firstReader == current) { // 当前线程为第一个读线程
          // assert firstReaderHoldCount > 0;
         if (firstReaderHoldCount == 1) // 读线程占用的资源数为1
              firstReader = null;
          else // 减少占用的资源
              firstReaderHoldCount--;
     } else { // 当前线程不为第一个读线程
         // 获取缓存的计数器
         HoldCounter rh = cachedHoldCounter;
         if (rh == null || rh.tid != getThreadId(current)) // 计数器为空或者计数器的tid不为当前正在运行的线程的tid
             // 获取当前线程对应的计数器
             rh = readHolds.get();
         // 获取计数
         int count = rh.count;
         if (count <= 1) { // 计数小于等于1
             // 移除
             readHolds.remove();
             if (count <= 0) // 计数小于等于0,抛出异常
                 throw unmatchedUnlockException();
         }
         // 减少计数
         --rh.count;
     }
     for (;;) { // 死循环
         // 获取状态
         int c = getState();
         // 获取状态
         int nextc = c - SHARED_UNIT;
         if (compareAndSetState(c, nextc)) // 比较并进行设置
             // Releasing the read lock has no effect on readers,
             // but it may allow waiting writers to proceed if
             // both read and write locks are now free.
             return nextc == 0;
     }
 }
 /**真正释放锁
  * Release action for shared mode -- signals successor and ensures
  * propagation. (Note: For exclusive mode, release just amounts
  * to calling unparkSuccessor of head if it needs signal.)
  */
private void doReleaseShared() {
        /*
         * Ensure that a release propagates, even if there are other
         * in-progress acquires/releases.  This proceeds in the usual
         * way of trying to unparkSuccessor of head if it needs
         * signal. But if it does not, status is set to PROPAGATE to
         * ensure that upon release, propagation continues.
         * Additionally, we must loop in case a new node is added
         * while we are doing this. Also, unlike other uses of
         * unparkSuccessor, we need to know if CAS to reset status
         * fails, if so rechecking.
         */
        for (;;) {
            Node h = head;
            if (h != null && h != tail) {
                int ws = h.waitStatus;
                if (ws == Node.SIGNAL) {
                    if (!compareAndSetWaitStatus(h, Node.SIGNAL, 0))
                        continue;            // loop to recheck cases
                    unparkSuccessor(h);
                }
                else if (ws == 0 &&
                         !compareAndSetWaitStatus(h, 0, Node.PROPAGATE))
                    continue;                // loop on failed CAS
            }
            if (h == head)                   // loop if head changed
                break;
        }
    }

通過分析可以看出:

在線程持有讀鎖的情況下,該線程不能取得寫鎖(因為獲取寫鎖的時候,如果發現當前的讀鎖被佔用,就馬上獲取失敗,不管讀鎖是不是被當前線程持有)。

在線程持有寫鎖的情況下,該線程可以繼續獲取讀鎖(獲取讀鎖時如果發現寫鎖被佔用,只有寫鎖沒有被當前線程佔用的情況才會獲取失敗)。

LongAdder

在高並發的情況下,我們對一個 Integer 類型的整數直接進行 i++ 的時候,無法保證操作的原子性,會出現線程安全的問題。為此我們會用 juc 下的 AtomicInteger ,它是一個提供原子操作的 Interger 類,內部也是通過 CAS 實現線程安全的。但當大量線程同時去訪問時,就會因為大量線程執行 CAS 操作失敗而進行空旋轉,導致 CPU 資源消耗過多,而且執行效率也不高。 Doug Lea 大神應該也不滿意,於是在 JDK1.8 中對 CAS 進行了優化,提供了 LongAdder ,它是基於了 CAS 分段鎖的思想實現的。

線程去讀寫一個 LongAdder 類型的變量時,流程如下:

聊聊 Java 的幾把 JVM 級鎖 5

LongAdder 也是基於 Unsafe 提供的 CAS 操作 +valitale 去實現的。在LongAdder 的父類Striped64 中維護著一個base 變量和一個cell 數組,當多個線程操作一個變量的時候,先會在這個base 變量上進行cas 操作,當它發現線程增多的時候,就會使用cell數組。比如當base 將要更新的時候發現線程增多(也就是調用casBase 方法更新base 值失敗),那麼它會自動使用cell 數組,每一個線程對應於一個cell ,在每一個線程中對該cell 進行cas 操作,這樣就可以將單一value 的更新壓力分擔到多個value 中去,降低單個value 的“熱度”,同時也減少了大量線程的空轉,提高並發效率,分散並發壓力。這種分段鎖需要額外維護一個內存空間 cells ,不過在高並發場景下,這點成本幾乎可以忽略。分段鎖是一種優秀的優化思想, juc 中提供的的 ConcurrentHashMap 也是基於分段鎖保證讀寫操作的線程安全。

作者介紹

夏傑,花名楚昭,現就職於阿里巴巴企業智能事業部BUC&ACL&SSO 團隊,面向阿里巴巴經濟體提供人員賬號的權限管控、應用數據安全訪問治理,並通過現有的技術沉澱與領域模型,致力於打造To B、To G 領域的應用信息化架構的基礎設施SAAS 產品MOZI 。

本文轉載自公眾號阿里巴巴中間件(ID:Aliware_2018)。

原文鏈接

https://mp.weixin.qq.com/s/h3VIUyH9L0v14MrQJiiDbw