并發編程-初級之認識并發編程

1.并發領域可以處理的問題

1. 分工；
2. 同步：分好工之后，就可以具體執行，任務之間是有依賴的，一個任務結束之后將去去通知后續的任務，java里面 Executor、Fork/Join、Future本質上都
   是分工方法，但同時也能解決執行緒協作的問題，

例如，用 Future 可以發起一個異步呼叫，主執行緒通過 get() 方法取結果時，主執行緒就會等待，當異步執行的結果回傳時，get() 方法就自動回傳了，
我之前用的是CountDownLatch，先創建多個執行緒實作分工，再用CountDownLatch來一起協

3. 互斥：這里要說的就是執行緒安全的問題，導致這種多個執行緒訪問一個變數的時候的不確定性的源頭是由于可見性問題，有序性問題，原子性問題，
   而當我們講到互斥其實我們是在說***同一時刻，只允許一個執行緒訪問共享 變數***，
   而實作互斥的核心就是鎖，
   

2.可見性，原子性和有序性問題：并發編程bug源頭

1.什么是可見性

一個執行緒對共享變數的修改另一個執行緒能立刻看到，我們稱為可見性，

1.1 快取問題導致的可見性問題
1.2 執行緒切換帶來的原子性問題

1.3 編譯優化帶來的有序性問題

3.Java記憶體模型：java如何解決可見性和有序性問題

解決這種問題合理方案：按需禁用快取，編譯優化

1.按需禁用快取

1.1 volatile關鍵字

volatile 關鍵字并不是 Java 語言的特產，古老的 C 語言里也有，它最原始的意義就是禁用
CPU 快取，

在java 1.5后 對volite使用Happens-Before增強，

Happens-Before規則（java-可見性）

大意：前一個操作的結果對后續的操作是可見的，
Happens-Before 約束了
編譯器的優化行為，雖允許編譯器優化，但是要求編譯器優化后一定遵守 HappensBefore 規則

一共有六項

1.程式的順序性規則

1 // 以下代碼來源于【參考 1】 2 class VolatileExample {
3 int x = 0;
4 volatile boolean v = false;
5 public void writer() {
6 x = 42;
7 v = true;
8 }
9 public void reader() {
10 if (v == true) {
11 // 這里 x 會是多少呢？
    42// 1.5之前這里x=0
12 }
13 }
14 }

2.volatile規則

3.傳遞性：這條規則是指如果 A Happens-Before B，且 B Happens-Before C，那么 A HappensBefore C，

從圖中，我們可以看到：

1. “x=42” Happens-Before 寫變數 “v=true” ，這是規則 1 的內容；

2. 寫變數“v=true” Happens-Before 讀變數 “v=true”，這是規則 2 的內容 ，
再根據這個傳遞性規則，我們得到結果：“x=42” Happens-Before 讀變
量“v=true”，這意味著什么呢？
如果執行緒 B 讀到了“v=true”，那么執行緒 A 設定的“x=42”對執行緒 B 是可見的，也就是
說，執行緒 B 能看到 “x == 42” ，有沒有一種恍然大悟的感覺？這就是 1.5 版本對
volatile 語意的增強，這個增強意義重大，1.5 版本的并發工具包（java.util.concurrent）

ps:這個規則也解釋了為什么之前我們看到的x是等于42而不是等于0
4.管程中鎖的規則

管程：
一種通用的同步原語，在
Java 中指的就是 synchronized，synchronized 是 Java 里對管程的實作，

1 synchronized (this) { // 此處自動加鎖
2 // x 是共享變數, 初始值 =10
3 if (this.x < 12) {
4 this.x = 12; 
5 } 
6 } // 此處自動解鎖

所以結合規則 4——管程中鎖的規則，可以這樣理解：假設 x 的初始值是 10，執行緒 A 執行
完代碼塊后 x 的值會變成 12（執行完自動釋放鎖），執行緒 B 進入代碼塊時，能夠看到執行緒
A 對 x 的寫操作，也就是執行緒 B 能夠看到 x==12，這個也是符合我們直覺的，應該不難理
解，

5.執行緒start()規則

這條是關于執行緒啟動的，它是指主執行緒 A 啟動子執行緒 B 后，子執行緒 B 能夠看到主執行緒在啟
動子執行緒 B 前的操作，

1 Thread B = new Thread(()->{
2 // 主執行緒呼叫 B.start() 之前
3 // 所有對共享變數的修改，此處皆可見
4 // 此例中，var==77
5 });
6 // 此處對共享變數 var 修改
7 var = 77;
8 // 主執行緒啟動子執行緒
9 B.start();

