併發編程實戰(一)_ZenDei技術網路在線

併發編程的三個核心問題: 1. 分工 : 高效的拆解任務分給線程 2. 同步 : 線程之間的協作 3. 互斥 : 保證同一時刻只允許一個線程訪問共用資源這個其實不難理解,做個簡單的比喻,我們團隊做一個項目的時候肯定是先分配任務(分工),然後等到任務完成進行合併對接(同步),在開發過程中,使用版本控 ...

併發編程的三個核心問題:

分工 : 高效的拆解任務分給線程
同步 : 線程之間的協作
互斥 : 保證同一時刻只允許一個線程訪問共用資源

這個其實不難理解,做個簡單的比喻,我們團隊做一個項目的時候肯定是先分配任務(分工),然後等到任務完成進行合併對接(同步),在開發過程中,使用版本控制工具訪問,一個代碼只能被一個人修改,否則會報錯,需要meger(互斥).

學習攻略:

跳出來,看全景
鑽進去,看本質

核心: 分工(拆分) - 同步(一個線程執行完成如何通知後續任務的線程開始工作) - 互斥(同一時刻,只允許一個線程訪問共用變數)

全景:

本質 : 知其然知其所以然,有理論做基礎.技術的本質是背後的理論模型

併發編程為啥好難?

我從我的角度看,一個是併發編程的API不是很瞭解,第二個就是出現了問題不會解決,如果說還有,那就是是在不知道併發編程是用來幹啥的?有什麼用?

每一中技術的出現都有他出現的必然性,對於併發來說無疑是提高性能,那單線程為啥就不能提高性能,原因就在於CPU,記憶體和IO設備三者的速度差異太大,舉個例子來說: CPU一天,記憶體一年,IO一百年; 而木桶理論告訴我們程式的性能是由短板決定,所以只要合理的平衡三者的速度差異,就可以提高性能.

併發編程問題的源頭

緩存導致的可見性: 對於單CPU來說,緩存是可見的,也就是說多個線程同時操作,CPU會從記憶體讀取數據,線程更新數據到CPU,CPU寫入記憶體,線程和CPU進行交互,這個操作每個線程之間是可見的.
但是對於多CPU來說,多個線程操作不同的CPU,不同的CPU操作同一個記憶體,這會導致操作的不可見性,就出現了問題.(說下可見性的概念: 一個線程對共用變數的修改,另一個線程能夠立刻看到,這就是可見性)
線程切換帶來的原子性問題: 原子性是一個或多個操作在CPU執行的過程中不被中斷的特性. 那為什麼會中斷呢?原因就在於提高性能,就和現在的電腦一樣,是分時間片來進行任務切換,同時聽歌和敲代碼,看似是同時發生,其實不是,知識任務之間切換的非常快,做到了看似同時進行.
在高級程式中,一個看似簡單的操作可能需要多條CPU指令來完成,不如說count += 1;CPU指令至少三個,從記憶體中拿到count值到寄存器,在寄存器中進行加一操作,將結果寫入記憶體,這個過程中可能會發生任務間的切換,比如說另一個線程在寫入記憶體前有進行了一次++操作,這個時候結果就不是想要的結果了,可能例子不合適,但是這個意思就是這個. 而原子性就是保證高級語言層面保證操作的原子性.
編譯優化的有序性問題: 有序性指的是程式按照代碼的先後順序執行. 看起來沒問題,本來就應該這樣,其實不然,在JVM的知識中有一個叫重排序,就是編譯器為了優化性能,有時會改變程式中語句的先後順序,大部分情況下編譯器調整後的順序是不會影響程式的最終結果,不過也有特殊情況,如下:

public class Singleton {
  static Singleton instance;
  static Singleton getInstance(){
    if (instance == null) {
      synchronized(Singleton.class) {
        if (instance == null)
          instance = new Singleton();
        }
    }
    return instance;
  }
}

上面是經典的雙重檢查創建單例對象,在我們的印象中new的操作應該是: 分配記憶體,在記憶體上初始化對象,地址賦值. 實際上優化後是: 分配記憶體,地址賦值,初始化. 優化後的順序就會出現問題,地址賦值後發生了線程切換,這時候其他線程讀取到了對象不為null,但是實際上只有地址,這個時候訪問成員變數就會出現空指針異常,這個就是編譯優化可能會出現的問題.

