Go語言的互斥鎖的詳細(xì)使用
前言
當(dāng)提到并發(fā)編程、多線程編程時(shí),都會(huì)在第一時(shí)間想到鎖,鎖是并發(fā)編程中的同步原語,他可以保證多線程在訪問同一片內(nèi)存時(shí)不會(huì)出現(xiàn)競爭來保證并發(fā)安全;在
Go
語言中更推崇由channel
通過通信的方式實(shí)現(xiàn)共享內(nèi)存,這個(gè)設(shè)計(jì)點(diǎn)與許多主流編程語言不一致,但是Go
語言也在sync
包中提供了互斥鎖、讀寫鎖,畢竟channel
也不能滿足所有場景,互斥鎖、讀寫鎖的使用與我們是分不開的,所以接下來我會(huì)分兩篇來分享互斥鎖、讀寫鎖是怎么實(shí)現(xiàn)的,本文我們先來看看互斥鎖的實(shí)現(xiàn)。
本文基于Golang
版本:1.18
Go語言互斥鎖設(shè)計(jì)實(shí)現(xiàn)
mutex介紹
sync
包下的mutex
就是互斥鎖,其提供了三個(gè)公開方法:調(diào)用Lock()
獲得鎖,調(diào)用Unlock()
釋放鎖,在Go1.18
新提供了TryLock()
方法可以非阻塞式的取鎖操作:
Lock()
:調(diào)用Lock
方法進(jìn)行加鎖操作,使用時(shí)應(yīng)注意在同一個(gè)goroutine
中必須在鎖釋放時(shí)才能再次上鎖,否則會(huì)導(dǎo)致程序panic
。Unlock()
:調(diào)用UnLock
方法進(jìn)行解鎖操作,使用時(shí)應(yīng)注意未加鎖的時(shí)候釋放鎖會(huì)引起程序panic
,已經(jīng)鎖定的 Mutex 并不與特定的 goroutine 相關(guān)聯(lián),這樣可以利用一個(gè) goroutine 對(duì)其加鎖,再利用其他 goroutine 對(duì)其解鎖。tryLock()
:調(diào)用TryLock
方法嘗試獲取鎖,當(dāng)鎖被其他 goroutine 占有,或者當(dāng)前鎖正處于饑餓模式,它將立即返回 false,當(dāng)鎖可用時(shí)嘗試獲取鎖,獲取失敗不會(huì)自旋/阻塞,也會(huì)立即返回false;
mutex
的結(jié)構(gòu)比較簡單只有兩個(gè)字段:
type Mutex struct { state int32 sema uint32 }
state
:表示當(dāng)前互斥鎖的狀態(tài),復(fù)合型字段;sema
:信號(hào)量變量,用來控制等待goroutine
的阻塞休眠和喚醒
初看結(jié)構(gòu)你可能有點(diǎn)懵逼,互斥鎖應(yīng)該是一個(gè)復(fù)雜東西,怎么就兩個(gè)字段就可以實(shí)現(xiàn)?那是因?yàn)樵O(shè)計(jì)使用了位的方式來做標(biāo)志,state
的不同位分別表示了不同的狀態(tài),使用最小的內(nèi)存來表示更多的意義,其中低三位由低到高分別表示mutexed
、mutexWoken
和 mutexStarving
,剩下的位則用來表示當(dāng)前共有多少個(gè)goroutine
在等待鎖:
const ( mutexLocked = 1 << iota // 表示互斥鎖的鎖定狀態(tài) mutexWoken // 表示從正常模式被從喚醒 mutexStarving // 當(dāng)前的互斥鎖進(jìn)入饑餓狀態(tài) mutexWaiterShift = iota // 當(dāng)前互斥鎖上等待者的數(shù)量 )
mutex
最開始的實(shí)現(xiàn)只有正常模式,在正常模式下等待的線程按照先進(jìn)先出的方式獲取鎖,但是新創(chuàng)建的gouroutine
會(huì)與剛被喚起的 goroutine
競爭,會(huì)導(dǎo)致剛被喚起的 goroutine
獲取不到鎖,這種情況的出現(xiàn)會(huì)導(dǎo)致線程長時(shí)間被阻塞下去,所以Go
語言在1.9
中進(jìn)行了優(yōu)化,引入了饑餓模式,當(dāng)goroutine
超過1ms
沒有獲取到鎖,就會(huì)將當(dāng)前互斥鎖切換到饑餓模式,在饑餓模式中,互斥鎖會(huì)直接交給等待隊(duì)列最前面的goroutine
,新的 goroutine 在該狀態(tài)下不能獲取鎖、也不會(huì)進(jìn)入自旋狀態(tài),它們只會(huì)在隊(duì)列的末尾等待。如果一個(gè) goroutine 獲得了互斥鎖并且它在隊(duì)列的末尾或者它等待的時(shí)間少于 1ms,那么當(dāng)前的互斥鎖就會(huì)切換回正常模式。
mutex
的基本情況大家都已經(jīng)掌握了,接下來我們從加鎖到解鎖來分析mutex
是如何實(shí)現(xiàn)的;
Lock加鎖
從Lock
方法入手:
func (m *Mutex) Lock() { // 判斷當(dāng)前鎖的狀態(tài),如果鎖是完全空閑的,即m.state為0,則對(duì)其加鎖,將m.state的值賦為1 if atomic.CompareAndSwapInt32(&m.state, 0, mutexLocked) { if race.Enabled { race.Acquire(unsafe.Pointer(m)) } return } // Slow path (outlined so that the fast path can be inlined) m.lockSlow() }
上面的代碼主要兩部分邏輯:
- 通過
CAS
判斷當(dāng)前鎖的狀態(tài),也就是state
字段的低1位,如果鎖是完全空閑的,即m.state為0,則對(duì)其加鎖,將m.state的值賦為1 - 若當(dāng)前鎖已經(jīng)被其他
goroutine
加鎖,則進(jìn)行lockSlow
方法嘗試通過自旋或饑餓狀態(tài)下饑餓goroutine
競爭方式等待鎖的釋放,我們?cè)谙旅娼榻BlockSlow
方法;
lockSlow
代碼段有點(diǎn)長,主體是一個(gè)for
循環(huán),其主要邏輯可以分為以下三部分:
- 狀態(tài)初始化
- 判斷是否符合自旋條件,符合條件進(jìn)行自旋操作
- 搶鎖準(zhǔn)備期望狀態(tài)
- 通過
CAS
操作更新期望狀態(tài)
初始化狀態(tài)
在locakSlow
方法內(nèi)會(huì)先初始化5個(gè)字段:
func (m *Mutex) lockSlow() { var waitStartTime int64 starving := false awoke := false iter := 0 old := m.state ........ }
waitStartTime
用來計(jì)算waiter
的等待時(shí)間starving
是饑餓模式標(biāo)志,如果等待時(shí)長超過1ms,starving置為true,后續(xù)操作會(huì)把Mutex也標(biāo)記為饑餓狀態(tài)。awoke
表示協(xié)程是否喚醒,當(dāng)goroutine
在自旋時(shí),相當(dāng)于CPU上已經(jīng)有在等鎖的協(xié)程。為避免Mutex解鎖時(shí)再喚醒其他協(xié)程,自旋時(shí)要嘗試把Mutex置為喚醒狀態(tài),Mutex處于喚醒狀態(tài)后 要把本協(xié)程的 awoke 也置為true。iter
用于記錄協(xié)程的自旋次數(shù),old
記錄當(dāng)前鎖的狀態(tài)
自旋
自旋的判斷條件非常苛刻:
for { // 判斷是否允許進(jìn)入自旋 兩個(gè)條件,條件1是當(dāng)前鎖不能處于饑餓狀態(tài) // 條件2是在runtime_canSpin內(nèi)實(shí)現(xiàn),其邏輯是在多核CPU運(yùn)行,自旋的次數(shù)小于4 if old&(mutexLocked|mutexStarving) == mutexLocked && runtime_canSpin(iter) { // !awoke 判斷當(dāng)前goroutine不是在喚醒狀態(tài) // old&mutexWoken == 0 表示沒有其他正在喚醒的goroutine // old>>mutexWaiterShift != 0 表示等待隊(duì)列中有正在等待的goroutine // atomic.CompareAndSwapInt32(&m.state, old, old|mutexWoken) 嘗試將當(dāng)前鎖的低2位的Woken狀態(tài)位設(shè)置為1,表示已被喚醒, 這是為了通知在解鎖Unlock()中不要再喚醒其他的waiter了 if !awoke && old&mutexWoken == 0 && old>>mutexWaiterShift != 0 && atomic.CompareAndSwapInt32(&m.state, old, old|mutexWoken) { // 設(shè)置當(dāng)前goroutine喚醒成功 awoke = true } // 進(jìn)行自旋 runtime_doSpin() // 自旋次數(shù) iter++ // 記錄當(dāng)前鎖的狀態(tài) old = m.state continue } }
自旋這里的條件還是很復(fù)雜的,我們想讓當(dāng)前goroutine
進(jìn)入自旋轉(zhuǎn)的原因是我們樂觀的認(rèn)為當(dāng)前正在持有鎖的goroutine能在較短的時(shí)間內(nèi)歸還鎖,所以我們需要一些條件來判斷,mutex
的判斷條件我們?cè)谖淖置枋鲆幌拢?/p>
old&(mutexLocked|mutexStarving) == mutexLocked
用來判斷鎖是否處于正常模式且加鎖,為什么要這么判斷呢?
mutexLocked
二進(jìn)制表示為 0001
mutexStarving
二進(jìn)制表示為 0100
mutexLocked|mutexStarving
二進(jìn)制為 0101. 使用0101在當(dāng)前狀態(tài)做 &
操作,如果當(dāng)前處于饑餓模式,低三位一定會(huì)是1,如果當(dāng)前處于加鎖模式,低1位一定會(huì)是1,所以使用該方法就可以判斷出當(dāng)前鎖是否處于正常模式且加鎖;
runtime_canSpin()
方法用來判斷是否符合自旋條件:
// / go/go1.18/src/runtime/proc.go const active_spin = 4 func sync_runtime_canSpin(i int) bool { if i >= active_spin || ncpu <= 1 || gomaxprocs <= int32(sched.npidle+sched.nmspinning)+1 { return false } if p := getg().m.p.ptr(); !runqempty(p) { return false } return true }
自旋條件如下:
- 自旋的次數(shù)要在4次以內(nèi)
CPU
必須為多核GOMAXPROCS>1
- 當(dāng)前機(jī)器上至少存在一個(gè)正在運(yùn)行的處理器 P 并且處理的運(yùn)行隊(duì)列為空;
判斷當(dāng)前goroutine
可以進(jìn)自旋后,調(diào)用runtime_doSpin
方法進(jìn)行自旋:
const active_spin_cnt = 30 func sync_runtime_doSpin() { procyield(active_spin_cnt) } // asm_amd64.s TEXT runtime·procyield(SB),NOSPLIT,$0-0 MOVL cycles+0(FP), AX again: PAUSE SUBL $1, AX JNZ again RET
循環(huán)次數(shù)被設(shè)置為30
次,自旋操作就是執(zhí)行30次PAUSE
指令,通過該指令占用CPU
并消費(fèi)CPU
時(shí)間,進(jìn)行忙等待;
這就是整個(gè)自旋操作的邏輯,這個(gè)就是為了優(yōu)化 等待阻塞->喚醒->參與搶占鎖這個(gè)過程不高效,所以使用自旋進(jìn)行優(yōu)化,在期望在這個(gè)過程中鎖被釋放。
搶鎖準(zhǔn)備期望狀態(tài)
自旋邏輯處理好后開始根據(jù)上下文計(jì)算當(dāng)前互斥鎖最新的狀態(tài),根據(jù)不同的條件來計(jì)算mutexLocked
、mutexStarving
、mutexWoken
和 mutexWaiterShift
:
首先計(jì)算mutexLocked
的值:
// 基于old狀態(tài)聲明到一個(gè)新狀態(tài) new := old // 新狀態(tài)處于非饑餓的條件下才可以加鎖 if old&mutexStarving == 0 { new |= mutexLocked }
計(jì)算mutexWaiterShift
的值:
//如果old已經(jīng)處于加鎖或者饑餓狀態(tài),則等待者按照FIFO的順序排隊(duì) if old&(mutexLocked|mutexStarving) != 0 { new += 1 << mutexWaiterShift }
計(jì)算mutexStarving
的值:
// 如果當(dāng)前鎖處于饑餓模式,并且已被加鎖,則將低3位的Starving狀態(tài)位設(shè)置為1,表示饑餓 if starving && old&mutexLocked != 0 { new |= mutexStarving }
計(jì)算mutexWoken
的值:
// 當(dāng)前goroutine的waiter被喚醒,則重置flag if awoke { // 喚醒狀態(tài)不一致,直接拋出異常 if new&mutexWoken == 0 { throw("sync: inconsistent mutex state") } // 新狀態(tài)清除喚醒標(biāo)記,因?yàn)楹竺娴膅oroutine只會(huì)阻塞或者搶鎖成功 // 如果是掛起狀態(tài),那就需要等待其他釋放鎖的goroutine來喚醒。 // 假如其他goroutine在unlock的時(shí)候發(fā)現(xiàn)Woken的位置不是0,則就不會(huì)去喚醒,那該goroutine就無法在被喚醒后加鎖 new &^= mutexWoken }
通過CAS
操作更新期望狀態(tài)
上面我們已經(jīng)得到了鎖的期望狀態(tài),接下來通過CAS
將鎖的狀態(tài)進(jìn)行更新:
// 這里嘗試將鎖的狀態(tài)更新為期望狀態(tài) if atomic.CompareAndSwapInt32(&m.state, old, new) { // 如果原來鎖的狀態(tài)是沒有加鎖的并且不處于饑餓狀態(tài),則表示當(dāng)前goroutine已經(jīng)獲取到鎖了,直接推出即可 if old&(mutexLocked|mutexStarving) == 0 { break // locked the mutex with CAS } // 到這里就表示goroutine還沒有獲取到鎖,waitStartTime是goroutine開始等待的時(shí)間,waitStartTime != 0就表示當(dāng)前goroutine已經(jīng)等待過了,則需要將其放置在等待隊(duì)列隊(duì)頭,否則就排到隊(duì)列隊(duì)尾 queueLifo := waitStartTime != 0 if waitStartTime == 0 { waitStartTime = runtime_nanotime() } // 阻塞等待 runtime_SemacquireMutex(&m.sema, queueLifo, 1) // 被信號(hào)量喚醒后檢查當(dāng)前goroutine是否應(yīng)該表示為饑餓 // 1. 當(dāng)前goroutine已經(jīng)饑餓 // 2. goroutine已經(jīng)等待了1ms以上 starving = starving || runtime_nanotime()-waitStartTime > starvationThresholdNs // 再次獲取當(dāng)前鎖的狀態(tài) old = m.state // 如果當(dāng)前處于饑餓模式, if old&mutexStarving != 0 { // 如果當(dāng)前鎖既不是被獲取也不是被喚醒狀態(tài),或者等待隊(duì)列為空 這代表鎖狀態(tài)產(chǎn)生了不一致的問題 if old&(mutexLocked|mutexWoken) != 0 || old>>mutexWaiterShift == 0 { throw("sync: inconsistent mutex state") } // 當(dāng)前goroutine已經(jīng)獲取了鎖,等待隊(duì)列-1 delta := int32(mutexLocked - 1<<mutexWaiterShift // 當(dāng)前goroutine非饑餓狀態(tài) 或者 等待隊(duì)列只剩下一個(gè)waiter,則退出饑餓模式(清除饑餓標(biāo)識(shí)位) if !starving || old>>mutexWaiterShift == 1 { delta -= mutexStarving } // 更新狀態(tài)值并中止for循環(huán),拿到鎖退出 atomic.AddInt32(&m.state, delta) break } // 設(shè)置當(dāng)前goroutine為喚醒狀態(tài),且重置自璇次數(shù) awoke = true iter = 0 } else { // 鎖被其他goroutine占用了,還原狀態(tài)繼續(xù)for循環(huán) old = m.state }
這塊的邏輯很復(fù)雜,通過CAS
來判斷是否獲取到鎖,沒有通過 CAS 獲得鎖,會(huì)調(diào)用 runtime.sync_runtime_SemacquireMutex
通過信號(hào)量保證資源不會(huì)被兩個(gè) goroutine
獲取,runtime.sync_runtime_SemacquireMutex
會(huì)在方法中不斷嘗試獲取鎖并陷入休眠等待信號(hào)量的釋放,一旦當(dāng)前 goroutine
可以獲取信號(hào)量,它就會(huì)立刻返回,如果是新來的goroutine
,就需要放在隊(duì)尾;如果是被喚醒的等待鎖的goroutine
,就放在隊(duì)頭,整個(gè)過程還需要啃代碼來加深理解。
解鎖
相對(duì)于加鎖操作,解鎖的邏輯就沒有那么復(fù)雜了,接下來我們來看一看UnLock
的邏輯:
func (m *Mutex) Unlock() { // Fast path: drop lock bit. new := atomic.AddInt32(&m.state, -mutexLocked) if new != 0 { // Outlined slow path to allow inlining the fast path. // To hide unlockSlow during tracing we skip one extra frame when tracing GoUnblock. m.unlockSlow(new) } }
使用AddInt32
方法快速進(jìn)行解鎖,將m.state的低1位置為0,然后判斷新的m.state值,如果值為0,則代表當(dāng)前鎖已經(jīng)完全空閑了,結(jié)束解鎖,不等于0
說明當(dāng)前鎖沒有被占用,會(huì)有等待的goroutine
還未被喚醒,需要進(jìn)行一系列喚醒操作,這部分邏輯就在unlockSlow
方法內(nèi):
func (m *Mutex) unlockSlow(new int32) { // 這里表示解鎖了一個(gè)沒有上鎖的鎖,則直接發(fā)生panic if (new+mutexLocked)&mutexLocked == 0 { throw("sync: unlock of unlocked mutex") } // 正常模式的釋放鎖邏輯 if new&mutexStarving == 0 { old := new for { // 如果沒有等待者則直接返回即可 // 如果鎖處于加鎖的狀態(tài),表示已經(jīng)有g(shù)oroutine獲取到了鎖,可以返回 // 如果鎖處于喚醒狀態(tài),這表明有等待的goroutine被喚醒了,不用嘗試獲取其他goroutine了 // 如果鎖處于饑餓模式,鎖之后會(huì)直接給等待隊(duì)頭goroutine if old>>mutexWaiterShift == 0 || old&(mutexLocked|mutexWoken|mutexStarving) != 0 { return } // 搶占喚醒標(biāo)志位,這里是想要把鎖的狀態(tài)設(shè)置為被喚醒,然后waiter隊(duì)列-1 new = (old - 1<<mutexWaiterShift) | mutexWoken if atomic.CompareAndSwapInt32(&m.state, old, new) { // 搶占成功喚醒一個(gè)goroutine runtime_Semrelease(&m.sema, false, 1) return } // 執(zhí)行搶占不成功時(shí)重新更新一下狀態(tài)信息,下次for循環(huán)繼續(xù)處理 old = m.state } } else { // 饑餓模式釋放鎖邏輯,直接喚醒等待隊(duì)列g(shù)oroutine runtime_Semrelease(&m.sema, true, 1) } }
我們?cè)趩拘?code>goroutine時(shí)正常模式/饑餓模式都調(diào)用func runtime_Semrelease(s *uint32, handoff bool, skipframes int)
,這兩種模式在第二個(gè)參數(shù)的傳參上不同,如果handoff is true, pass count directly to the first waiter.
。
非阻塞加鎖
Go
語言在1.18
版本中引入了非阻塞加鎖的方法TryLock()
,其實(shí)現(xiàn)就很簡潔:
func (m *Mutex) TryLock() bool { // 記錄當(dāng)前狀態(tài) old := m.state // 處于加鎖狀態(tài)/饑餓狀態(tài)直接獲取鎖失敗 if old&(mutexLocked|mutexStarving) != 0 { return false } // 嘗試獲取鎖,獲取失敗直接獲取失敗 if !atomic.CompareAndSwapInt32(&m.state, old, old|mutexLocked) { return false } return true }
TryLock
的實(shí)現(xiàn)就比較簡單了,主要就是兩個(gè)判斷邏輯:
- 判斷當(dāng)前鎖的狀態(tài),如果鎖處于加鎖狀態(tài)或饑餓狀態(tài)直接獲取鎖失敗
- 嘗試獲取鎖,獲取失敗直接獲取鎖失敗
TryLock
并不被鼓勵(lì)使用,至少我還沒想到有什么場景可以使用到它。
總結(jié)
通讀源碼后你會(huì)發(fā)現(xiàn)互斥鎖的邏輯真的十分復(fù)雜,代碼量雖然不多,但是很難以理解,一些細(xì)節(jié)點(diǎn)還需要大家多看看幾遍才能理解其為什么這樣做,文末我們?cè)倏偨Y(jié)一下互斥鎖的知識(shí)點(diǎn):
- 互斥鎖有兩種模式:正常模式、饑餓模式,饑餓模式的出現(xiàn)是為了優(yōu)化正常模式下剛被喚起的
goroutine
與新創(chuàng)建的goroutine
競爭時(shí)長時(shí)間獲取不到鎖,在Go1.9
時(shí)引入饑餓模式,如果一個(gè)goroutine
獲取鎖失敗超過1ms
,則會(huì)將Mutex
切換為饑餓模式,如果一個(gè)goroutine
獲得了鎖,并且他在等待隊(duì)列隊(duì)尾 或者 他等待小于1ms
,則會(huì)將Mutex
的模式切換回正常模式 - 加鎖的過程:
- 鎖處于完全空閑狀態(tài),通過CAS直接加鎖
- 當(dāng)鎖處于正常模式、加鎖狀態(tài)下,并且符合自旋條件,則會(huì)嘗試最多4次的自旋
- 若當(dāng)前
goroutine
不滿足自旋條件時(shí),計(jì)算當(dāng)前goroutine的鎖期望狀態(tài) - 嘗試使用CAS更新鎖狀態(tài),若更新鎖狀態(tài)成功判斷當(dāng)前
goroutine
是否可以獲取到鎖,獲取到鎖直接退出即可,若獲取不到鎖則陷入睡眠,等待被喚醒 - goroutine被喚醒后,如果鎖處于饑餓模式,則直接拿到鎖,否則重置自旋次數(shù)、標(biāo)志喚醒位,重新走for循環(huán)自旋、獲取鎖邏輯;
- 解鎖的過程
- 原子操作mutexLocked,如果鎖為完全空閑狀態(tài),直接解鎖成功
- 如果鎖不是完全空閑狀態(tài),,那么進(jìn)入
unlockedslow
邏輯 - 如果解鎖一個(gè)未上鎖的鎖直接panic,因?yàn)闆]加鎖
mutexLocked
的值為0,解鎖時(shí)進(jìn)行mutexLocked - 1操作,這個(gè)操作會(huì)讓整個(gè)互斥鎖混亂,所以需要有這個(gè)判斷 - 如果鎖處于饑餓模式直接喚醒等待隊(duì)列隊(duì)頭的waiter
- 如果鎖處于正常模式下,沒有等待的goroutine可以直接退出,如果鎖已經(jīng)處于鎖定狀態(tài)、喚醒狀態(tài)、饑餓模式則可以直接退出,因?yàn)橐呀?jīng)有被喚醒的
goroutine
獲得了鎖.
- 使用互斥鎖時(shí)切記拷貝
Mutex
,因?yàn)榭截?code>Mutex時(shí)會(huì)連帶狀態(tài)一起拷貝,因?yàn)?code>Lock時(shí)只有鎖在完全空閑時(shí)才會(huì)獲取鎖成功,拷貝時(shí)連帶狀態(tài)一起拷貝后,會(huì)造成死鎖 - TryLock的實(shí)現(xiàn)邏輯很簡單,主要判斷當(dāng)前鎖處于加鎖狀態(tài)、饑餓模式就會(huì)直接獲取鎖失敗,嘗試獲取鎖失敗直接返回;
到此這篇關(guān)于Go語言的互斥鎖的詳細(xì)使用的文章就介紹到這了,更多相關(guān)Go語言 互斥鎖內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家!
相關(guān)文章
Go語言模型:string的底層數(shù)據(jù)結(jié)構(gòu)與高效操作詳解
這篇文章主要介紹了Go語言模型:string的底層數(shù)據(jù)結(jié)構(gòu)與高效操作詳解,具有很好的參考價(jià)值,希望對(duì)大家有所幫助。一起跟隨小編過來看看吧2020-12-12Go語言range關(guān)鍵字循環(huán)時(shí)的坑
今天小編就為大家分享一篇關(guān)于Go語言range關(guān)鍵字循環(huán)時(shí)的坑,小編覺得內(nèi)容挺不錯(cuò)的,現(xiàn)在分享給大家,具有很好的參考價(jià)值,需要的朋友一起跟隨小編來看看吧2019-03-03詳解Go多協(xié)程并發(fā)環(huán)境下的錯(cuò)誤處理
這篇文章主要介紹了詳解Go多協(xié)程并發(fā)環(huán)境下的錯(cuò)誤處理,文中通過示例代碼介紹的非常詳細(xì),對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值,需要的朋友們下面隨著小編來一起學(xué)習(xí)學(xué)習(xí)吧2020-08-08Golang實(shí)現(xiàn)HTTP編程請(qǐng)求和響應(yīng)
本文主要介紹了Golang實(shí)現(xiàn)HTTP編程請(qǐng)求和響應(yīng),文中通過示例代碼介紹的非常詳細(xì),對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值,需要的朋友們下面隨著小編來一起學(xué)習(xí)學(xué)習(xí)吧2022-08-08golang?select?機(jī)制和超時(shí)問題
golang 中的協(xié)程使用非常方便,但是協(xié)程什么時(shí)候結(jié)束是一個(gè)控制問題,可以用 select 配合使用,這篇文章主要介紹了golang?select?機(jī)制和超時(shí)問題,需要的朋友可以參考下2022-06-06