溫馨提示×

溫馨提示×

您好,登錄后才能下訂單哦!

密碼登錄×
登錄注冊×
其他方式登錄
點擊 登錄注冊 即表示同意《億速云用戶服務(wù)條款》

Go語言中的數(shù)據(jù)競爭模式實例分析

發(fā)布時間:2022-07-21 10:08:05 來源:億速云 閱讀:91 作者:iii 欄目:開發(fā)技術(shù)

這篇文章主要介紹了Go語言中的數(shù)據(jù)競爭模式實例分析的相關(guān)知識,內(nèi)容詳細易懂,操作簡單快捷,具有一定借鑒價值,相信大家閱讀完這篇Go語言中的數(shù)據(jù)競爭模式實例分析文章都會有所收獲,下面我們一起來看看吧。

Go在goroutine中通過引用來透明地捕獲自由變量 

Go中的嵌套函數(shù)(又名closure)通過引用的方式,透明地捕獲所有自由的變量。程序員通常無需明確指定在closure語法中,需要捕獲哪些自由變量。

這種方式是有別于Java和C++的。Java的lambda僅會根據(jù)數(shù)值去捕獲,而且他們會有意識地避免并發(fā)缺陷。而C++則要求開發(fā)人員明確地指明是使用數(shù)值、還是引用的捕獲方式。

當closure較大時,開發(fā)人員并不知道closure內(nèi)使用的變量是否自由,可否通過引用來捕獲。而由于引用的捕獲、以及goroutine都是并發(fā)的,因此Go程序最終可能會因為沒能顯式地執(zhí)行同步,而對自由變量進行無序的訪問。我們可以通過如下三個示例來證明這一點:

示例1:由循環(huán)索引的變量捕獲,而導(dǎo)致數(shù)據(jù)競爭

圖1A中的代碼顯示了迭代Go的切片作業(yè),并通過ProcessJob函數(shù)來處理每個元素的作業(yè)。

Go語言中的數(shù)據(jù)競爭模式實例分析

圖1A:由循環(huán)索引的變量捕獲,而導(dǎo)致數(shù)據(jù)競爭。

在此,開發(fā)人員會將厚重的ProcessJob包裝在一個匿名的goroutine中。但是,循環(huán)索引變量的作業(yè)是通過goroutine內(nèi)部被引用捕獲的。當goroutine為首次循環(huán)迭代而啟動,并訪問作業(yè)的變量時,父goroutine中的for循環(huán)將在切片中更新相同的循環(huán)索引變量作業(yè),并指向切片中的第二個元素,這就會導(dǎo)致數(shù)據(jù)競爭的出現(xiàn)。此類數(shù)據(jù)競爭可能發(fā)生在數(shù)值和引用類型上;切片、數(shù)組和映射上;以及循環(huán)體中的讀和寫的訪問中。為此,Go推薦了一種編碼習慣,來隱藏和私有化循環(huán)體中循環(huán)索引的變量。不過,開發(fā)人員并不總是能夠遵循這一點。

示例2:由err變量的捕獲,所導(dǎo)致的數(shù)據(jù)競爭

Go語言中的數(shù)據(jù)競爭模式實例分析

圖1B:由err變量的捕獲,所導(dǎo)致的數(shù)據(jù)競爭。

Go一直提倡函數(shù)有多個返回值。圖1B展示了一種常見的通過返回實際值和錯誤對象,來指示是否存在錯誤的用法??梢?,當且僅當錯誤值為nil(空)時,實際的返回值才會被認為是有意義的。因此,我們的通常做法是:將返回的錯誤對象,分配給名為err的變量,然后檢查其是否為空(nilness)。不過,由于我們可以在函數(shù)體內(nèi)調(diào)用多個返回錯誤的函數(shù),因此程序每次都會對err變量進行多次賦值,然后進行是否為空的檢查。當開發(fā)人員將這個習慣用法與goroutine混合使用時,錯誤變量就會在closure中被引用捕獲。結(jié)果,程序?qū)τ趃oroutine中err的讀寫訪問,與隨后對封閉函數(shù)(或goroutine的多個實例)中相同的err變量的讀寫操作,就會同時運行。這便導(dǎo)致了數(shù)據(jù)競爭。

