如何使用Mutex確保併發程式的正確性

来源:https://www.cnblogs.com/chenjiazhan/archive/2023/03/15/17220186.html
-Advertisement-
Play Games

實現SpringBoot底層機制 Tomcat底層啟動分析+Spring容器初始化+Tomcat關聯Spring容器 1.任務1-創建Tomcat，並啟動 （1）創建一個Maven項目，修改pom.xml文件：我們需要自己創建Tomcat對象，因此在引入的場景啟動器中排除SpringBoot內嵌的T ...


1. 簡介

本文的主要內容是介紹Go中Mutex併發原語。包含Mutex的基本使用，使用的註意事項以及一些實踐建議。

2. 基本使用

2.1 基本定義

Mutex是Go語言中的一種同步原語，全稱為Mutual Exclusion，即互斥鎖。它可以在併發編程中實現對共用資源的互斥訪問，保證同一時刻只有一個協程可以訪問共用資源。Mutex通常用於控制對臨界區的訪問，以避免競態條件的出現。

2.2 使用方式

使用Mutex的基本方法非常簡單，可以通過調用Mutex的Lock方法來獲取鎖，然後通過Unlock方法釋放鎖，示例代碼如下：

import "sync"

var mutex sync.Mutex

func main() {
  mutex.Lock()    // 獲取鎖
  // 執行需要同步的操作
  mutex.Unlock()  // 釋放鎖
}

2.3 使用例子

2.3.1 未使用mutex同步代碼示例

下麵是一個使用goroutine訪問共用資源，但沒有使用Mutex進行同步的代碼示例：

package main

import (
    "fmt"
    "time"
)

var count int

func main() {
    for i := 0; i < 1000; i++ {
        go add()
    }
    time.Sleep(1 * time.Second)
    fmt.Println("count:", count)
}

func add() {
    count++
}

上述代碼中，我們啟動了1000個goroutine，每個goroutine都調用add()函數將count變數的值加1。由於count變數是共用資源，因此在多個goroutine同時訪問的情況下會出現競態條件。但是由於沒有使用Mutex進行同步，所以會導致count的值無法正確累加，最終輸出的結果也會出現錯誤。

在這個例子中，由於多個goroutine同時訪問count變數，而不進行同步控制，導致每個goroutine都可能讀取到同樣的count值，進行相同的累加操作。這就會導致最終輸出的count值不是期望的結果。如果我們使用Mutex進行同步控制，就可以避免這種競態條件的出現。

2.3.2 使用mutex解決上述問題

下麵是使用Mutex進行同步控制，解決上述代碼中競態條件問題的示例：

package main

import (
    "fmt"
    "sync"
    "time"
)

var (
    count int
    mutex sync.Mutex
)

func main() {
    for i := 0; i < 1000; i++ {
        go add()
    }
    time.Sleep(1 * time.Second)
    fmt.Println("count:", count)
}

func add() {
    mutex.Lock()
    count++
    mutex.Unlock()
}

在上述代碼中，我們在全局定義了一個sync.Mutex類型的變數mutex，用於進行同步控制。在add()函數中，我們首先調用mutex.Lock()方法獲取mutex的鎖，確保只有一個goroutine可以訪問count變數。然後進行加1操作，最後調用mutex.Unlock()方法釋放mutex的鎖，使其他goroutine可以繼續訪問count變數。

通過使用Mutex進行同步控制，我們避免了競態條件的出現，確保了count變數的正確累加。最終輸出的結果也符合預期。

3. 使用註意事項

3.1 Lock/Unlock需要成對出現

下麵是一個沒有成對出現Lock和Unlock的代碼例子：

package main

import (
    "fmt"
    "sync"
)

func main() {
    var mutex sync.Mutex
    go func() {
        mutex.Lock()
        fmt.Println("goroutine1 locked the mutex")
    }()
    go func() {
        fmt.Println("goroutine2 trying to lock the mutex")
        mutex.Lock()
        fmt.Println("goroutine2 locked the mutex")
    }()
}

在上述代碼中，我們創建了一個sync.Mutex類型的變數mutex，然後在兩個goroutine中使用了這個mutex。

在第一個goroutine中，我們調用了mutex.Lock()方法獲取mutex的鎖，但是沒有調用相應的Unlock方法。在第二個goroutine中，我們首先列印了一條信息，然後調用了mutex.Lock()方法嘗試獲取mutex的鎖。由於第一個goroutine沒有釋放mutex的鎖，第二個goroutine就一直阻塞在Lock方法中，一直無法執行。