6.執行緒join原則

這條是關于執行緒等待的，它是指主執行緒 A 等待子執行緒 B 完成（主執行緒 A 通過呼叫子執行緒 B
的 join() 方法實作），當子執行緒 B 完成后（主執行緒 A 中 join() 方法回傳），主執行緒能夠看
到子執行緒的操作，當然所謂的“看到”，指的是對共享變數的操作，
換句話說就是，如果在執行緒 A 中，呼叫執行緒 B 的 join() 并成功回傳，那么執行緒 B 中的任意
操作 Happens-Before 于該 join() 操作的回傳，具體可參考下面示例代碼，

1 Thread B = new Thread(()->{
2 // 此處對共享變數 var 修改
3 var = 66;
4 });
5 // 例如此處對共享變數修改，
6 // 則這個修改結果對執行緒 B 可見
7 // 主執行緒啟動子執行緒
8 B.start();
9 B.join()
10 // 子執行緒所有對共享變數的修改
11 // 在主執行緒呼叫 B.join() 之后皆可見
12 // 此例中，var==66

所以以前我們的單例模式,其實會導致空指標例外 因為New物件是三步 - 1.開記憶體 2.堆上初始化一個物件 3.在吧地址給那個堆疊 但是java會進行優化 2，3步會交換 所以 很多執行緒訪問的時候 可能會拿到instance!= null 然后他們就拿著這個物件走了 但其實這個物件是沒有記憶體的 會出現空指標例外

public class DoubleCheckLock {
    private static Instance instance;
    public static Instance getInstance(){
        // 第一次檢查
        if(instance==null){
            // 第一次檢查為null再進行加鎖，降低同步帶來的性能開銷
            synchronized (DoubleCheckLock.class){
                // 第二次檢查
                if(instance==null){
                    // 問題出在此處
                    instance=new Instance();
                }
            }
        }
        return instance;
    }
}

所以解決方案就是 Instance 加上volatile關鍵字 防止java的優化

final 修飾變數時，初衷是告訴編譯器：這個變數生而不變，可以可勁兒優化，

4.互斥鎖

解決原子性問題

本質：互斥鎖本質上是將并行的程式串行化，所以要增加并行度，一定減少持有鎖的時間

最原始粗暴的鎖模型

在上面的鎖在我們看來是非常簡單粗暴的，在現實世界里，鎖和要保護的資源是有對應關系的，比如我家的鎖鎖我家的門，
所以引進了下面一種模型

首先，我們要把臨界區要保護的資源標注出來，如圖中臨界區里增加了一個元素：受保護的
資源 R；其次，我們要保護資源 R 就得為它創建一把鎖 LR；最后，針對這把鎖 LR，我們
還需在進出臨界區時添上加鎖操作和解鎖操作，另外，在鎖 LR 和受保護資源之間，我特地
用一條線做了關聯，這個關聯關系非常重要，很多并發 Bug 的出現都是因為把它忽略了，
然后就出現了類似鎖自家門來保護他家資產的事情，這樣的 Bug 非常不好診斷，因為潛意
識里我們認為已經正確加鎖了，

圖畫出來了，但是這個圖在java里面是怎樣實作呢？
我們接著往下面看，

1.synchronized ：可以用來修飾方法和代碼塊

1  class X {
2 // 修飾非靜態方法
3 synchronized void foo() {
4 // 臨界區
5 }
6 // 修飾靜態方法
7 synchronized static void bar() {
8 // 臨界區
9 }
10 // 修飾代碼塊
11 Object obj = new Object()；
12 void baz() {
13 synchronized(obj) {
14 // 臨界區
15 }
16 }
17 }

用synchronized可以自動lock()和unLock(),而在修飾代碼塊的時候，鎖定了一個Obj，那他修飾方法呢？

當修飾靜態方法的時候，鎖定的是當前類的 Class 物件，在上面的例子中就
是 Class X；
當修飾非靜態方法的時候，鎖定的是當前實體物件 this，

鎖和受保護資源的關系

資源->鎖 多->一

ps:當多個鎖鎖住同一個資源（方法或者是什么）那么就會執行緒不安全

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

1.保護沒有關聯關系的多個資源 -上不同的鎖
2.保護有關聯關系的多個資源

評估性能的指標：
1.吞吐量
2.延遲
3.并發量:

評估性能的指標

5.管程