示例3:由已命名的返回變量捕獲,所導(dǎo)致的數(shù)據(jù)競爭

Go語言中的數(shù)據(jù)競爭模式實例分析

圖1C:由已命名的返回變量捕獲,所導(dǎo)致的數(shù)據(jù)競爭。

Go引入了一種被稱為已命名返回值的語法塊。已命名的返回變量被視為在函數(shù)頂部定義的變量,其作用域超出了函數(shù)體。而沒有參數(shù)的return語句,被稱為“裸”命名返回值。由于closure的存在,如果將正常(非裸)的返回與已命名的返回相混合、或在具有命名返回的函數(shù)中使用延遲返回,那么就可能會引發(fā)數(shù)據(jù)競爭。

在上圖1C中的NamedReturnCallee函數(shù)返回了一個整數(shù),而且返回變量被命名為result。根據(jù)該語法,函數(shù)體的其余部分可以對結(jié)果進行直接讀寫,而無需額外聲明。如果函數(shù)在第4行返回的是一個裸返回,而由于在第2行被賦值為result=10,那么第13行的調(diào)用者將看到其返回值為10。編譯器則會安排將結(jié)果復(fù)制到retVal。同時,已命名的返回函數(shù)也可以使用如第9行所示的標準返回語法。該語法會讓編譯器復(fù)制return語句中的返回值20,以分配給已命名的返回變量結(jié)果。第6行創(chuàng)建了一個goroutine,它會捕獲已命名的返回變量的結(jié)果。在設(shè)置該goroutine時,即使是并發(fā)專家也可能認為讀取第7行的結(jié)果中是安全的,畢竟不存在對同一變量的寫入,而且第9行的語句返回的20是一個常量,它似乎并沒有觸及到已命名的返回變量結(jié)果。不過,如前所述,代碼在生成的過程中,會將return 20的語句轉(zhuǎn)換為寫入結(jié)果。此時,一旦我們突然對共享的結(jié)果變量進行并發(fā)讀寫,就會產(chǎn)生數(shù)據(jù)競爭的情況。

切片會產(chǎn)生難以診斷的數(shù)據(jù)競爭 

切片(Slices)實際上是一些動態(tài)數(shù)組和引用類型。在其內(nèi)部,切片包含了一個指向底層數(shù)組的指針、它的當前長度、以及底層數(shù)組可以擴展的最大容量。為了便于討論,我們將這些變量統(tǒng)稱為切片的元字段(meta field)。切片上的一種常見操作便是通過追加操作(append operation)來使其增長。當達到其容量限制時,代碼會進行新的分配(例如,對當前的容量翻倍),并更新其對應(yīng)的元字段。而當一個切片被goroutine并發(fā)訪問時,Go會通過互斥鎖(mutex),來保護對它的訪問。

Go語言中的數(shù)據(jù)競爭模式實例分析

圖2:即使使用鎖,切片仍會出現(xiàn)數(shù)據(jù)競爭。

在圖2中,開發(fā)人員往往以為已經(jīng)對第6行的切片進行了鎖定保護,便可防止數(shù)據(jù)競爭的出現(xiàn)。而實際上,當?shù)?4行將切片作為參數(shù)傳遞給沒有鎖保護的goroutine時,就會產(chǎn)生數(shù)據(jù)競爭。具體而言,goroutine的調(diào)用導(dǎo)致了切片中的元字段從調(diào)用處(第14行)被復(fù)制到被調(diào)用者(第11行)處??紤]到切片屬于引用類型,我們認為在將其傳遞(復(fù)制)到被調(diào)用者時,會導(dǎo)致數(shù)據(jù)競爭的發(fā)生。不過,由于切片與指針類型不同,畢竟元字段是按照數(shù)值復(fù)制的,因此該數(shù)據(jù)競爭的發(fā)生概率非常低。

并發(fā)訪問Go內(nèi)置的、不安全的線程映射會導(dǎo)致頻繁的數(shù)據(jù)競爭 