因此，在使用Mutex的過程中，一定要確保每個Lock方法都有對應的Unlock方法，確保Mutex的正常使用。

3.2 不能對已使用的Mutex作為參數進行傳遞

下麵舉一個已使用的Mutex作為參數進行傳遞的代碼的例子:

type Counter struct {
    sync.Mutex
    Count int
}

func main(){
    var c Counter
    c.Lock()
    defer c.Unlock()
    c.Count++
    foo(c)
    fmt.println("done")
}

func foo(c Counter) {
    c.Lock()
    defer c.Unlock()
    fmt.println("foo done")
}

當一個 mutex 被傳遞給一個函數時，預期的行為應該是該函數在訪問受 mutex 保護的共用資源時，能夠正確地獲取和釋放 mutex，以避免競態條件的發生。

如果我們在Mutex未解鎖的情況下拷貝這個Mutex，就會導致鎖失效的問題。因為Mutex的狀態信息被拷貝了，拷貝出來的Mutex還是處於鎖定的狀態。而在函數中，當要訪問臨界區數據時，首先肯定是先調用Mutex.Lock方法加鎖，而傳入Mutex其實是處於鎖定狀態的，此時函數將永遠無法獲取到鎖。

因此，不能將已使用的Mutex直接作為參數進行傳遞。

3.3 不可重覆調用Lock/UnLock方法

下麵是一個例子，其中對同一個 Mutex 進行了重覆加鎖：

package main

import (
    "fmt"
    "sync"
)

func main() {
    var mu sync.Mutex
    mu.Lock()
    fmt.Println("First Lock")

    // 重覆加鎖
    mu.Lock()
    fmt.Println("Second Lock")

    mu.Unlock()
    mu.Unlock()
}

在這個例子中，我們先對 Mutex 進行了一次加鎖，然後在沒有解鎖的情況下，又進行了一次加鎖操作.

這種情況下，程式會出現死鎖，因為第二次加鎖操作已經被阻塞，等待第一次加鎖的解鎖操作，而第一次加鎖的解鎖操作也被阻塞，等待第二次加鎖的解鎖操作，導致了互相等待的局面，無法繼續執行下去。

Mutex實際上是通過一個int32類型的標誌位來實現的。當這個標誌位為0時，表示這個Mutex當前沒有被任何goroutine獲取；當標誌位為1時，表示這個Mutex當前已經被某個goroutine獲取了。

Mutex的Lock方法實際上就是將這個標誌位從0改為1，表示獲取了鎖；Unlock方法則是將標誌位從1改為0，表示釋放了鎖。當第二次調用Lock方法，此時標記位為1，代表有一個goroutine持有了這個鎖，此時將會被阻塞，而持有該鎖的其實就是當前的goroutine,此時該程式將會永遠阻塞下去。

4. 實踐建議

4.1 Mutex鎖不要同時保護兩份不相關數據

下麵是一個例子，使用Mutex同時保護兩份不相關的數據

// net/http transport.go
type Transport struct {
   lk       sync.Mutex
   idleConn map[string][]*persistConn
   altProto map[string]RoundTripper // nil or map of URI scheme => RoundTripper
}

func (t *Transport) CloseIdleConnections() {
   t.lk.Lock()
   defer t.lk.Unlock()
   if t.idleConn == nil {
      return
   }
   for _, conns := range t.idleConn {
      for _, pconn := range conns {
         pconn.close()
      }
   }
   t.idleConn = nil
}


func (t *Transport) RegisterProtocol(scheme string, rt RoundTripper) {
   if scheme == "http" || scheme == "https" {
      panic("protocol " + scheme + " already registered")
   }
   t.lk.Lock()
   defer t.lk.Unlock()
   if t.altProto == nil {
      t.altProto = make(map[string]RoundTripper)
   }
   if _, exists := t.altProto[scheme]; exists {
      panic("protocol " + scheme + " already registered")
   }
   t.altProto[scheme] = rt
}

在這個例子中，idleConn是存儲了空閑的連接，altProto是存儲了協議的處理器，CloseIdleConnections方法是關閉所有空閑的連接，RegisterProtocol是用於註冊協議處理的。

儘管ideConn和altProto這兩部分數據並沒有任何關聯，但是卻是使用同一個Mutex來保護的，這樣子當調用RegisterProtocol方法時，便無法調用CloseIdleConnections方法，這會導致競爭過多，從而影響性能。

