近年來，Uber已經開始采用Golang（簡稱Go）作為開發微服務的主要編程語言。目前，其Go monorepo（譯者注：包含多個不同項目的單個倉庫）包含了大約5,000萬行代碼，以及大約2,100個獨特的Go服務。而且，它們都還在持續增長中。

為了實現并發，我們通常會使用go關鍵字，為函數調用添加前綴，以實現異步式的運行調用。在Go中，此類異步函數調用被稱為goroutine。開發人員可以通過創建goroutine（例如，對其他服務的IO或RPC調用），來隱藏延遲。不同的goroutine可以通過消息傳遞，以及共享內存的方式，來傳遞數據。其中，共享內存恰好是Go中最常用的數據通信方式之一。

由于goroutineGo很容易被程序員創建和使用，因此它被認為屬于“輕量級” 。同時，由Go編寫的程序通常會比由其他語言編寫的程序具有更強的并發性。例如，通過掃描數十萬個運行在數據中心的微服務實例，我們發現Go微服務的并發性可達Java微服務的8倍。

當然，更高的并發性也意味著更多潛在的并發錯誤。我們常用數據競爭（data race）來描述當兩個或多個goroutine訪問相同的數據，而且至少有一個處于寫入狀態時，由于它們之間并沒有排序，因此就會發生并發錯誤。總的來說，根據Go自身的相互作用等特點，數據競爭之類的隱蔽錯誤非常容易出現，因此我們應該盡量避免。

最近，我們使用動態數據競爭檢測技術開發了一個系統，專門用來檢測Uber的數據競爭。它在上線的六個月時間內，在我們的Go代碼庫中，檢測到了大約2,000個數據競爭。其中已被開發人員著手修復了的數據競爭約有1,100個。下面，我將向您展示我們已發現的各種常見數據競爭模式。

?

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

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

這種方式是有別于Java和C++的。Java的lambda僅會根據數值去捕獲，而且他們會有意識地避免并發缺陷。而C++則要求開發人員明確地指明是使用數值、還是引用的捕獲方式。當closure較大時，開發人員并不知道closure內使用的變量是否自由，可否通過引用來捕獲。而由于引用的捕獲、以及goroutine都是并發的，因此Go程序最終可能會因為沒能顯式地執行同步，而對自由變量進行無序的訪問。我們可以通過如下三個示例來證明這一點：

示例1：由循環索引的變量捕獲，而導致數據競爭

圖1A中的代碼顯示了迭代Go的切片作業，并通過ProcessJob函數來處理每個元素的作業。

圖1A：由循環索引的變量捕獲，而導致數據競爭

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

示例2：由err變量的捕獲，所導致的數據競爭

圖1B：由err變量的捕獲，所導致的數據競爭

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

示例3：由已命名的返回變量捕獲，所導致的數據競爭

圖1C：由已命名的返回變量捕獲，所導致的數據競爭

Go引入了一種被稱為已命名返回值的語法塊。已命名的返回變量被視為在函數頂部定義的變量，其作用域超出了函數體。而沒有參數的return語句，被稱為“裸”命名返回值。由于closure的存在，如果將正常（非裸）的返回與已命名的返回相混合、或在具有命名返回的函數中使用延遲返回，那么就可能會引發數據競爭。在上圖1C中的NamedReturnCallee函數返回了一個整數，而且返回變量被命名為result。根據該語法，函數體的其余部分可以對結果進行直接讀寫，而無需額外聲明。如果函數在第4行返回的是一個裸返回，而由于在第2行被賦值為result=10，那么第13行的調用者將看到其返回值為10。編譯器則會安排將結果復制到retVal。同時，已命名的返回函數也可以使用如第9行所示的標準返回語法。該語法會讓編譯器復制return語句中的返回值20，以分配給已命名的返回變量結果。第6行創建了一個goroutine，它會捕獲已命名的返回變量的結果。在設置該goroutine時，即使是并發專家也可能認為讀取第7行的結果中是安全的，畢竟不存在對同一變量的寫入，而且第9行的語句返回的20是一個常量，它似乎并沒有觸及到已命名的返回變量結果。不過，如前所述，代碼在生成的過程中，會將return 20的語句轉換為寫入結果。此時，一旦我們突然對共享的結果變量進行并發讀寫，就會產生數據競爭的情況。

?

切片會產生難以診斷的數據競爭 

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

圖2：即使使用鎖，切片仍會出現數據競爭

在圖2中，開發人員往往以為已經對第6行的切片進行了鎖定保護，便可防止數據競爭的出現。而實際上，當第14行將切片作為參數傳遞給沒有鎖保護的goroutine時，就會產生數據競爭。具體而言，goroutine的調用導致了切片中的元字段從調用處（第14行）被復制到被調用者（第11行）處。考慮到切片屬于引用類型，我們認為在將其傳遞（復制）到被調用者時，會導致數據競爭的發生。不過，由于切片與指針類型不同，畢竟元字段是按照數值復制的，因此該數據競爭的發生概率非常低。

?

并發訪問Go內置的、不安全的線程映射會導致頻繁的數據競爭 

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

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

圖3：由于并發映射訪問導致的數據競爭

雖然導致數據競爭的哈希表并非Go獨有，但是以下原因會讓Go更容易發生數據競爭：