哈希表(或稱映射)是Go中的內(nèi)置語言功能。不過,它對于線程是不安全的。如果多個goroutine同時訪問同一張哈希表,而且其中至少有一個試圖去修改哈希表(插入或刪除某項)的話,就會產(chǎn)生數(shù)據(jù)競爭。開發(fā)人員往往認為他們可以同時訪問哈希表中的不同項。而實際上,與數(shù)組或切片不同,映射(哈希表)是一種稀疏的數(shù)據(jù)結(jié)構(gòu),訪問某一個元素就可能會導(dǎo)致訪問另一個元素,如果在同一過程中發(fā)生了另一種插入或刪除,那么它將會因為修改了稀疏的數(shù)據(jù)結(jié)構(gòu),而導(dǎo)致了數(shù)據(jù)競爭。

我們甚至觀察到了更為復(fù)雜的、由并發(fā)映射訪問產(chǎn)生的數(shù)據(jù)競爭。其原因是同一個哈希表被傳遞到了深度調(diào)用路徑,而開發(fā)人員忘記了這些調(diào)用路徑是通過異步goroutine去改變哈希表的事實。圖3便顯示了此類數(shù)據(jù)競爭的示例。

Go語言中的數(shù)據(jù)競爭模式實例分析

圖3:由于并發(fā)映射訪問導(dǎo)致的數(shù)據(jù)競爭。

雖然導(dǎo)致數(shù)據(jù)競爭的哈希表并非Go獨有,但是以下原因會讓Go更容易發(fā)生數(shù)據(jù)競爭:

  • 由于映射是一種內(nèi)置的語言結(jié)構(gòu),因此Go開發(fā)人員會比其他語言的開發(fā)者更頻繁地使用映射。例如,在我們的Java存儲庫中,每MLoC(Millions of Lines Of Code,數(shù)百萬行代碼)里有4,389個映射結(jié)構(gòu);而在Go中,每MLoC里就有5,950個映射,足足高出了1.34倍。

  • 不同于Java的get和put API,哈希表的訪問語法類似數(shù)組訪問語法,雖然易于使用,但是也會意外地與隨機訪問數(shù)據(jù)結(jié)構(gòu)相混淆。在Go中,我們可以使用table[key]的語法,輕松查詢那些不存在(non-existing)的映射元素。該語法能夠簡單地返回默認值,而不會產(chǎn)生任何錯誤。這種容錯性對于開發(fā)者在使用Go的映射時是非常友好的。

Go開發(fā)人員常在pass-by-value時犯錯并導(dǎo)致non-trivial的數(shù)據(jù)競爭

Go建議使用pass-by-value的語義,以簡化逃逸分析,并為變量提供更好的棧上分配的機會,進而減少垃圾收集器的壓力。

與所有對象皆為引用類型的Java不同,在Go中,對象可以是數(shù)值類型(如:結(jié)構(gòu)),也可以是引用類型(如:接口)。由于沒有了語法差異,這會導(dǎo)致諸如:sync.Mutex和sync.RWMutex等數(shù)值類型,在同步構(gòu)造中被錯誤地使用。如果一個函數(shù)創(chuàng)建了一個互斥體結(jié)構(gòu),并通過數(shù)值傳遞(pass-by-value)給多個goroutine調(diào)用,那么這些goroutine在并發(fā)執(zhí)行時,不同的互斥對象是不會在操作過程中共享內(nèi)部狀態(tài)的。這也就破壞了對于受保護的共享內(nèi)存區(qū)域的互斥訪問特性。請參見如下圖4所示的代碼。

Go語言中的數(shù)據(jù)競爭模式實例分析

圖4A:

由by-reference或by-pointer的方法調(diào)用所引起的數(shù)據(jù)競爭

Go語言中的數(shù)據(jù)競爭模式實例分析

圖4B:sync.Mutex的Lock/Unlock簽名。

由于Go語法在指針和數(shù)值上調(diào)用方法是相同的,因此開發(fā)人員往往會忽視m.Lock()正在處理互斥鎖的副本并非指針這一問題。調(diào)用者仍然可以在互斥的數(shù)值上調(diào)用這些API。而且編譯器也會透明地安排傳遞數(shù)值的地址。相反,如果沒有此類透明度,該錯誤就能夠會被檢測到,并認定為編譯器類型不匹配的錯誤。