因此，為了提高併發性能，應該將 Mutex 的鎖粒度儘量縮小，只保護需要保護的數據。

現代版本的 net/http 中已經對 Transport 進行了改進，分別使用了不同的 mutex 來保護 idleConn 和 altProto，以提高性能和代碼的可維護性。

type Transport struct {
   idleMu       sync.Mutex
   idleConn     map[connectMethodKey][]*persistConn // most recently used at end

   altMu    sync.Mutex   // guards changing altProto only
   altProto atomic.Value // of nil or map[string]RoundTripper, key is URI scheme   
}

4.2 Mutex嵌入結構體中位置放置建議

將 Mutex 嵌入到結構體中，如果只需要保護其中一些數據，可以將 Mutex 放在需要控制的欄位上面，然後使用空格將被保護欄位和其他欄位進行分隔。這樣可以實現更細粒度的鎖定，也能更清晰地表達每個欄位需要被互斥保護的意圖，代碼更易於維護和理解。下麵舉一些實際的例子:

Server結構體中reqLock是用來保護freeReq欄位，respLock用來保護freeResp欄位，都是將mutex放在被保護欄位的上面

//net/rpc server.go
type Server struct {
   serviceMap sync.Map   // map[string]*service
   reqLock    sync.Mutex // protects freeReq
   freeReq    *Request
   respLock   sync.Mutex // protects freeResp
   freeResp   *Response
}

在Transport結構體中，idleMu鎖會保護closeIdle等一系列欄位，此時將鎖放在被保護欄位的最上面，然後用空格將被idleMu鎖保護的欄位和其他欄位分隔開來。 實現更細粒度的鎖定，也能更清晰地表達每個欄位需要被互斥保護的意圖。

// net/http transport.go
type Transport struct {
   idleMu       sync.Mutex
   closeIdle    bool                                // user has requested to close all idle conns
   idleConn     map[connectMethodKey][]*persistConn // most recently used at end
   idleConnWait map[connectMethodKey]wantConnQueue  // waiting getConns
   idleLRU      connLRU

   reqMu       sync.Mutex
   reqCanceler map[cancelKey]func(error)

   altMu    sync.Mutex   // guards changing altProto only
   altProto atomic.Value // of nil or map[string]RoundTripper, key is URI scheme

   connsPerHostMu   sync.Mutex
   connsPerHost     map[connectMethodKey]int
   connsPerHostWait map[connectMethodKey]wantConnQueue // waiting getConns
}

4.3 儘量減小鎖的作用範圍

在一個代碼段里，儘量減小鎖的作用範圍可以提高併發性能，減少鎖的等待時間，從而減少系統資源的浪費。

鎖的作用範圍越大，那麼就有越多的代碼需要等待鎖，這樣就會降低併發性能。因此，在編寫代碼時，應該儘可能減小鎖的作用範圍，只在需要保護的臨界區內加鎖。

如果鎖的作用範圍是整個函數，使用 defer 語句來釋放鎖是一種常見的做法，可以避免忘記手動釋放鎖而導致的死鎖等問題。

func (t *Transport) CloseIdleConnections() {
   t.lk.Lock()
   defer t.lk.Unlock()
   if t.idleConn == nil {
      return
   }
   for _, conns := range t.idleConn {
      for _, pconn := range conns {
         pconn.close()
      }
   }
   t.idleConn = nil
}

在使用鎖時，註意避免在鎖內執行長時間運行的代碼或者IO操作，因為這樣會阻塞鎖的使用，導致鎖的等待時間變長。如果確實需要在鎖內執行長時間運行的代碼或者IO操作，可以考慮將鎖釋放，讓其他代碼先執行，等待操作完成後再重新獲取鎖, 比如下麵代碼示例

// net/http/httputil persist.go
func (cc *ClientConn) Read(req *http.Request) (resp *http.Response, err error) {
   // Retrieve the pipeline ID of this request/response pair
   cc.mu.Lock()
   id, ok := cc.pipereq[req]
   delete(cc.pipereq, req)
   if !ok {
      cc.mu.Unlock()
      return nil, ErrPipeline
   }
   cc.mu.Unlock()
    
    // xxx 省略掉一些中間邏輯

   // 從http連接中讀取http響應數據, 這個IO操作,先解鎖
   resp, err = http.ReadResponse(r, req)
   // 網路IO操作結束,再繼續讀取
   
   cc.mu.Lock()
   defer cc.mu.Unlock()
   if err != nil {
      cc.re = err
      return resp, err
   }
   cc.lastbody = resp.Body

   cc.nread++

   if resp.Close {
      cc.re = ErrPersistEOF // don't send any more requests
      return resp, cc.re
   }
   return resp, err
}

