鎖（lock）的代價

鎖是用來做併發最簡單的方式，當然其代價也是最高的。核心態的鎖的時候需要作業系統進行一次上下文切換，加鎖、釋放鎖會導致比較多的上下文切換和排程延時，等待鎖的執行緒會被掛起直至鎖釋放。在上下文切換的時候，cpu之前快取的指令和資料都將失效，對效能有很大的損失。作業系統對多執行緒的鎖進行判斷就像兩姐妹在為一個玩具在爭吵，然後作業系統就是能決定他們誰能拿到玩具的父母，這是很慢的。使用者態的鎖雖然避免了這些問題，但是其實它們只是在沒有真實的競爭時才有效。

Java在JDK1.5之前都是靠synchronized關鍵字保證同步的，這種通過使用一致的鎖定協議來協調對共享狀態的訪問，可以確保無論哪個執行緒持有守護變數的鎖，都採用獨佔的方式來訪問這些變數，如果出現多個執行緒同時訪問鎖，那第一些線執行緒將被掛起，當執行緒恢復執行時，必須等待其它執行緒執行完他們的時間片以後才能被排程執行，在掛起和恢復執行過程中存在著很大的開銷。鎖還存在著其它一些缺點，當一個執行緒正在等待鎖時，它不能做任何事。如果一個執行緒在持有鎖的情況下被延遲執行，那麼所有需要這個鎖的執行緒都無法執行下去。如果被阻塞的執行緒優先順序高，而持有鎖的執行緒優先順序低，將會導致優先順序反轉(Priority Inversion)。

樂觀鎖與悲觀鎖

獨佔鎖是一種悲觀鎖，synchronized就是一種獨佔鎖，它假設最壞的情況，並且只有在確保其它執行緒不會造成干擾的情況下執行，會導致其它所有需要鎖的執行緒掛起，等待持有鎖的執行緒釋放鎖。而另一個更加有效的鎖就是樂觀鎖。所謂樂觀鎖就是，每次不加鎖而是假設沒有衝突而去完成某項操作，如果因為衝突失敗就重試，直到成功為止。

volatile的問題

與鎖相比，volatile變數是一和更輕量級的同步機制，因為在使用這些變數時不會發生上下文切換和執行緒排程等操作，但是volatile變數也存在一些侷限：不能用於構建原子的複合操作，因此當一個變數依賴舊值時就不能使用volatile變數。（參考：

談談volatiile）

volatile只能保證變數對各個執行緒的可見性，但不能保證原子性。為什麼？見我的另外一篇文章：《為什麼volatile不能保證原子性而Atomic可以？》

Java中的原子操作( atomic operations)

原子操作指的是在一步之內就完成而且不能被中斷。原子操作在多執行緒環境中是執行緒安全的，無需考慮同步的問題。在java中，下列操作是原子操作：

• all assignments of primitive types except for long and double
• all assignments of references
• all operations of java.concurrent.Atomic* classes
• all assignments to volatile longs and doubles

問題來了，為什麼long型賦值不是原子操作呢？例如：

1	long foo = 65465498L;

實時上java會分兩步寫入這個long變數，先寫32位，再寫後32位。這樣就執行緒不安全了。如果改成下面的就執行緒安全了：

1	private volatile long foo;

因為volatile內部已經做了synchronized.

CAS無鎖演算法

要實現無鎖（lock-free）的非阻塞演算法有多種實現方法，其中CAS（比較與交換，Compare and swap）是一種有名的無鎖演算法。CAS, CPU指令，在大多數處理器架構，包括IA32、Space中採用的都是CAS指令，CAS的語義是“我認為V的值應該為A，如果是，那麼將V的值更新為B，否則不修改並告訴V的值實際為多少”，CAS是項樂觀鎖技術，當多個執行緒嘗試使用CAS同時更新同一個變數時，只有其中一個執行緒能更新變數的值，而其它執行緒都失敗，失敗的執行緒並不會被掛起，而是被告知這次競爭中失敗，並可以再次嘗試。CAS有3個運算元，記憶體值V，舊的預期值A，要修改的新值B。當且僅當預期值A和記憶體值V相同時，將記憶體值V修改為B，否則什麼都不做。CAS無鎖演算法的C實現如下：

1 2 3 4 5 6 7 8 9

int compare_and_swap (int* reg, int oldval, int newval) { ATOMIC(); int old_reg_val = *reg; if (old_reg_val == oldval) *reg = newval; END_ATOMIC(); return old_reg_val; }

CAS（樂觀鎖演算法）的基本假設前提

CAS比較與交換的虛擬碼可以表示為：

do{   
       備份舊資料；  
       基於舊資料構造新資料；  
}while(!CAS( 記憶體地址，備份的舊資料，新資料 ))  

 

（上圖的解釋：CPU去更新一個值，但如果想改的值不再是原來的值，操作就失敗，因為很明顯，有其它操作先改變了這個值。）

就是指當兩者進行比較時，如果相等，則證明共享資料沒有被修改，替換成新值，然後繼續往下執行；如果不相等，說明共享資料已經被修改，放棄已經所做的操作，然後重新執行剛才的操作。容易看出 CAS 操作是基於共享資料不會被修改的假設，採用了類似於資料庫的 commit-retry 的模式。當同步衝突出現的機會很少時，這種假設能帶來較大的效能提升。