也就是說,很多的併發Bug是由可見性,原子性,有序性的原理造成的,從這三個方面去考慮,可以理解診斷很大部分一部分Bug. 緩存導致可見性問題,線程切換帶來的原子性,編譯優化帶來的有序性,本質都是提高程式性能,但是在帶來性能的時候可能也會出現其他問題,所以在運用一項技術的時候一定要清楚它帶來的問題是什麼,以及如何實現.

Java記憶體模型: 解決可見性和有序性問題

可見性的原因是緩存,有序性的原因是編譯優化,那解決的最直接的辦法就是禁用緩存和編譯優化,但是有緩存和編譯優化的目的是提高程式性能,禁用了程式的性能如何保證? 合理的方案是按需禁用緩存和編譯優化,Java記憶體模型規範了JVM如何提供按需禁用緩存和編譯優化的方法,具體的,這些方法包括volatile,synchronized和final三個關鍵字,以及六項Happens-Before規則

volatile的困惑

volatile關鍵字用來聲明變數,告訴編譯器這個變數的讀寫不能使用CPU緩存,必須從記憶體中讀寫.

// 以下代碼來源於【參考 1】
class VolatileExample {
  int x = 0;
  volatile boolean v = false;
  public void writer() {
    x = 42;
    v = true;
  }
  public void reader() {
    if (v == true) {
      // 這裡 x 會是多少呢？
    }
  }
}

上面的代碼x的值是多少呢?直覺上應該是42,但是在jdk1.5之前,可能的值是0或者42,1.5之後就是42,為什麼?原因是變數x可能被CPU緩存而導致可見性問題,也就是x=42可能不被v=true可見,那Java的記憶體模型在1.5版本之後是如何解決的呢? 就是Happens-before規則.

Happens-Before規則

Happens-before指的是前一個操作的結果對後續操作是可見的,具體如下.

1. 程式的順序性規則

這個規則說的是在一個線程中,按照程式順序,前面的操作Happens-Before於後續的任意操作. 簡單理解就是: 程式前面對於某個變數的修改一定是對後續操作可見的.也就是前面的代碼x=42對於v=true是可見的.

2. volatile變數規則

這條規則指的是對一個volatile變數的寫操作,Happens-Before於後續對這個volatile變數的讀操作,即volatile變數的寫操作對於讀操作是可見的.

3. 傳遞性

這條規則指的是A Happens-Before C,且B Happens-Before C,那麼A Happens-Before C,如下圖:
傳遞性

這樣就很明顯了,x=42 Happens-Before v=true,寫v=true Happens-Before 讀v=true,那也就是說x=42 Happens Before 讀v=true,這樣下來,其他線程就可以看到x=42這個操作了.

4. 管程中鎖的規則

這個規則是指對一個鎖的解鎖Happens-Before與後續對這個鎖的加鎖. 管程是一種通用的同步原語,在Java中指的就是synchronized,synchronized是Java里對管程的實現.管程中的鎖在Java中是隱式實現的,也就是進入同步塊之前,會自動加鎖,而在代碼塊執行完後自動釋放鎖,加鎖以及解鎖都是編譯器幫我們實現的.

synchronized (this) { // 此處自動加鎖
  // x 是共用變數, 初始值 =10
  if (this.x < 12) {
    this.x = 12; 
  }  
} // 此處自動解鎖

5. 線程start()規則

這個是線程啟動的,指的是主線程A啟動子線程B,子線程B能夠看到主線程在啟動子線程B前的操作.

Thread B = new Thread(()->{
  // 主線程調用 B.start() 之前
  // 所有對共用變數的修改，此處皆可見
  // 此例中，var==77
});
// 此處對共用變數 var 修改
var = 77;
// 主線程啟動子線程
B.start();

6. 線程join()規則

這條規則是關於線程等待的.它是指主席愛能成A通過調用子線程B的join方法,子線程B執行完成之後,主線程可以看到子線程中的操作.這裡指的是對共用變數的操作.

Thread B = new Thread(()->{
  // 此處對共用變數 var 修改
  var = 66;
});
// 例如此處對共用變數修改，
// 則這個修改結果對線程 B 可見
// 主線程啟動子線程
B.start();
B.join()
// 子線程所有對共用變數的修改
// 在主線程調用 B.join() 之後皆可見
// 此例中，var==66

