併發編程實戰(一)

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

1. 分工 : 高效的拆解任務分給線程
2. 同步 : 線程之間的協做
3. 互斥 : 保證同一時刻只容許一個線程訪問共享資源

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

學習攻略:

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

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

全景:

本質 : 知其然知其因此然,有理論作基礎.技術的本質是背後的理論模型

併發編程爲啥好難?

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

每一中技術的出現都有他出現的必然性,對於併發來講無疑是提升性能,那單線程爲啥就不能提升性能,緣由就在於CPU,內存和IO設備三者的速度差別太大,舉個例子來講: CPU一天,內存一年,IO一百年; 而木桶理論告訴咱們程序的性能是由短板決定,因此只要合理的平衡三者的速度差別,就能夠提升性能.

併發編程問題的源頭

1. 緩存致使的可見性: 對於單CPU來講,緩存是可見的,也就是說多個線程同時操做,CPU會從內存讀取數據,線程更新數據到CPU,CPU寫入內存,線程和CPU進行交互,這個操做每一個線程之間是可見的.<br> 可是對於多CPU來講,多個線程操做不一樣的CPU,不一樣的CPU操做同一個內存,這會致使操做的不可見性,就出現了問題.(說下可見性的概念: 一個線程對共享變量的修改,另外一個線程可以馬上看到,這就是可見性)
2. 線程切換帶來的原子性問題: 原子性是一個或多個操做在CPU執行的過程當中不被中斷的特性. 那爲何會中斷呢?緣由就在於提升性能,就和如今的計算機同樣,是分時間片來進行任務切換,同時聽歌和敲代碼,看似是同時發生,其實不是,知識任務之間切換的很是快,作到了看似同時進行. <br> 在高級程序中,一個看似簡單的操做可能須要多條CPU指令來完成,不如說count += 1;CPU指令至少三個,從內存中拿到count值到寄存器,在寄存器中進行加一操做,將結果寫入內存,這個過程當中可能會發生任務間的切換,好比說另外一個線程在寫入內存前有進行了一次++操做,這個時候結果就不是想要的結果了,可能例子不合適,可是這個意思就是這個. 而原子性就是保證高級語言層面保證操做的原子性.
3. 編譯優化的有序性問題: 有序性指的是程序按照代碼的前後順序執行. 看起來沒問題,原本就應該這樣,其實否則,在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;
  }
}

分析如圖:

因此說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的.

上面的案例兩我的之間的轉帳或許沒有問題,可是涉及三我的呢?

這個時候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;
      }
    }
  } 
}

這個是否是很簡單.

上圖展現瞭如何使用共享的鎖來保護不一樣對象的臨界區.

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