如何使用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
  • GoF之工廠模式
    GoF之工廠模式 @目錄GoF之工廠模式每博一文案1. 簡單說明“23種設計模式”1.2 介紹工廠模式的三種形態1.3 簡單工廠模式（靜態工廠模式）1.3.1 簡單工廠模式的優缺點:1.4 工廠方法模式1.4.1 工廠方法模式的優缺點:1.5 抽象工廠模式1.6 抽象工廠模式的優缺點：2. 總結:3 ...
  • dotnet C# 簡單的追加文件夾到 ZipArchive 壓縮文件的方法
    新改進提供的Taurus Rpc 功能，可以簡化微服務間的調用，同時可以不用再手動輸出模塊名稱，或調用路徑，包括負載均衡，這一切，由框架實現並提供了。新的Taurus Rpc 功能，將使得服務間的調用，更加輕鬆、簡約、高效。 ...
  • Elasticsearch 系列（六）- ES數據同步和ES集群
    本章將和大家分享ES的數據同步方案和ES集群相關知識。廢話不多說，下麵我們直接進入主題。 一、ES數據同步 1、數據同步問題 Elasticsearch中的酒店數據來自於mysql資料庫，因此mysql數據發生改變時，Elasticsearch也必須跟著改變，這個就是Elasticsearch與my ...
  • 自動化測試數據生成：Asp.Net Core單元測試利器AutoFixture詳解
    引言 在我們之前的文章中介紹過使用Bogus生成模擬測試數據，今天來講解一下功能更加強大自動生成測試數據的工具的庫"AutoFixture"。 什麼是AutoFixture? AutoFixture 是一個針對 .NET 的開源庫，旨在最大程度地減少單元測試中的“安排（Arrange）”階段，以提高 ...
  • .NET Emit 入門教程：第七部分：實戰項目1：將 DbDataReader 轉實體
    經過前面幾個部分學習，相信學過的同學已經能夠掌握 .NET Emit 這種中間語言，並能使得它來編寫一些應用，以提高程式的性能。隨著 IL 指令篇的結束，本系列也已經接近尾聲，在這接近結束的最後，會提供幾個可供直接使用的示例，以供大伙分析或使用在項目中。 ...
  • Windows下綁定線程到指定的CPU核心
    當從不同來源導入Excel數據時，可能存在重覆的記錄。為了確保數據的準確性，通常需要刪除這些重覆的行。手動查找並刪除可能會非常耗費時間，而通過編程腳本則可以實現在短時間內處理大量數據。本文將提供一個使用C# 快速查找並刪除Excel重覆項的免費解決方案。 以下是實現步驟： 1. 首先安裝免費.NET ...
  • mORMot 1.18 第07章 簡單的讀寫操作
    C++ 異常處理 C++ 異常處理機制允許程式在運行時處理錯誤或意外情況。它提供了捕獲和處理錯誤的一種結構化方式，使程式更加健壯和可靠。 異常處理的基本概念： 異常: 程式在運行時發生的錯誤或意外情況。 拋出異常: 使用 throw 關鍵字將異常傳遞給調用堆棧。 捕獲異常: 使用 try-catch ...
  • mORMot 1.18 第06章 概念
    優秀且經驗豐富的Java開發人員的特征之一是對API的廣泛瞭解，包括JDK和第三方庫。 我花了很多時間來學習API，尤其是在閱讀了Effective Java 3rd Edition之後 ，Joshua Bloch建議在Java 3rd Edition中使用現有的API進行開發，而不是為常見的東西編 ...
  • php 開發規範
    框架 · 使用laravel框架，原因：tp的框架路由和orm沒有laravel好用 · 使用強制路由，方便介面多時，分多版本，分文件夾等操作 介面 · 介面開發註意欄位類型，欄位是int，查詢成功失敗都要返回int（對接java等強類型語言方便） · 查詢介面用GET、其他用POST 代碼 · 所 ...
  • 2024 年 4 月 28 日 周日 晴 熱（1253 字）
    正文 下午找企業的人去鎮上做貸後。 車上聽同事跟那個司機對罵，火星子都快出來了。司機跟那同事更熟一些，連我在內一共就三個人，同事那一手指桑罵槐給我都聽愣了。司機也是老社會人了，馬上聽出來了，為那個無辜的企業經辦人辯護，實際上是為自己辯護。 “這個事情你不能怪企業。”“但他們總不能讓銀行的人全權負責， ...
所有分類