【Go】併發編程

　　Go語言宣揚用通信的方式共享數據。

　　Go語言以獨特的併發編程模型傲視羣雄，與併發編程關係最緊密的代碼包就是sync包，意思是同步。同步的用途有兩個，一個是避免多個線程在同一時刻操做同一個數據塊，另外一個是協調多個線程，以免它們在同一時刻執行同一塊代碼。因爲這一的數據庫和代碼塊的背後都隱含着一種或多種資源，因此能夠把它們當作是共享資源，同步就是控制多個線程對共享資源的訪問。

　　一個線程在想要訪問某一個共享資源時，須要先申請對該資源的訪問權限，而且只有在申請成功以後，訪問才能真正開始，而當線程對共享資源的訪問結束時，它還必須歸還對該資源的訪問權限，若要再次訪問仍需申請。多個併發運行的線程對一個共享資源的訪問是徹底串行的。

　　在Go語言中，最經常使用的同步工具當屬互斥量（mutex)。sync包中的Mutex就是與其對應的類型，該類型的值能夠被稱爲互斥量或互斥鎖。一個互斥鎖能夠被用來保護一個臨界區或者一組臨界區，能夠經過它來保證，在同一時刻只有一個goroutin處於該臨界區以內。每當有goroutine想進入臨界區時，都須要先對它進行鎖定，而且每一個goroutine離開臨界區時，都要及時對它進行解鎖。鎖定操做能夠經過調用互斥鎖的Lock方法實現，解鎖操做能夠調用互斥鎖的Unlock方法

mu.Lock()
_, err := writer.Write([]byte(data))
if err != nil {
 log.Printf("error: %s [%d]", err, id)
}
mu.Unlock()

 

使用互斥鎖的注意事項有：

1.不要重複鎖定互斥鎖

　　對一個已經被鎖定的互斥鎖進行鎖定，會當即阻塞當前的goroutine

　　當Go語言運行時系統發現全部的用戶級goroutine都處於等待狀態（死鎖），就會自行拋出一個帶有以下信息的panic：

fatal error: all goroutines are asleep - deadlock!

 

　　這種由Go語言運行時系統自行拋出的panic屬於致命錯誤，都是沒法被恢復的，調用recover函數對它們起不到任何做用，即一旦產生死鎖，程序必然奔潰+

　　避免這種狀況的發生，最簡單有效的方式就是讓每個互斥鎖都只保護一個臨界區

 

2.不要忘記解鎖互斥鎖，必要時使用defer語句

　　忘記解鎖會使其餘goroutine沒法進入到該互斥鎖保護的臨界區，這輕則會致使一些程序功能的失效，重則會形成死鎖和程序奔潰。

 

3.不要對還沒有鎖定或者已解鎖的互斥鎖解鎖

　　解鎖爲鎖定的鎖會當即引起panic，應該老是抱着，對每個鎖定操做，都要有且只有一個對應的解鎖操做。

 

4.不要在多個函數之間直接傳遞互斥鎖

　　Go語言中的互斥鎖是開箱即用的，一旦聲明瞭一個sync。Mutex類型的變量，就能夠直接使用它。但該類型是一個結構體類型，屬於值類型的一種，把它傳給一個函數、將它從函數中返回、把它賦值給其餘變量、讓它進入某個通道都會致使它的副本的產生。而且原值和它的副本，以及多個副本之間都是徹底獨立的，它們都是不一樣的互斥鎖。若是把一個互斥鎖做爲參數值傳給了一個函數，那麼在這個函數中對傳入的鎖的全部操做，都不會對存在於該函數以外的那個原鎖產生任何影響。

 

 

讀寫鎖和互斥鎖有哪些異同？

　　讀寫鎖是讀/寫互斥鎖的簡稱。在Go語言中，讀寫鎖由sync.RWMutex類型的值表明，也是開箱即用的。讀寫鎖把對共享資源的讀操做和寫操做區別對待了，它能夠對這兩種操做施加不一樣程度的保護。

　　一個讀寫鎖實際上包含了兩個鎖，即：讀鎖和寫鎖。sync.RWMutex類型中的Lock方法和Unlock方法分別用於對寫鎖進行鎖定和解鎖，而它的RLock方法和RUnlock方法則分別用於對讀鎖進行鎖定和解鎖

　　另外，對於同一個讀寫鎖來講有以下規則：

• 在寫鎖已被鎖定的狀況下再試圖鎖定寫鎖，會阻塞當前的goroutine
• 在寫鎖已被鎖定的狀況試圖鎖定讀鎖，會阻塞當前goroutine
• 在讀鎖已被鎖定的狀況下鎖定寫鎖，會阻塞當前goroutine
• 在讀鎖已被鎖定的狀況下再試圖鎖定讀鎖，不會阻塞當前的goroutine

 

條件變量（conditional variable）

　　條件變量並非被用來保護臨界區和共享資源的，它是用於協調想要訪問共享資源的那些線程的。當共享資源的狀態發生變化時，它能夠被用來通知被互斥鎖阻塞的線程。

　　條件變量提供三個方法：等待通知（wait）、單發通知（signal）和廣播通知（broadcast）。在等待通知的時候須要在條件變量基於的那個互斥鎖的保護下進行。在進行單發或者廣播通知時，須要在對應互斥鎖解鎖以後作這兩種操做。