• 由于映射是一種內置的語言結構，因此Go開發人員會比其他語言的開發者更頻繁地使用映射。例如，在我們的Java存儲庫中，每MLoC（Millions of Lines Of Code，數百萬行代碼）里有4,389個映射結構；而在Go中，每MLoC里就有5,950個映射，足足高出了1.34倍。
• 不同于Java的get和put API，哈希表的訪問語法類似數組訪問語法，雖然易于使用，但是也會意外地與隨機訪問數據結構相混淆。在Go中，我們可以使用table[key]的語法，輕松查詢那些不存在（non-existing）的映射元素。該語法能夠簡單地返回默認值，而不會產生任何錯誤。這種容錯性對于開發者在使用Go的映射時是非常友好的。

?

Go開發人員常在pass-by-value時犯錯并導致non-trivial的數據競爭

Go建議使用pass-by-value的語義，以簡化逃逸分析，并為變量提供更好的棧上分配的機會，進而減少垃圾收集器的壓力。與所有對象皆為引用類型的Java不同，在Go中，對象可以是數值類型（如：結構），也可以是引用類型（如：接口）。由于沒有了語法差異，這會導致諸如：sync.Mutex和sync.RWMutex等數值類型，在同步構造中被錯誤地使用。如果一個函數創建了一個互斥體結構，并通過數值傳遞（pass-by-value）給多個goroutine調用，那么這些goroutine在并發執行時，不同的互斥對象是不會在操作過程中共享內部狀態的。這也就破壞了對于受保護的共享內存區域的互斥訪問特性。請參見如下圖4所示的代碼。

圖4A：由by-reference或by-pointer的方法調用所引起的數據競爭

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

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

據此，當開發人員意外地實現了一個方法，其中的接收者是指向結構的指針，而不是結構的數值或副本時，那么就會發生與此相反的情況。也就是說，調用該方法的多個goroutine，最終會意外地共享結構相同的內部狀態。而且，調用者也不會意識到數值類型在接收者處被透明地轉換為了指針類型。顯然，這都是開發人員所不愿發生的。

?

消息傳遞（通道）和共享內存的混合使用使代碼變得復雜且易受數據競爭的影響

圖5：將消息傳遞與共享內存混合時的數據競爭

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

在Go中，上下文攜帶了跨越API邊界和進程之間的截止日期、取消信號和其他請求范圍的數值。這是在微服務中為任務設置時間線的常見模式。由此，Wait()阻止了被取消（第13行）的上下文、或已完成的Future（第11行）。此外，Wait()被包裝在一個select語句（第10行）中，并處于阻止狀態，直到至少有一個選擇arm準備就緒。如果上下文超時，則相應的案例將Future的err字段，在第14行上記錄為ErrCancelled。此時，對于err的寫入與第5行對Future的相同變量的寫入操作，便形成了競爭。

?

Add和Done方法的錯誤放置會導致數據競爭

sync.WaitGroup結構是Go的組同步結構。與C++的barrier的barrier、以及latch的構造不同，WaitGroup中參與者的數量不是在構造時被確定的，而是動態更新的。在WaitGroup對象上，Go允許進行Add(int)、Done()和Wait()三種操作。其中，Add()會增加參與者的計數，而Wait()會處于阻止狀態，直到Done()被調用為count的次數（通常每個參與者一次）。由于在Go中，組同步的使用程度比Java高出1.9倍，因此WaitGroup在Go中常被廣泛地使用。在下圖6中，開發人員打算創建與切片itemId里的元素數量相同的goroutine，且并發處理它們。每個goroutine在不同索引的結果切片、以及在第12行對父功能塊中，記錄其成功或失敗的狀態，直到所有的goroutine已完成。接著，它會依次訪問結果中的所有元素，以計算出被成功處理的數量。

圖6A：由于WaitGroup.Add()的錯誤放置，導致了數據競爭

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

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

圖6B：由于WaitGroup.Done()的錯誤放置延遲語句排序，并導致了數據競爭

并發運行測試會導致產品或測試代碼中的數據競爭 

測試是Go的內置功能。在那些后綴為_test.go的文件里，任何前綴為Test的函數，都可以測試由Go構建的系統。如果測試代碼調用了API--testing.T.Parallel()，那么它將與其他同類測試并發運行。我們發現此類并發測試有時會在測試代碼中、有時也會在產品代碼中產生大量的數據競爭。

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

?

小結 

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

圖7：數據競爭待分類

上面討論的主要是基于我們在Uber的Go monorepo中發現的各種數據競爭模式，難免有些掛一漏萬。其實，代碼的交錯覆蓋也可能產生數據競爭模式。希望上述提到的各種經驗能夠幫助更多的Go開發人員，去關注并發代碼的編寫，考慮不同的語言的特性、以及避免由于自身編程習慣所引發的并發錯誤。

原文鏈接：https://eng.uber.com/data-race-patterns-in-go/

?

譯者介紹

陳峻 （Julian Chen），51CTO社區編輯，具有十多年的IT項目實施經驗，善于對內外部資源與風險實施管控，專注傳播網絡與信息安全知識與經驗；持續以博文、專題和譯文等形式，分享前沿技術與新知；經常以線上、線下等方式，開展信息安全類培訓與授課。