CAS的開銷（CPU Cache Miss problem）

前面說過了，CAS（比較並交換）是CPU指令級的操作，只有一步原子操作，所以非常快。而且CAS避免了請求作業系統來裁定鎖的問題，不用麻煩作業系統，直接在CPU內部就搞定了。但CAS就沒有開銷了嗎？不！有cache miss的情況。這個問題比較複雜，首先需要了解CPU的硬體體系結構：

上圖可以看到一個8核CPU計算機系統，每個CPU有cache（CPU內部的快取記憶體，暫存器），管芯內還帶有一個互聯模組，使管芯內的兩個核可以互相通訊。在圖中央的系統互聯模組可以讓四個管芯相互通訊，並且將管芯與主存連線起來。資料以“快取線”為單位在系統中傳輸，“快取線”對應於記憶體中一個 2 的冪大小的位元組塊，大小通常為 32 到 256 位元組之間。當 CPU 從記憶體中讀取一個變數到它的暫存器中時，必須首先將包含了該變數的快取線讀取到 CPU 快取記憶體。同樣地，CPU 將暫存器中的一個值儲存到記憶體時，不僅必須將包含了該值的快取線讀到 CPU 快取記憶體，還必須確保沒有其他 CPU 擁有該快取線的拷貝。

比如，如果 CPU0 在對一個變數執行“比較並交換”（CAS）操作，而該變數所在的快取線在 CPU7 的快取記憶體中，就會發生以下經過簡化的事件序列：

• CPU0 檢查本地快取記憶體，沒有找到快取線。
• 請求被轉發到 CPU0 和 CPU1 的互聯模組，檢查 CPU1 的本地快取記憶體，沒有找到快取線。
• 請求被轉發到系統互聯模組，檢查其他三個管芯，得知快取線被 CPU6和 CPU7 所在的管芯持有。
• 請求被轉發到 CPU6 和 CPU7 的互聯模組，檢查這兩個 CPU 的快取記憶體，在 CPU7 的快取記憶體中找到快取線。
• CPU7 將快取線傳送給所屬的互聯模組，並且重新整理自己快取記憶體中的快取線。
• CPU6 和 CPU7 的互聯模組將快取線傳送給系統互聯模組。
• 系統互聯模組將快取線傳送給 CPU0 和 CPU1 的互聯模組。
• CPU0 和 CPU1 的互聯模組將快取線傳送給 CPU0 的快取記憶體。
• CPU0 現在可以對快取記憶體中的變數執行 CAS 操作了

以上是重新整理不同CPU快取的開銷。最好情況下的 CAS 操作消耗大概 40 納秒，超過 60 個時鐘週期。這裡的“最好情況”是指對某一個變數執行 CAS 操作的 CPU 正好是最後一個操作該變數的CPU，所以對應的快取線已經在 CPU 的快取記憶體中了，類似地，最好情況下的鎖操作（一個“round trip 對”包括獲取鎖和隨後的釋放鎖）消耗超過 60 納秒，超過 100 個時鐘週期。這裡的“最好情況”意味著用於表示鎖的資料結構已經在獲取和釋放鎖的 CPU 所屬的快取記憶體中了。鎖操作比 CAS 操作更加耗時，是因深入理解並行程式設計 
為鎖操作的資料結構中需要兩個原子操作。快取未命中消耗大概 140 納秒，超過 200 個時鐘週期。需要在儲存新值時查詢變數的舊值的 CAS 操作，消耗大概 300 納秒，超過 500 個時鐘週期。想想這個，在執行一次 CAS 操作的時間裡，CPU 可以執行 500 條普通指令。這表明了細粒度鎖的侷限性。

以下是cache miss cas 和lock的效能對比：

JVM對CAS的支援：AtomicInt, AtomicLong.incrementAndGet()

在JDK1.5之前，如果不編寫明確的程式碼就無法執行CAS操作，在JDK1.5中引入了底層的支援，在int、long和物件的引用等型別上都公開了CAS的操作，並且JVM把它們編譯為底層硬體提供的最有效的方法，在執行CAS的平臺上，執行時把它們編譯為相應的機器指令，如果處理器/CPU不支援CAS指令，那麼JVM將使用自旋鎖。因此，值得注意的是，CAS解決方案與平臺/編譯器緊密相關（比如x86架構下其對應的彙編指令是lock cmpxchg，如果想要64Bit的交換，則應使用lock cmpxchg8b。在.NET中我們可以使用Interlocked.CompareExchange函式）。

在原子類變數中，如java.util.concurrent.atomic中的AtomicXXX，都使用了這些底層的JVM支援為數字型別的引用型別提供一種高效的CAS操作，而在java.util.concurrent中的大多數類在實現時都直接或間接的使用了這些原子變數類。

Java 1.6中AtomicLong.incrementAndGet()的實現原始碼為：

由此可見，AtomicLong.incrementAndGet的實現用了樂觀鎖技術，呼叫了sun.misc.Unsafe類庫裡面的 CAS演算法，用CPU指令來實現無鎖自增。所以，AtomicLong.incrementAndGet的自增比用synchronized的鎖效率倍增。

1 2 3 4 5 6 7 8 9 10 11 12

public final int