5.總結

在併發編程中，Mutex是一種常見的同步機制，用來保護共用資源。為了提高併發性能，我們需要儘可能縮小Mutex的鎖粒度，只保護需要保護的數據，同時在一個代碼段里，儘量減小鎖的作用範圍。如果鎖的作用範圍是整個函數，可以使用defer來在函數退出時解鎖。當Mutex嵌入到結構體中時，我們可以將Mutex放到要控制的欄位上面，並使用空格將欄位進行分隔，以便只保護需要保護的數據。


您的分享是我們最大的動力!

-Advertisement-
Play Games
更多相關文章
  • python策略模式場景
    觀察者模式 介紹 觀察者模式是極其重要的一個設計模式，在許多框架都使用了，以及實際開發中也會用到。 定義對象之間的一種一對多的依賴關係，使得每當一個對象的狀態發生變化時，其相關的依賴對象都可以得到通知並被自動更新。主要用於多個不同的對象對一個對象的某個方法會做出不同的反應！ 以不同觀察者從同一個天氣 ...
  • 讀Java性能權威指南（第2版）筆記18_垃圾回收E
    1. 回收 1.1. 找到不使用的對象 1.2. 釋放它們的記憶體 1.3. 壓縮堆 1.4. 合在一起稱為回收 2. Throughput回收器 2.1. 工作細節比較簡單 2.1.1. 可以在同一個GC周期內完成回收 2.1.2. 在單次操作過程中回收新生代或老年代 2.2. Minor GC 2 ...
  • Bokeh 環境設置
    背景 業務系統開發時，你是否踩過這樣的坑： 業務說列表篩選姓名精準查詢查不到人？ 導入數據時，明明看起來一樣的ID卻匹配不到DB里的數據？ 看起來一樣的內容，SQL Group By 時出現好幾行？ …… DEBUG後發現，原來要麼時用戶傳入或者導入的數據里有個空格，要麼是資料庫里不知道什麼時候已經 ...
  • springboot+vue學習筆記
    P1 環境搭建 包括java,idea,maven配置,以及在idea中配置maven。 註：在files->New Project Settings中配置maven路徑，jdk版本1.8，不然重啟會失效 P2 創建springboot項目，熱部署 1、創建springboot項目時type選Mav ...
  • Python判斷列表裡是否有重覆元素的三種方法
    一、用set方法去重後與原列表長度比較 set會生成一個元素無序且不重覆的可迭代對象，也就是我們常說的去重set會生成一個元素無序且不重覆的可迭代對象，也就是我們常說的去重 lst = [1,3,5,3,4,4,2,9,6,7] set_lst=set(lst) if len(set_lst)==l ...
  • 基於 SpringBoot+vue的地方美食系統，可作為畢業設計
    1 簡介 這個項目是基於 SpringBoot和 Vue 開發的地方美食系統，包括系統功能模塊，管理員功能模塊，用戶管理模塊，功能齊全，可以作為畢業設計，課程設計等。源碼下載下來，進行一些簡單的部署，就可以使用，都有對應的教程。 2 技術棧 開發語言：Java 框架：springboot JDK版本 ...
  • Python+ChatGPT實戰之進行游戲運營數據分析
    最近ChatGPT蠻火的，今天試著讓ta寫了一篇數據分析實戰案例，大家來評價一下！ 一、數據 您的團隊已經為您提供了一些游戲數據，包括玩家的行為和收入情況。以下是數據的一些特征： user_id: 玩家ID date: 游戲日期 level: 玩家達到的游戲等級 revenue: 玩家在游戲中花費的 ...
  • 【開源免費】使用Spring Boot和Html實現ChatGPT，1：億還原，將就看
    highlight: a11y-dark 簡介 前段時間寫了一個Chatgpt的Java版SDK開源地址：chatgpt-java歡迎使用。但由於原來OpenAI 並沒有支持官網的chatgpt模型，所以使用起來相對沒有官網那麼智能完善，所以就沒有寫出一個demo項目，只開源了Open AI的SDK ...