1.什么是管程：
管程，對應的英文是 Monitor，很多 Java 領域的同學都喜歡將其翻譯成“監視器”，這是
直譯，作業系統領域一般都翻譯成“管程”，這個是意譯，而我自己也更傾向于使用“管
程”，
是Java并發使用的技術，而其體現在synchronized 關
鍵字及 wait()、notify()、notifyAll()，

2.作用: 指的是管理共享變數以及對共享變數的操作程序，讓他們支持并發

3.廣泛使用的管程模型:MESA

3.1 互斥：
管程解決互斥問題的思路很簡單，就是將共享變數及其對共享變數的操作統一封裝起來，在
下圖中，管程 X 將共享變數 queue 這個佇列和相關的操作入隊 enq()、出隊 deq() 都封裝
起來了；執行緒 A 和執行緒 B 如果想訪問共享變數 queue，只能通過呼叫管程提供的 enq()、
deq() 方法來實作；enq()、deq() 保證互斥性，只允許一個執行緒進入管程，
在管程模型里，對于共享變數的操作是被封裝的，圖中最外層的框就代表封裝，框的上面只有一個入口，并且在入口旁邊有一個等待佇列，當多個執行緒同時進入時，只允許一個執行緒進入，其他則在隊伍中等待，

條件變數
每個條件變數對應一個條件變數等待佇列，比如說有一個條件變數 A，當執行執行緒 T1 時發現不滿足條件變數 A，T1 就會進入條件變數 A 的等待佇列中，就像去看醫生，醫生讓你先去排個 X 光，就要去拍 X 光的地方排隊，

public class BlockedQueue<T>{
  final Lock lock =
    new ReentrantLock();
  // 條件變數：佇列不滿  
  final Condition notFull =
    lock.newCondition();
  // 條件變數：佇列不空  
  final Condition notEmpty =
    lock.newCondition();

  // 入隊
  void enq(T x) {
    lock.lock();
    try {
      while (佇列已滿){
        // 等待佇列不滿 
        notFull.await();
      }  
      // 省略入隊操作...
      //入隊后,通知可出隊
      notEmpty.signal();
    }finally {
      lock.unlock();
    }
  }
  // 出隊
  void deq(){
    lock.lock();
    try {
      while (佇列已空){
        // 等待佇列不空
        notEmpty.await();
      }
      // 省略出隊操作...
      //出隊后，通知可入隊
      notFull.signal();
    }finally {
      lock.unlock();
    }  
  }
}

3.2 synchronized 單條件變數的管程模型
Java內置的管程方案（synchronized）只支持一個條件變數
而如果要支持多個 可以參考Java 的Sdk

6.執行緒的生命周期

1. NEW（初始化狀態）
2. RUNNABLE（可運行 / 運行狀態）
3. BLOCKED（阻塞狀態）
4. WAITING（無時限等待）
5. TIMED_WAITING（有時限等待）
6. TERMINATED（終止狀態）

只要執行緒處于BLOCKED、WAITING、TIMED_WAITING那么這個執行緒就永遠沒有 CPU 的使用權，這個時候被如果被Interrute()就會報例外

如何從New切換到 WAITING
呼叫start()

如何從Runnable切換到 WAITING

1. Object.wait()
2. Thread.join()
3. LockSupport.park()

如何從Runnable切換到 TIMED_WAITING