　　舉個栗子，兩我的在執行祕密任務，須要在不直接聯繫和見面的前提下進行，一我的須要向信箱裏放置情報，另外一我的須要從信箱裏獲取情報，這個信箱就如同一個共享資源。

var mailbox uint8   // 信箱，值爲0表示情報，值爲1表示有情報
var lock sync.RWMutex  // 讀寫鎖
//sync.Cond類型不是開箱即用，須要利用sync.NewCond來建立。
sendCond := sync.NewCond(&lock)  //*sync.Cond類型
recvCond := sync.NewCond(lock.RLocker()) //*sync.Cond類型

 　　條件變量是基於互斥鎖的，所以這裏的sync.Locker類型的參數值不可或缺。

　　sync.Locker是一個接口，在它聲明中只包含兩個方法的定義，Lock()和UnLock。sync.Mutex和sync.RWMutex類型都擁有Lock方法和Unlock方法，只不過它們都是指針方法。所以這兩個類型的指針類型纔算sync.Locker接口的實現類型。

　　這裏在爲sendCond作初始化時，把基於lock變量的指針值傳給了sync.NewCond函數。由於lock變量的Lock方法和Unlock方法分別用於對寫鎖的鎖定和解鎖，它們與sendCond變量的含義是對應的。sendCond變量是專門爲放置情報而準備的條件變量，向信箱中放置情報。

　　recvCond變量表明的是專門爲獲取情報而準備的條件變量。與sendCond不一樣，lock變量中用於對讀鎖進行鎖定和解鎖的方法是RLock和RUnlock，它們與sync.Locker接口中定義的方法並不匹配。須要調用sync.RWMutex類型的RLocker方法實現這一需求。lock.RLocker()得來的值所擁有的Lock方法和UnLock方法，在其內部會分別調用lock變量的RLock和RUnlock方法，即前兩個方法僅僅是後兩個方法的代理。

　　定義好了變量，那放置情報並通知另一我的應該怎麼作呢

lock.Lock()  // 持有信箱上的鎖，寫操做
for mailbox == 1 {
 sendCond.Wait()   //若是有情報，就等待
}
mailbox = 1   //放入情報
lock.Unlock()  //寫完
recvCond.Signal()

　　獲取情報

lock.RLock()  // 讀操做
for mailbox == 0 {
 recvCond.Wait()  //沒有情報
}
mailbox = 0  //取走情報
lock.RUnlock()  //讀完
sendCond.Signal()

 

條件變量的Wait方法作了什麼？

一、把調用它的goroutine（當前的goroutine）加入到當前條件變量的通知隊列中

二、解鎖當前條件變量基於的那個互斥鎖

三、讓當前的goroutine處於等待狀態，等到通知到來時再決定是否喚醒它，這時這個goroutine就會阻塞在調用這個Wait方法的那行代碼上

四、若是通知到來而且決定喚醒這個goroutine，那麼就在喚醒它以後從新鎖定當前條件變量基於的互斥鎖。自此之後，當前的goroutine就會繼續執行後面的代碼

 

　　爲何先要鎖定條件變量基於的互斥鎖，才能調用它的Wait方法？

　　那由於條件變量的Wait方法在阻塞當前的goroutine以前會解鎖它基於的互斥鎖，因此在調用該Wait方法以前，必須先鎖定那個互斥鎖，不然在調用這個Wait方法時，會引起一個不可恢復的panic

 

　　爲何要用for語句包裹調用其Wait方法的表達式，用if語句不行嗎?

　　顯然，if語句只會對共享資源的狀態檢查一次，for語句能夠作屢次檢查，直到這個狀態改變爲止。

 

　　那爲何要作屢次檢查呢？

　　主要是爲了保險起見。若是一個goroutine因收到通知而被喚醒，但卻發現共享資源的狀態依然不符合它的要求，那麼就應該再次調用條件變量的Wait方法，並繼續等待下次通知的到來。

 

　　那何時會出現上述的狀況呢？

　　1）有多個goroutine在等待共享資源的同一種狀態。雖然等待的goroutine不少，但每次成功的goroutine卻可能只有一個。成功的goroutine最終解鎖互斥鎖以後，其餘的goroutine會前後進入臨界區，但它們會發現共享資源狀態依然不是它們想要的。

　　2）共享資源狀態可能有的狀態不是兩個，如mailbox變量可能值不僅有0和1，還有2，3，4。但每次改變後的結果只可能有一個，因此單一的結果必定不可能知足全部goroutine的條件，那些未被知足的goroutine須要繼續等待。

　　3）在一些多CPU核心的計算機系統中，即便沒有收到條件變量的通知，調用其Wait方法的goroutine也是有可能被喚醒的。這是硬件層面決定的。

 

條件變量的Signal方法和Broadcast方法有何異同？ 

 　　條件變量的Signal方法和Broadcast方法都是用來發送通知的，不一樣的是，前者的通知只會喚醒一個所以而等待的goroutine，然後者的通知卻會喚醒全部爲此等待的goroutine。

　　條件變量的Wait方法總會把當前的goroutine添加到隊列的隊尾，而它的Signal方法總會從通知隊列的隊首開始查找可被喚醒的goroutine，因此，因Signal方法的通知而被喚醒的goroutine通常都是最先等待的那個。

　　條件變量的Signal方法和Broadcast方法不須要在互斥鎖保護下執行。

　　條件變量的通知有即時性。即若是發生通知的時候沒有goroutine爲此等待，那麼該通知就會被遺棄