據(jù)此,當開發(fā)人員意外地實現(xiàn)了一個方法,其中的接收者是指向結(jié)構(gòu)的指針,而不是結(jié)構(gòu)的數(shù)值或副本時,那么就會發(fā)生與此相反的情況。也就是說,調(diào)用該方法的多個goroutine,最終會意外地共享結(jié)構(gòu)相同的內(nèi)部狀態(tài)。而且,調(diào)用者也不會意識到數(shù)值類型在接收者處被透明地轉(zhuǎn)換為了指針類型。顯然,這都是開發(fā)人員所不愿發(fā)生的。

消息傳遞(通道)和共享內(nèi)存的混合使用使代碼變得復(fù)雜且易受數(shù)據(jù)競爭的影響

Go語言中的數(shù)據(jù)競爭模式實例分析

圖5:將消息傳遞與共享內(nèi)存混合時的數(shù)據(jù)競爭。

圖5展示了開發(fā)人員使用一個專門為信號和等待準備的通道,通過Future來實現(xiàn)的示例。我們可以通過調(diào)用Start()方法來啟動Future,并通過調(diào)用Future的Wait()方法,來阻止Future的完成。Start()方法會創(chuàng)建一個goroutine,以執(zhí)行一個注冊到Future的函數(shù),并記錄其返回值(如:response和err)。如第6行所示,goroutine通過在通道ch上發(fā)送一條消息,以向Wait()方法發(fā)出Future完成的信號。對稱地,如第11行所示,Wait()方法塊會從通道中獲取相應(yīng)的消息。

在Go中,上下文攜帶了跨越API邊界和進程之間的截止日期、取消信號和其他請求范圍的數(shù)值。這是在微服務(wù)中為任務(wù)設(shè)置時間線的常見模式。由此,Wait()阻止了被取消(第13行)的上下文、或已完成的Future(第11行)。此外,Wait()被包裝在一個select語句(第10行)中,并處于阻止狀態(tài),直到至少有一個選擇arm準備就緒。

如果上下文超時,則相應(yīng)的案例將Future的err字段,在第14行上記錄為ErrCancelled。此時,對于err的寫入與第5行對Future的相同變量的寫入操作,便形成了競爭。

Add和Done方法的錯誤放置會導(dǎo)致數(shù)據(jù)競爭

sync.WaitGroup結(jié)構(gòu)是Go的組同步結(jié)構(gòu)。與C++的barrier的barrier、以及l(fā)atch的構(gòu)造不同,WaitGroup中參與者的數(shù)量不是在構(gòu)造時被確定的,而是動態(tài)更新的。在WaitGroup對象上,Go允許進行Add(int)、Done()和Wait()三種操作。其中,Add()會增加參與者的計數(shù),而Wait()會處于阻止狀態(tài),直到Done()被調(diào)用為count的次數(shù)(通常每個參與者一次)。由于在Go中,組同步的使用程度比Java高出1.9倍,因此WaitGroup在Go中常被廣泛地使用。

在下圖6中,開發(fā)人員打算創(chuàng)建與切片itemId里的元素數(shù)量相同的goroutine,且并發(fā)處理它們。每個goroutine在不同索引的結(jié)果切片、以及在第12行對父功能塊中,記錄其成功或失敗的狀態(tài),直到所有的goroutine已完成。接著,它會依次訪問結(jié)果中的所有元素,以計算出被成功處理的數(shù)量。

Go語言中的數(shù)據(jù)競爭模式實例分析

圖6A:

由于WaitGroup.Add()的錯誤放置,導(dǎo)致了數(shù)據(jù)競爭

為了使該代碼能夠正常工作,我們需要在第12行調(diào)用Wait()時,保證wg.Add(1)在調(diào)用wg.Wait()之前所執(zhí)行的次數(shù),也就是注冊參與者的數(shù)量,必須等于itemIds的長度。這就意味著wg.Add(1)應(yīng)該在每個goroutine之前被放置在第5行調(diào)用。但是,如果開發(fā)人員在第7行錯誤地將wg.Add(1)放置在了goroutine的主體中,它就無法保證在外部函數(shù)WaitGrpExample調(diào)用Wait()時,完整地執(zhí)行。據(jù)此,在調(diào)用Wait()時,被注冊到WaitGroup的itemId的長度就可能會變短。正是出于該原因,Wait()會被提前解除阻止。據(jù)此,WaitGrpExample函數(shù)則可以從切片結(jié)果中開始讀取(即:第13行),而一些goroutine則開始并發(fā)寫入同一個切片。

