為什麼 Go 中 `recover` 無法處理並發地圖修改當機？

處理並發地圖修改：恢復與運行時崩潰的困境

在處理並發地圖訪問時，可能會遇到一種特殊的情況：從「並發映射讀取和映射寫入」恐慌中恢復似乎是徒勞的。這是因為運行時在這種情況下的行為不是恐慌，而是故意崩潰。

在 Go 1.6 中，運行時引入了並發濫用映射的檢測機制。如果多個 goroutine 嘗試同時修改映射，則運行時會觸發崩潰，並列印診斷訊息。這種行為源自於同時存取映射進行寫入操作時潛在的未定義行為的固有危險。

不幸的是，使用 defer 和恢復來處理恐慌的典型方法在這種情況下是無效的。恢復函數無法攔截運行時發起的崩潰。建議的解決方案是完全防止並發濫用映射。

在提供的範例中：

package main

import "time"

var m = make(map[string]string)

func main() {
    go func() {
        for {
            m["x"] = "foo"
        }
    }()
    go func() {
        for {
            m["x"] = "foo"
        }
    }()

    time.Sleep(1 * time.Second)
}

對映射「m」的並發寫入將觸發運行時崩潰。為了防止這種情況，需要採用同步機制，例如使用互斥體或通道，以確保在寫入作業期間對映射的獨佔存取。

以上是為什麼 Go 中 `recover` 無法處理並發地圖修改當機？的詳細內容。更多資訊請關注PHP中文網其他相關文章！