上次我們說到協程,我們再來回顧一下:
- 協程類似執行緒,是一種更為輕量級的排程單位
- 執行緒是系統級實現的,常見的排程方法是時間片輪轉法
- 協程是應用軟體級實現,原理與執行緒類似
- 協程的排程基於 GPM 模型實現
要是對協程的使用感興趣的話,可以看看這篇文章簡單瞭解一下瞅一眼就會使用GO的併發程式設計分享
今天我們來聊聊GO裡面的鎖
鎖是什麼?
鎖 是用於解決隔離性的一種機制
某個協程(執行緒)在訪問某個資源時先鎖住,防止其它協程的訪問,等訪問完畢解鎖後其他協程再來加鎖進行訪問
在我們生活中,我們應該不會陌生,鎖是這樣的
本意是指置於可啟閉的器物上,以鑰匙或暗碼開啟,引申義是用鎖鎖住、封閉
生活中用到的鎖
上鎖基本是為了防止外人進來、防止自己財物被盜
程式語言中的鎖
鎖的種類更是多種多樣,每種鎖的加鎖開銷以及應用場景也不盡相同
鎖是用來做什麼的?
用來控制各個協程的同步,防止資源競爭導致錯亂問題
在高併發的場景下,如果選對了合適的鎖,則會大大提高系統的效能,否則效能會降低。
那麼知道各種鎖的開銷,以及應用場景很有必要
GO中的鎖有哪些?
- 互斥鎖
- 讀寫鎖
我們在編碼中會存在多個 goroutine 協程同時操作一個資源(臨界區),這種情況會發生競態問題(資料競態)
舉一個生活中的例子
生活中最明顯的例子就是,大家搶著上廁所,資源有限,只能一個一個的用
舉一個編碼中的例子
package main
import (
"fmt"
"sync"
)
// 全域性變數
var num int64
var wg sync.WaitGroup
func add() {
for i := 0; i < 10000000; i++ {
num = num + 1
}
// 協程退出, 記錄 -1
wg.Done()
}
func main() {
// 啟動2個協程,記錄 2
wg.Add(2)
go add()
go add()
// 等待子協程退出
wg.Wait()
fmt.Println(num)
}
按照上述程式碼,我們的輸出結果應該是 20000000
,每一個協程計算 10000000 次,可是實際結果卻是
10378923
每一次計算的結果還不一樣,出現這個問題的原因就是上述提到的資源競爭
兩個 goroutine 協程在訪問和修改num變數,會存在2個協程同時對num+1 , 最終num 總共只加了 1 ,而不是 2
這就導致最後的結果與期待的不符,那麼我們如何解決呢?
我們當然是用鎖控制同步了,保證各自協程在操作臨界區資源的時候,先確實是否拿到鎖,只有拿到鎖了才能進行對臨界區資源的修改
先來看看互斥鎖
互斥鎖
互斥鎖的簡單理解就像上述我們講到上廁所的案例一樣,同一時間點,只能有一個人在使用其他人只能排隊等待
在程式設計中,引入了物件互斥鎖的概念,來保證共享資料操作的完整性
每個物件都對應於一個可稱為互斥鎖
的標記,這個標記用來保證在任一時刻,只能有一個協程訪問該物件。
應用場景
寫大於讀操作的
它代表的資源就是一個,不管是讀者還是寫者,只要誰擁有了它,那麼其他人就只有等待解鎖後
我們來使用互斥鎖解決上述的問題
互斥鎖 - 解決問題
互斥鎖是一種常用的控制共享資源訪問的方法,它能夠保證同時只有一個 goroutine 協程可以訪問共享資源
Go 中使用到如下 1個知識點來解決
- sync包 的 Mutex型別 來實現互斥鎖
package main
import (
"fmt"
"sync"
)
// 全域性變數
var num int64
var wg sync.WaitGroup
var lock sync.Mutex
func add() {
for i := 0; i < 10000000; i++ {
// 訪問資源前 加鎖
lock.Lock()
num = num + 1
// 訪問資源後 解鎖
lock.Unlock()
}
// 協程退出, 記錄 -1
wg.Done()
}
func main() {
// 啟動2個協程,記錄 2
wg.Add(2)
go add()
go add()
// 等待子協程退出
wg.Wait()
fmt.Println(num)
}
執行上述程式碼,我們能看到,輸出的結果與我們預期的一致
20000000
使用互斥鎖能夠保證同一時間有且只有一個goroutine 協程進入臨界區,其他的goroutine則在等待鎖
當互斥鎖釋放後,等待的 goroutine 協程才可以獲取鎖進入臨界區
如何知道哪一個協程是先被喚醒呢?
可是,多個goroutine 協程同時等待一個鎖時,如何知道哪一個協程是先被喚醒呢?
互斥鎖這裡的喚醒的策略是隨機的,並不知道到底是先喚醒誰
讀寫鎖
為什麼有了互斥鎖 ,還要讀寫鎖呢?
很明顯就是互斥鎖不能滿足所有的應用場景,就催生出了讀寫鎖,我們細細道來
互斥鎖是完全互斥的,不管協程是讀臨界區資源還是寫臨界區資源,都必須要拿到鎖,否則就無法操作(這個限制太死了對嗎?)
可是在我們實際的應用場景下是讀多寫少
若我們併發的去讀取一個資源,且不對資源做任何修改的時候如果也要加鎖才能讀取資料,是不是就很沒有必要呢
這種場景下讀寫鎖就發揮作用了,他就相對靈活了,也很好的解決了讀多寫少的場景問題
讀寫鎖的種類
- 讀鎖
- 寫鎖
當一個goroutine 協程獲取讀鎖之後,其他的 goroutine 協程如果是獲取讀鎖會繼續獲得鎖
可如果是獲取寫鎖就必須等待
當一個 goroutine 協程獲取寫鎖之後,其他的goroutine 協程無論是獲取讀鎖還是寫鎖都會等待
我們先來寫一個讀寫鎖的DEMO
Go 中使用到如下 1個知識點來解決
- sync包 的 RWMutex型別 來實現讀寫鎖
package main
import (
"fmt"
"sync"
"time"
)
var (
num int64
wg sync.WaitGroup
//lock sync.Mutex
rwlock sync.RWMutex
)
func write() {
// 加互斥鎖
// lock.Lock()
// 加寫鎖
rwlock.Lock()
num = num + 1
// 模擬真實寫資料消耗的時間
time.Sleep(10 * time.Millisecond)
// 解寫鎖
rwlock.Unlock()
// 解互斥鎖
// lock.Unlock()
// 退出協程前 記錄 -1
wg.Done()
}
func read() {
// 加互斥鎖
// lock.Lock()
// 加讀鎖
rwlock.RLock()
// 模擬真實讀取資料消耗的時間
time.Sleep(time.Millisecond)
// 解讀鎖
rwlock.RUnlock()
// 解互斥鎖
// lock.Unlock()
// 退出協程前 記錄 -1
wg.Done()
}
func main() {
// 用於計算時間 消耗
start := time.Now()
// 開5個協程用作 寫
for i := 0; i < 5; i++ {
wg.Add(1)
go write()
}
// 開500 個協程,用作讀
for i := 0; i < 1000; i++ {
wg.Add(1)
go read()
}
// 等待子協程退出
wg.Wait()
end := time.Now()
// 列印程式消耗的時間
fmt.Println(end.Sub(start))
}
我們開5個協程用於寫,開1000個協程用於讀,使用讀寫鎖加鎖,結果耗時 54.4871ms
如下
54.4871ms
如果我們將上述程式碼修改成加 互斥鎖,執行之後的結果是 1.7750029s
如下
1.7750029s
是不是結果相差很大呢,對於不同的場景應用不同的鎖,對於我們的程式效能影響也是很大,當然上述結果,若讀協程,和寫協程的個數差距越大,結果就會越懸殊
我們總結一下這一小塊的邏輯:
- 寫者是排他性的,一個讀寫鎖同時只能有一個寫者或多個讀者
- 不能同時既有讀者又有寫者
- 如果讀寫鎖當前沒有讀者,也沒有寫者,那麼寫者可以立刻獲得讀寫鎖,否則它必須自旋在那裡,直到沒有任何寫者或讀者。
- 如果讀寫鎖沒有寫者,那麼讀者可以立即獲得該讀寫鎖,否則讀者必須自旋在那裡,直到寫者釋放該讀寫鎖。
上述提了自旋鎖,我們來簡單解釋一下,什麼是自旋鎖
自旋鎖是專為防止多處理器併發而引入的一種鎖,它在核心中大量應用於中斷處理等部分(對於單處理器來說,防止中斷處理中的併發可簡單採用關閉中斷的方式,即在標誌暫存器中關閉/開啟中斷標誌位,不需要自旋鎖)。
簡單來說,在併發過程中,若其中一個協程拿不到鎖,他會不停的去嘗試拿鎖,不停的去看能不能拿,而不是阻塞睡眠
自旋鎖和互斥鎖的區別
- 互斥鎖
當拿不到鎖的時候,會阻塞等待,會睡眠,等待鎖釋放後被喚醒
- 自旋鎖
當拿不到鎖的時候,會在原地不停的看能不能拿到鎖,所以叫做自旋,他不會阻塞,不會睡眠
如何選擇鎖?
對於 C/C++ 而言
- 若加鎖後的業務操作消耗,大於互斥鎖阻塞後切換上下文的消耗 ,那麼就選擇互斥鎖
- 若加鎖後的業務操作消耗,小於互斥鎖阻塞後切換上下文的消耗,那麼選擇自旋鎖
對於 GO 而言
- 若寫的頻次大大的多餘讀的頻次,那麼選擇互斥鎖
- 若讀的頻次大大的多餘寫的頻次,那麼選擇讀寫鎖
我們都是對自身要求比較高的同學,那麼有沒有比鎖還好用的東西呢?
自然是有的,我們來看看原子操作
啥是原子操作
“原子操作(atomic operation)是不需要synchronized”,這是多執行緒程式設計的老生常談了。所謂原子操作是指不會被執行緒排程機制打斷的操作
這種操作一旦開始,就一直執行到結束,中間不會有任何 context switch (切換到另一個執行緒)。
原子操作的特性:
- 原子操作是不可分割的,在執行完畢之前不會被任何其它任務或事件中斷
上述我們的加鎖案例,我們們編碼中的加鎖操作會涉及核心態的上下文切換會比較耗時、代價比較高
針對基本的資料型別我們還可以使用原子操作來保證併發安全
因為原子操作是Go語言提供的方法它在使用者態就可以完成,因此效能比加鎖操作更好
不用我們自己寫彙編,這裡 GO 也提供了原子操作的包,供我們一起來使用 sync/atomic
我們對上述的案例做一個延伸
package main
import (
"fmt"
"sync"
"sync/atomic"
"time"
)
var num int64
var l sync.Mutex
var wg sync.WaitGroup
// 普通版加函式
func add() {
num = num + 1
wg.Done()
}
// 互斥鎖版加函式
func mutexAdd() {
l.Lock()
num = num + 1
l.Unlock()
wg.Done()
}
// 原子操作版加函式
func atomicAdd() {
atomic.AddInt64(&num, 1)
wg.Done()
}
func main() {
// 目的是 記錄程式消耗時間
start := time.Now()
for i := 0; i < 20000; i++ {
wg.Add(1)
// go add() // 無鎖的 add函式 不是併發安全的
// go mutexAdd() // 互斥鎖的 add函式 是併發安全的,因為拿不到互斥鎖會阻塞,所以加鎖效能開銷大
go atomicAdd() // 原子操作的 add函式 是併發安全,效能優於加鎖的
}
// 等待子協程 退出
wg.Wait()
end := time.Now()
fmt.Println(num)
// 列印程式消耗時間
fmt.Println(end.Sub(start))
}
我們使用上述 demo 程式碼,模擬了3種情況下,程式的耗時以及計算結果對比
- 不加鎖
無鎖的 add函式 不是併發安全的
19495
11.9474ms
- 加互斥鎖
互斥鎖的 add函式 是併發安全的,因為拿不到互斥鎖會阻塞,所以加鎖效能開銷大
20000
14.9586ms
- 使用原子操作
原子操作的 add函式 是併發安全,效能優於加鎖的
20000
9.9726ms
總結
- 分享了鎖是什麼,用來做什麼
- 分享了互斥鎖,讀寫鎖,以及其區別和應用場景
- 分享了原子操作
- 大家感興趣可以去看看鎖的實現,裡面也是有使用原子操作
歡迎點贊,關注,收藏
朋友們,你的支援和鼓勵,是我堅持分享,提高質量的動力
好了,本次就到這裡,下一次 GO通道和sync包的分享
技術是開放的,我們的心態,更應是開放的。擁抱變化,向陽而生,努力向前行。
我是小魔童哪吒,歡迎點贊關注收藏,下次見~
本作品採用《CC 協議》,轉載必須註明作者和本文連結