1.呼叫帶超時引數的 Thread.sleep(long millis) 方法；
2.帶超時引數的 Object.wait(long timeout)
3.帶超時引數的 Thread.join(long millis
…

如何從Runnable切換到 WAITING
1.程式執行完
2.stop() 超級不建議使用
3.interrupt() 正確使用

TIMED_WAITING 和 WAITING 狀態的區別，僅僅是觸發條件多了超時引數

7.使用執行緒的正確姿勢 降低延遲，提高吞吐量

7.1 創建最優數量執行緒

單核CPU
I/O 密集型計算 1 +（I/O 耗時 / CPU 耗時）

CPU 密集型計算 CPU 核數 +1
多核CPU
CPU 核數 * [ 1 +（I/O 耗時 / CPU 耗時）]

8.區域變數的安全性

區域變數是安全的，因為他只存在于堆疊中，且每個方法都有自己的呼叫堆疊，

執行緒封閉：方法里的區域變數，因為不會和其他執行緒共享，所以沒有并發問題，這個思路很好，已經成為解決并發問題的一個重要技術，同時還有個響當當的名字叫做執行緒封閉，比較官方的解釋是：僅在單執行緒內訪問資料，

比如資料庫連接Conn,因為JDBC規范并沒有要求必須是執行緒安全的，資料庫連接池通過執行緒封閉技術，保證一個Conn一旦被一個執行緒獲取后，在這個執行緒關閉之前不會把這個Con分給其他執行緒

9.Java面向物件思想與并發編程的融合之旅

9.1 封裝共享變數

對于這些不會發生變化的共享變數，建議你用 final 關鍵字來

9.2 注意If判斷

在我們的指定并發訪問策略是利用原子類，所以我們要特別注競態條件判斷
反應在代碼里面

public class SafeWM {
 // 庫存上限
 private final AtomicLong upper =
 new AtomicLong(0);
 // 庫存下限
 private final AtomicLong lower =
 new AtomicLong(0);
 // 設定庫存上限
 void setUpper(long v){
 // 檢查引數合法性
 if (v < lower.get()) {
 throw new IllegalArgumentException();
 }
 upper.set(v);
 }
 // 設定庫存下限
 void setLower(long v){
 // 檢查引數合法性
 if (v > upper.get()) {
 throw new IllegalArgumentException();
 }
 lower.set(v);
 }
 // 省略其他業務代碼
}

在這個類中，我們用了原子類AtomicLong來保證我們存取的值的安全性，
我們假設庫存的下限和上限分別是 (2,10)，執行緒 A 呼叫 setUpper(5) 將上限設定為 5，線
程 B 呼叫 setLower(7) 將下限設定為 7，如果執行緒 A 和執行緒 B 完全同時執行，你會發現線
程 A 能夠通過引數校驗，因為這個時候，下限還沒有被執行緒 B 設定，還是 2，而 5>2；線
程 B 也能夠通過引數校驗，因為這個時候，上限還沒有被執行緒 A 設定，還是 10，而
7<10，當執行緒 A 和執行緒 B 都通過引數校驗后，就把庫存的下限和上限設定成 (7, 5) 了，顯
然此時的結果是不符合庫存下限要小于庫存上限這個約束條件的，
這個時候光只用原子類是不行的，

9.4 制定并發訪問策略

三個方案

1.避免共享：避免共享的技術主要是利于執行緒本地存盤以及為每個任務分配獨立的執行緒，
我的理解可能就是ThreadLocal

2.不變模式：java運用少 不解釋

3.管程及其他同步工具：java并發包

三原則

1.優先使用成熟的工具類，而不是自己造輪子

2.迫不得已才使用低級的同步原理
這里主要指的是 synchronized、Lock、
Semaphore 等，這些雖然感覺簡單，但實際上并沒那么簡單，一定要小心使用，

3.避免過早優化：并發程式首先要保證安全，出現性能瓶頸時再優化

總結

思考題:

1.下面的代碼用 synchronized 修飾代碼塊來嘗試解決并發問題，你覺得這個使用方式正確
嗎？有哪些問題呢？能解決可見性和原子性問題嗎？

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

我的答案：不正確，圖中的資源是Value,但是在兩個方法中用了不同的鎖去請求方法，所以會出現執行緒不安全，

官方答案:，每次呼叫方法 get()、addOne() 都創建了不同的鎖，相當于無鎖，這里需要
你再次加深一下記憶，“一個合理的受保護資源與鎖之間的關聯關系應該是 N:1”，只有
共享一把鎖才能起到互斥的作用，

2.加粗：這個問題我錯了

class Account {
 // 賬戶余額 
 private Integer balance;
 // 賬戶密碼
 private String password;
 // 取款
 void withdraw(Integer amt) {
 synchronized(balance) {
 if (this.balance > amt){
 this.balance -= amt;
 }
 }
 } 
 // 更改密碼
 void updatePassword(String pw){
 synchronized(password) {
 this.password = pw;
 }
 } 
}

我的答案：這個物件多個執行緒用的如果是同一個，那么就可行，

官方答案錯！！！！
1.鎖可能會變
2.Interger和Sting型別不適合做鎖，因為他們在JVM可能被重用，
那么你的鎖可能別其他代碼使用，如果其他代碼 synchronized(你的鎖)，而且不釋放，那你的程式就永遠拿不
到鎖，這是隱藏的風險

通過這兩個反例，我們可以總結出這樣一個基本的原則：鎖，應是私有的、不可變的、不可
重用的，我們經常看到別人家的鎖，都長成下面示例代碼這樣

// 普通物件鎖
private final Object 
 lock = new Object();
// 靜態物件鎖
private static final Object
 lock = new Object();

撒花~~~~