Final

final修飾變數是告訴編譯器: 這個變數生而不變,可以可勁兒優化.在 1.5 以後 Java 記憶體模型對 final 類型變數的重排進行了約束。現在只要我們提供正確構造函數沒有“逸出”，就不會出問題了。下麵的例子,在構造函數里將this賦值給全局變數global.obj,這就是逸出(逸出就是對象還沒有構造完成,就被髮布出去),線程global.obj讀取到x有可能讀到0.

// 以下代碼來源於【參考 1】
final int x;
// 錯誤的構造函數
public FinalFieldExample() { 
  x = 3;
  y = 4;
  // 此處就是講 this 逸出，
  global.obj = this;
}

在 Java 語言裡面，Happens-Before 的語義本質上是一種可見性，A Happens-Before B 意味著 A 事件對 B 事件來說是可見的，無論 A 事件和 B 事件是否發生在同一個線程里。例如 A 事件發生線上程 1 上，B 事件發生線上程 2 上，Happens-Before 規則保證線程 2 上也能看到 A 事件的發生。

互斥鎖: 解決原子性問題

前面看了Java的記憶體模型,解決了可見性和編譯優化的重排序問題,哪還有一個原子性如何解決?答案就是使用互斥鎖實現.

先探究源頭,long在32位機器上操作可能出現Bug,原因是線程的切換,那隻要保證同一時刻只有一個線程執行,就可以了,這就是互斥.

互斥鎖模型:

Java中如何實現這種互斥鎖呢?

Java語言提供的鎖技術: synchronized

java中的synchronized關鍵字就是鎖的一種實現,synchronized關鍵字可以用來修飾方法,也可以用來修飾代碼塊,如下:

class X {
  // 修飾非靜態方法
  synchronized void foo() {
    // 臨界區
  }
  // 修飾靜態方法
  synchronized static void bar() {
    // 臨界區
  }
  // 修飾代碼塊
  Object obj = new Object()；
  void baz() {
    synchronized(obj) {
      // 臨界區
    }
  }
}

先說一下那個加鎖和釋放鎖,synchronized並沒有顯示的進行這一操作,而是編譯器會在synchronized修飾的方法或代碼塊前後自動加鎖lock()和解鎖unlock(),不需要編程人員手動加鎖和釋放鎖(省的忘記,程式員很忙的).

synchronized鎖的規則是什麼: 當修飾靜態方法的時候,鎖定的是當前的類對象. 修飾非靜態方法和代碼塊的時候,鎖定的是當前的對象this.如下

class X {
  // 修飾靜態方法
  synchronized(X.class) static void bar() {
    // 臨界區
  }
}

class X {
  // 修飾非靜態方法
  synchronized(this) void foo() {
    // 臨界區
  }
}

案例深入理解:

下麵的代碼可以解決多線程問題嗎?

class SafeCalc {
  long value = 0L;
  long get() {
    return value;
  }
  synchronized void addOne() {
    value += 1;
  }
}

答案是並不可以,原因是雖然對addOne進行了加鎖操作(對一個鎖的解鎖Happens-Before於後續對這個鎖的加鎖),保證了後續addOne的操作的共用變數是可以看到前面addOne操作後的共用變數的值,但是get方法卻沒有,多個線程get方法可能獲取到的值相同,addOne()之後就會亂套,所以並不能解決.那下麵的代碼可以解決問題嗎?

class SafeCalc {
  long value = 0L;
  synchronized long get() {
    return value;
  }
  synchronized void addOne() {
    value += 1;
  }
}

這種是可以解決多線程問題,也就是可以解決多個線程操作同一個對象的併發問題.那如果要解決多個線程操作不同對象的併發問題呢?

鎖和受保護資源的關係

受保護資源和鎖之間的關聯關係是N:1的關係.也就是說一個鎖可以保護多個受保護的資源,這個就是現實生活中的包場,但是我覺得這個也要分情況,多個受保護的資源和鎖之間一定要有關係,不然鎖不起作用就麻煩了,舉個例子來說就是自己家門的鎖肯定保護自己東西,不能用自己家門的鎖去保護別人家的東西.