一周排行
    -Advertisement-
    Play Games
  • 移動開發（一）：使用.NET MAUI開發第一個安卓APP
    移動開發（一）：使用.NET MAUI開發第一個安卓APP 對於工作多年的C#程式員來說，近來想嘗試開發一款安卓APP，考慮了很久最終選擇使用.NET MAUI這個微軟官方的框架來嘗試體驗開發安卓APP，畢竟是使用Visual Studio開發工具，使用起來也比較的順手，結合微軟官方的教程進行了安卓 ...
  • wpf ToggleButton選中效果和一個登錄界面
    前言 QuestPDF 是一個開源 .NET 庫，用於生成 PDF 文檔。使用了C# Fluent API方式可簡化開發、減少錯誤並提高工作效率。利用它可以輕鬆生成 PDF 報告、發票、導出文件等。 項目介紹 QuestPDF 是一個革命性的開源 .NET 庫，它徹底改變了我們生成 PDF 文檔的方 ...
  • 彈幕樹洞項目功能新增篇
    項目地址 項目後端地址： https://github.com/ZyPLJ/ZYTteeHole 項目前端頁面地址： ZyPLJ/TreeHoleVue (github.com) https://github.com/ZyPLJ/TreeHoleVue 目前項目測試訪問地址： http://tree ...
  • 第27篇 sqlserver2022詳細安裝步驟
    話不多說，直接開乾 一.下載 1.官方鏈接下載： https://www.microsoft.com/zh-cn/sql-server/sql-server-downloads 2.在下載目錄中找到下麵這個小的安裝包 SQL2022-SSEI-Dev.exe，運行開始下載SQL server； 二. ...
  • .NET 開源高性能 MQTT 類庫
    前言 隨著物聯網（IoT）技術的迅猛發展，MQTT（消息隊列遙測傳輸）協議憑藉其輕量級和高效性，已成為眾多物聯網應用的首選通信標準。 MQTTnet 作為一個高性能的 .NET 開源庫，為 .NET 平臺上的 MQTT 客戶端與伺服器開發提供了強大的支持。 本文將全面介紹 MQTTnet 的核心功能 ...
  • Serilog文檔翻譯系列（六） - 可用的接收器、增強器、格式化輸出
    Serilog支持多種接收器用於日誌存儲，增強器用於添加屬性，LogContext管理動態屬性，支持多種輸出格式包括純文本、JSON及ExpressionTemplate。還提供了自定義格式化選項，適用於不同需求。 ...
  • 警惕 Visual Studio 屬性求值副作用導致邏輯不符合預期
    目錄簡介獲取 HTML 文檔解析 HTML 文檔測試參考文章 簡介 動態內容網站使用 JavaScript 腳本動態檢索和渲染數據，爬取信息時需要模擬瀏覽器行為，否則獲取到的源碼基本是空的。 本文使用的爬取步驟如下： 使用 Selenium 獲取渲染後的 HTML 文檔 使用 HtmlAgility ...
  • [使用目前最新版]HybridCLR6.9.0+YooAsset2.2.4實現純C# Unity熱更新方案 (一)
    1.前言 什麼是熱更新 游戲或者軟體更新時，無需重新下載客戶端進行安裝，而是在應用程式啟動的情況下，在內部進行資源或者代碼更新 Unity目前常用熱更新解決方案 HybridCLR，Xlua，ILRuntime等 Unity目前常用資源管理解決方案 AssetBundles，Addressable， ...
  • 在 ASP.NET Core Web API 中使用操作篩選器統一處理通用操作
    本文章主要是在C# ASP.NET Core Web API框架實現向手機發送驗證碼簡訊功能。這裡我選擇是一個互億無線簡訊驗證碼平臺，其實像阿裡雲，騰訊雲上面也可以。 首先我們先去 互億無線 https://www.ihuyi.com/api/sms.html 去註冊一個賬號 註冊完成賬號後，它會送 ...
  • 第28篇 如何.net中實現高效可靠數據同步api
    通過以下方式可以高效，並保證數據同步的可靠性 1.API設計 使用RESTful設計，確保API端點明確，並使用適當的HTTP方法（如POST用於創建，PUT用於更新）。 設計清晰的請求和響應模型，以確保客戶端能夠理解預期格式。 2.數據驗證 在伺服器端進行嚴格的數據驗證，確保接收到的數據符合預期格 ...
所有分類