4種Golang併發操作中常見的死鎖情形

華為雲開發者社群發表於2021-09-01
摘要:什麼是死鎖,在Go的協程裡面死鎖通常就是永久阻塞了,你拿著我的東西,要我先給你然後再給我,我拿著你的東西又讓你先給我,不然就不給你。我倆都這麼想,這事就解決不了了。

本文分享自華為雲社群《Golang併發操作中常見的死鎖情形》,作者:Regan Yue 。

什麼是死鎖,在Go的協程裡面死鎖通常就是永久阻塞了,你拿著我的東西,要我先給你然後再給我,我拿著你的東西又讓你先給我,不然就不給你。我倆都這麼想,這事就解決不了了。

第一種情形:無快取能力的管道,自己寫完自己讀

先上程式碼:

func main() {
    ch := make(chan int, 0)

    ch <- 666
    x := <- ch
    fmt.Println(x)
}

我們可以看到這是一個沒有快取能力的管道,然後往裡面寫666,然後就去管道里面讀。這樣肯定會出現問題啊!一個無快取能力的管道,沒有人讀,你也寫不了,沒有人寫,你也讀不了,這正是一種死鎖!

fatal error: all goroutines are asleep - deadlock!

解決辦法很簡單,開闢兩條協程,一條協程寫,一條協程讀。

第二種情形:協程來晚了

func main() {
    ch := make(chan int,0)
    ch <- 666
    go func() {
        <- ch
    }()
}

我們可以看到,這條協程開闢在將數字寫入到管道之後,因為沒有人讀,管道就不能寫,然後寫入管道的操作就一直阻塞。這時候你就有疑惑了,不是開闢了一條協程在讀嗎?但是那條協程開闢在寫入管道之後,如果不能寫入管道,就開闢不了協程。

第三種情形:管道讀寫時,相互要求對方先讀/寫

如果相互要求對方先讀/寫,自己再讀/寫,就會造成死鎖。

func main() {
    chHusband := make(chan int,0)
    chWife := make(chan int,0)

    go func() {
        select {
        case <- chHusband:
            chWife<-888
        }
    }()

    select {
        case <- chWife:
            chHusband <- 888
    }
}

先來看看老婆協程,chWife只要能讀出來,也就是老婆有錢,就給老公發個八百八十八的大紅包。

再看看老公的協程,一看不得了,咋啦?老公也說只要他有錢就給老婆包個八百八十八的大紅包。

兩個人都說自己沒錢,老公也給老婆發不了紅包,老婆也給老公發不了紅包,這就是死鎖!

第四種情形:讀寫鎖相互阻塞,形成隱形死鎖

先來看一看程式碼:

func main() {
    var rmw09 sync.RWMutex
    ch := make(chan int,0)

    go func() {
        rmw09.Lock()
        ch <- 123
        rmw09.Unlock()
    }()

    go func() {
        rmw09.RLock()
        x := <- ch
        fmt.Println("讀到",x)
        rmw09.RUnlock()
    }()

    for {
        runtime.GC()
    }
}

這兩條協程,如果第一條協程先搶到了只寫鎖,另一條協程就不能搶只讀鎖了,那麼因為另外一條協程沒有讀,所以第一條協程就寫不進。

如果第二條協程先搶到了只讀鎖,另一條協程就不能搶只寫鎖了,那麼因為另外一條協程沒有寫,所以第二條協程就讀不到。

 

點選關注,第一時間瞭解華為雲新鮮技術~

相關文章