此外,我們還發(fā)現(xiàn)過早地在Waitgroup上調(diào)用wg.Done(),也會導(dǎo)致數(shù)據(jù)競爭。下圖6B展示了wg.Done()與Go的defer語句交互的結(jié)果。當遇到多個defer語句時,代碼會按照“后進先出”的順序去執(zhí)行。其中,第9行的wg.Wait()會在doCleanup()運行之前完成。即,父goroutine會在第10行去訪問locationErr,而子goroutine可能仍然在延遲的doCleanup()函數(shù)內(nèi)寫入locationErr(為簡潔起見,在此并未顯示)。

Go語言中的數(shù)據(jù)競爭模式實例分析

圖6B:由于WaitGroup.Done()的錯誤放置

延遲語句排序,并導(dǎo)致了數(shù)據(jù)競爭。

并發(fā)運行測試會導(dǎo)致產(chǎn)品或測試代碼中的數(shù)據(jù)競爭 

測試是Go的內(nèi)置功能。在那些后綴為_test.go的文件里,任何前綴為Test的函數(shù),都可以測試由Go構(gòu)建的系統(tǒng)。如果測試代碼調(diào)用了API--testing.T.Parallel(),那么它將與其他同類測試并發(fā)運行。我們發(fā)現(xiàn)此類并發(fā)測試有時會在測試代碼中、有時也會在產(chǎn)品代碼中產(chǎn)生大量的數(shù)據(jù)競爭。

此外,在單個以Test為前綴的函數(shù)中,Go開發(fā)人員經(jīng)常會編寫許多子測試,并通過由Go提供的套件包去執(zhí)行它們。Go推薦開發(fā)人員通過表驅(qū)動的測試套件習語(table-driven test suite idiom)去編寫和運行測試套件。據(jù)此,我們的開發(fā)人員在同一個測試中就編寫了數(shù)十、甚至數(shù)百個可供系統(tǒng)并發(fā)運行的子測試。開發(fā)人員以為代碼會執(zhí)行串行測試,而忘記了在大型復(fù)雜測試套件中使用共享對象。此外,當產(chǎn)品級API在缺少線程安全(可能是因為沒有需要)的情況下,被并發(fā)調(diào)用時,情況就會更加惡化。

小結(jié) 

在上文中,我們分析了Go語言里的各種數(shù)據(jù)競爭模式,并對其背后的原因進行了分類。當然,不同的原因也可能會相互作用與影響。下表是對各種問題的匯總。

Go語言中的數(shù)據(jù)競爭模式實例分析

圖7:數(shù)據(jù)競爭待分類。

上面討論的主要是基于我們在Uber的Go monorepo中發(fā)現(xiàn)的各種數(shù)據(jù)競爭模式,難免有些掛一漏萬。其實,代碼的交錯覆蓋也可能產(chǎn)生數(shù)據(jù)競爭模式。希望上述提到的各種經(jīng)驗?zāi)軌驇椭嗟腉o開發(fā)人員,去關(guān)注并發(fā)代碼的編寫,考慮不同的語言的特性、以及避免由于自身編程習慣所引發(fā)的并發(fā)錯誤。

關(guān)于“Go語言中的數(shù)據(jù)競爭模式實例分析”這篇文章的內(nèi)容就介紹到這里,感謝各位的閱讀!相信大家對“Go語言中的數(shù)據(jù)競爭模式實例分析”知識都有一定的了解,大家如果還想學(xué)習更多知識,歡迎關(guān)注億速云行業(yè)資訊頻道。

向AI問一下細節(jié)

免責聲明:本站發(fā)布的內(nèi)容(圖片、視頻和文字)以原創(chuàng)、轉(zhuǎn)載和分享為主,文章觀點不代表本網(wǎng)站立場,如果涉及侵權(quán)請聯(lián)系站長郵箱:is@yisu.com進行舉報,并提供相關(guān)證據(jù),一經(jīng)查實,將立刻刪除涉嫌侵權(quán)內(nèi)容。

AI