如果CAS嘗試競爭成功，就直接執行代碼塊。如果失敗，發現有其他線程在競爭撤銷偏向鎖，升級成為輕量級鎖。

2.升級為輕量級鎖線程嘗試使用CAS將對象頭中的Mark Word替換為指向鎖記錄的指針。如果成功,當前線程獲得鎖,如果失敗,表示其他線程競爭鎖,當前線程便嘗試使用自旋來獲取鎖。

自旋鎖儘可能的減少線程的阻塞，這對於鎖的競爭不激烈，且佔用鎖時間非常短的代碼塊來說性能能大幅度的提升，因為自旋的消耗會小於線程阻塞掛起再喚醒的操作的消耗。

3.輕量級鎖自旋獲取鎖依然失敗，升級為重量級鎖。

四、性能優化與測試

在並發編程中線程安全是我們首要要關注的問題，它是保證程序穩定運行的前提。但是鎖的引入可能也是性能上的殺手。

4.1 多線程性能問題誘因

導致並發性能的主要誘因是"上下文切換"。

上線文切換

在多核的操作系統裏，當一個線程被切換進來時，它所需要的數據可能不在當前處理器的緩存裏，緩存的確實會使得這個線程初次的切換帶來更多的開銷。通常一次上下文的開銷相當於5000~10000個cp4時鐘週期。

引發上下切換的誘因是:阻塞IO,等待獲取競爭鎖等。

當線程發生阻塞或者等待獲取競爭鎖（cas,voliate都屬於非競爭同步，JVM自行調度，無需操作系統介入)時，需要被掛起，這個過程將包含兩次額外的上下文切換，被阻塞的線程在其執行的時間片還沒有用完之前就被交換出去，而在隨後的獲取鎖或者資源可用的時候再切換回來。

調用哪些方法會引起上線文切換（常見）：

• Thread.sleep(long millis)
• Object,wait(long timeout)
• Thread.join()/Thread.join(long timeout)

性能的影響因素也包含如內存同步等，這裡只說上下文切換是主要誘因，可能人為的做優化的部分。

4.2 性能優化方案

4.2.1 減少鎖力粒度

如果我們給public類每個方法加synchnorized(this)的同步，線程安全確實沒問題。但是基本也等同於串列操作，違背了並發的本意。

在編碼的時候盡量避免鎖的力度太粗。避免佔用鎖的時間過長。

case：

public class Grocery {
private final ArrayList fruits = new ArrayList();
private final ArrayList vegetables = new ArrayList();
public synchronized void addFruit(int index, String fruit) {
fruits.add(index, fruit);
}
public synchronized void removeFruit(int index) {
fruits.remove(index);
}
public synchronized void addVegetable(int index, String vegetable) {
vegetables.add(index, vegetable);
}
public synchronized void removeVegetable(int index) {
vegetables.remove(index);
}
}

這裡可以看出來在添加和移除水果的時候也會阻塞蔬菜的添加和刪除，對於水果和蔬菜的增刪操作都是方法域的同步。如果拆分下鎖：

public class Grocery {
private final ArrayList fruits = new ArrayList();
private final ArrayList vegetables = new ArrayList();
public void addFruit(int index, String fruit) {
synchronized(fruits) fruits.add(index, fruit);
}
public void removeFruit(int index) {
synchronized(fruits) {fruits.remove(index);}
}
public void addVegetable(int index, String vegetable) {
synchronized(vegetables) vegetables.add(index, vegetable);
}
public void removeVegetable(int index) {
synchronized(vegetables) vegetables.remove(index);
}
}

鎖的範圍就被縮小到了針對每個資源fruits和vegetables的鎖。通常這樣的方式阻塞出現的情況會更加少，性能會有較大的提升。

4.2.2 使用非競爭同步

在cas和voliate關鍵字適用的場景可以盡量去選擇使用此類樂觀鎖。

4.2.3 分段鎖

分解鎖可以帶來一定的伸縮性和性能的提升，但是如果競爭條件還是比較激烈的話，還是會有問題，這時候可以通過分段鎖來優化。jdk 1.7中的線程安全集合類ConcurrentHashMap就是利用了這個技術來實現高並發。

ConcurrentHashMap把容器分為多個 segment（片段） ，每個片段有一把鎖，當多線程訪問容器裏不同數據段的數據時，線程間就不會存在競爭關係；一個線程佔用鎖訪問一個segment的數據時，並不影響另外的線程訪問其他segment中的數據。

