為什麼 Go 的 select 用例中的鍊式通道操作會導致死鎖？

單一select 案例中的鍊式通道操作：解碼行為

為了設計並發和非同步程序，Go 的select 構造提供了多路復用通道的強大工具。然而，在單一 select case 中組合多個操作時，經常會遇到意想不到的結果。

考慮以下場景：兩個通道 A 和 B 以不同的時間間隔發送訊息（A 為 10 毫秒，A 為 1 秒） B）。我們使用 select 來監聽兩個通道，並將接收到的值轉發到扇入通道。

func main() {
    ch := fanIn(talk("A", 10), talk("B", 1000))

    for i := 0; i < 10; i++ {
        fmt.Printf("%q\n", <-ch)
    }
    fmt.Printf("Done\n")
}

預期結果是：

"A 0"
"B 0"
"A 1"
"A 2"
"A 3"
"A 4"
"B 1"
"B 2"
"B 3"
"B 4"
Done

但是，當我們修改 select時使用鍊式通道操作的情況：

select {
    case ch <- <-input1:
    case ch <- <-input2:
}

我們觀察到一個特殊的情況行為：

"B 0"
"A 1"
"B 2"
"A 3"
"A 4"
fatal error: all goroutines are asleep - deadlock!

幕後

理解此行為的關鍵在於選擇案例中通道操作的非阻塞性質。在典型的選擇情況下，只有一個通道操作（讀取或寫入）可以是非阻塞的。

當我們使用鍊式通道操作時，我們實際上是在單一情況下嘗試多個通道操作。第一個操作總是阻塞的，而後續操作是非阻塞的。

在我們修改後的程式碼中，第一個操作會阻塞以從 input1 接收值。收到值後，它會嘗試將其非阻塞地寫入 ch 通道。但是，如果 ch 通道的接收者還沒有準備好接受該值，則寫入操作將會失敗。

連鎖反應

失敗的寫入操作不會停止選擇案例。相反，它轉向第二種情況，這是現在唯一可行的情況。這會導致潛在的死鎖情況。

隨著時間的推移，會收到來自兩個通道的多個值，但由於寫入失敗而不會轉發到扇入通道。因此，扇入通道最終會變空，從而導致死鎖，因為無法接收更多值。

解決問題

為了避免此問題，它對於確保選擇案例中的通道操作序列執行至關重要。這可以透過使用臨時變數來儲存接收的值，然後在 select case 之外作為單獨的語句執行寫入操作來實現。

var msg string
select {
    case msg = <-input1:
    case msg = <-input2:
}

ch <- msg

以上是為什麼 Go 的 select 用例中的鍊式通道操作會導致死鎖？的詳細內容。更多資訊請關注PHP中文網其他相關文章！