下麵的例子:

class SafeCalc {
  static long value = 0L;
  synchronized long get() {
    return value;
  }
  synchronized static void addOne() {
    value += 1;
  }
}

分析如圖:
static lock

所以說addOne對value的修改對臨界區get()沒有可見性保證,會導致併發問題.將get方法也改為靜態的就可以解決了.

synchronized 是 Java 在語言層面提供的互斥原語，其實 Java 裡面還有很多其他類型的鎖，但作為互斥鎖，原理都是相通的：鎖，一定有一個要鎖定的對象，至於這個鎖定的對象要保護的資源以及在哪裡加鎖 / 解鎖，就屬於設計層面的事情了。

互斥鎖: 如何用一把鎖保護多個資源

受保護的資源和鎖之間合理的關聯關係應該是N:1的關係.使用一把鎖保護多個資源也是分情況的,在於多個資源之間存不存在關係,這是要分情況討論的.

保護沒有關聯關係的多個資源

舉個例子來說明,Account類有兩個成員變數,分別是賬戶餘額balance和賬戶密碼password. 取款和查看餘額會訪問balance,創建一個final對象balLock來作為balance的鎖;更改密碼和查看密碼會操作password,創建一個final對象pwLock來作為password的鎖.不同的資源用不同的鎖保護.代碼示例如下:

class Account {
  // 鎖：保護賬戶餘額
  private final Object balLock
    = new Object();
  // 賬戶餘額  
  private Integer balance;
  // 鎖：保護賬戶密碼
  private final Object pwLock
    = new Object();
  // 賬戶密碼
  private String password;

  // 取款
  void withdraw(Integer amt) {
    synchronized(balLock) {
      if (this.balance > amt){
        this.balance -= amt;
      }
    }
  } 
  // 查看餘額
  Integer getBalance() {
    synchronized(balLock) {
      return balance;
    }
  }

  // 更改密碼
  void updatePassword(String pw){
    synchronized(pwLock) {
      this.password = pw;
    }
  } 
  // 查看密碼
  String getPassword() {
    synchronized(pwLock) {
      return password;
    }
  }
}

那還有沒有其他的解決方案? 可以使用this來進行加鎖,但是這種情況性能會很差,因為password和balance使用同一把鎖,操作也就串列了,使用兩把鎖,password和balance的操作是可以並行的,用不同的鎖對受保護資源進行精細化關係,能夠提升性能.這個叫細粒度鎖

保護有關聯關係的多個資源

如果多個資源之間有關聯關係,那就比較複雜,經典的轉賬問題.看下麵代碼可能發生併發問題嗎?

class Account {
  private int balance;
  // 轉賬
  synchronized void transfer(
      Account target, int amt){
    if (this.balance > amt) {
      this.balance -= amt;
      target.balance += amt;
    }
  } 
}

開起來沒問題,其實不然,只對當前對象進行了加鎖,那目標對象的訪問呢?也就是說當前的對象是無法保護target.balance的.
unsafe

上面的案例兩個人之間的轉賬或許沒有問題,但是涉及三個人呢?
example

這個時候B的餘額可能為100,也可能為300,看哪個執行在後了.那應該如何解決這種有關聯的資源呢,找公共的鎖就可以,也就是要鎖能覆蓋所有受保護資源,解決方案其實不少,如下

class Account {
  private Object lock；
  private int balance;
  private Account();
  // 創建 Account 時傳入同一個 lock 對象
  public Account(Object lock) {
    this.lock = lock;
  } 
  // 轉賬
  void transfer(Account target, int amt){
    // 此處檢查所有對象共用的鎖
    synchronized(lock) {
      if (this.balance > amt) {
        this.balance -= amt;
        target.balance += amt;
      }
    }
  }
}

這個解決方案缺點在於需要傳入共用的lock,還有一種方案

class Account {
  private int balance;
  // 轉賬
  void transfer(Account target, int amt){
    synchronized(Account.class) {
      if (this.balance > amt) {
        this.balance -= amt;
        target.balance += amt;
      }
    }
  } 
}

這個是不是很簡單.
safe

上圖展示瞭如何使用共用的鎖來保護不同對象的臨界區.

解決原子性問題,是要保證中間狀態對外不可見.