@SuppressWarnings("unchecked")
public V put(K key, V value) {
Segment<K,V> s;
if (value == null)
throw new NullPointerException();
int hash = hash(key.hashCode()); //獲取hash值
int j = (hash >>> segmentShift) & segmentMask; //mask計算出資源散列在哪個片段中
if ((s = (Segment<K,V>)UNSAFE.getObject // nonvolatile; recheck
(segments, (j << SSHIFT) + SBASE)) == null) // in ensureSegment
s = ensureSegment(j);
return s.put(key, hash, value, false);
}

ensureSegment找到segment位置之後，就可以開始執行Segment put操作，Segment.put被使用開銷更小的ReentrantLock.trylock即非公平鎖。

非公平鎖（Nonfair）：加鎖時不考慮排隊等待問題，直接嘗試獲取鎖，獲取不到自動到隊尾等待。

4.2.4 ReadWriteLock

如果資源可以被多個讀線程訪問，或者只有一個寫線程訪問，可以使用讀寫鎖。也就是存在多個線程同時存在讀和寫的場景不適用。

資源並發讀寫：

紅色部分表示被阻塞的線程

使用讀寫鎖可以帶來性能上的優化。Java 中的實現有ReentrantReadWriteLock。

實例讀鎖和寫鎖

private final ReentrantReadWriteLock rwl = new ReentrantReadWriteLock();
private final Lock r = rwl.readLock();
private final Lock w = rwl.writeLock();

獲取鎖和釋放鎖

lock()
unlock()

讀鎖的性能高於獨佔鎖，讀鎖區別於寫鎖使用的是共享鎖，具有更小的開銷

4.3 編寫測試代碼

多線程的正確性通常很難通過肉眼甚至是正常測試回歸發現。對於我們的並發代碼的正確性需要更多的依賴測試代碼的驗證，這一點很重要。

但是編寫多線程的單元測試通常比寫多線程的邏輯代碼更難，需要一些技巧。

4.3.1 覆蓋基本的後驗條件

首先假定在串列的條件下，是否能正確的都到正確的結果。使用單元測試先去覆蓋掉。比如隊列在創建之前應該為空的嚴重，完成之後後驗結果的準確性。確保非並發的環境下程序是爭取的，這樣可以避免把所有錯誤懷疑到多線程上，也可以為多線程的後續結果驗證提供基礎。

4.3.2 使用柵欄模式(CyclicBarrier)設計"同時到達"

CyclicBarrier可以使線程互相等待，任何一個線程達到某個狀態之前，所有的線程都必須等待。等到所有線程都達到某個狀態，線程才能繼續執行。

CyclicBarrier的代碼模型：

//設計50個測試線程
int HREADS = 50 ;

CyclicBarrier barries = new CyclicBarrier(HREADS);

//in thread,wait to start
barries.await()

//do stuff

//in thread,wait to stop
barries.await();

case:

class Party extends Thread {
private int duration;
private CyclicBarrier barrier;

public Party(int duration, CyclicBarrier barrier, String name) {
super(name);
this.duration = duration;
this.barrier = barrier;
}

@Override
public void run() {
try {
Thread.sleep(duration);
System.out.println(Thread.currentThread().getName() + " is calling await()");
barrier.await();
System.out.println(Thread.currentThread().getName() + " has started running again");
} catch (InterruptedException | BrokenBarrierException e) {
e.printStackTrace();
}
}
}

Test:

public static void main(String args[]) throws InterruptedException, BrokenBarrierException {

CyclicBarrier barrier = new CyclicBarrier(4);
Party first = new Party(1000, barrier, "PARTY-1");
Party second = new Party(2000, barrier, "PARTY-2");
Party third = new Party(3000, barrier, "PARTY-3");
Party fourth = new Party(4000, barrier, "PARTY-4");

first.start();
second.start();
third.start();
fourth.start();

System.out.println(Thread.currentThread().getName() + " has finished");

}

4.3.3 產生更多的交替操作

低概率的事件即使是模擬多線程測試也很難驗證出來，需要讓程序產生更多的交替操作大概率去提高並發隱藏問題出現的概率。

藉助Thread.sleep()/Thread.yield()，通常加到需要驗證的邏輯之前。

public void run() {
try {
Thread.sleep(2);

//do stuff
} catch (InterruptedException | BrokenBarrierException e) {
e.printStackTrace();
}
}

Thread.sleep()/Thread.yield()都會阻塞使CPU讓出時間片,讓競爭更為激烈。

推薦閱讀：