為什麼加了鎖的代碼偶爾還會導致panic: send on closed channel？

Go語言加鎖代碼偶爾出現panic: send on closed channel的原因分析

在Go語言並發編程中，使用鎖(mutex)保證線程安全是常見做法，但即使使用了鎖，仍然可能遇到panic: send on closed channel錯誤。本文分析此問題出現的原因及解決方案。

問題代碼及現象

以下代碼片段演示了該問題：

 package main

import (
    "context"
    "fmt"
    "sync"
)

var lock sync.Mutex

func main() {
    c := make(chan int, 10)
    wg := sync.WaitGroup{}
    ctx, cancel := context.WithCancel(context.Background())

    wg.Add(1)
    go func() {
        defer wg.Done()
        lock.Lock()
        cancel()
        close(c)
        lock.Unlock()
    }()

    for i := 0; i <p>儘管使用了<code>lock.Lock()</code>和<code>lock.Unlock()</code>保護臨界區，但程序仍然可能在<code>c 處panic，因為<code>select</code>語句的非確定性行為。</code></p><h4 id="問題分析">問題分析</h4><p>Go語言<code>select</code>語句具有非確定性：如果多個case都準備好接收或發送， <code>select</code>會隨機選擇一個執行。</p><p>關鍵在於：</p><ol>
<li><p> <strong><code>close(c)</code>和<code>c 的競爭:</code></strong> <code>close(c)</code>操作和<code>c 操作並非原子操作，存在競爭條件。即使加了鎖， <code>close(c)</code>操作可能在<code>c 操作之後執行，導致<code>c 嘗試向已關閉的通道發送數據，從而引發panic。</code></code></code></p></li>
<li><p> <strong><code>select</code>語句的隨機性:</strong>即使<code>ctx.Done()</code>已經準備好， <code>select</code>仍然可能隨機選擇<code>c 執行。</code></p></li>
</ol><h4 id="解決方案">解決方案</h4><p>為了避免此問題，需要確保在發送數據前檢查通道是否已關閉。 可以使用<code>select</code>語句的默認case來實現：</p><pre class="brush:php;toolbar:false"> select {
case c <p>或者，使用一個額外的通道來協調關閉操作：</p><pre class="brush:php;toolbar:false"> package main

import (
    "fmt"
    "sync"
)

func main() {
    c := make(chan int, 10)
    done := make(chan struct{})
    wg := sync.WaitGroup{}

    wg.Add(1)
    go func() {
        defer wg.Done()
        close(done) // Signal that the channel is closing
        close(c)
    }()

    for i := 0; i <p>這個改進的版本使用<code>done</code>通道來通知goroutine通道即將關閉，避免了競爭條件。</p><p>通過以上方法，可以有效地避免<code>panic: send on closed channel</code>錯誤，即使在並發環境下使用鎖。 選擇哪種解決方案取決於具體的應用場景和代碼複雜度。</p>

以上是為什麼加了鎖的代碼偶爾還會導致panic: send on closed channel？的詳細內容。更多資訊請關注PHP中文網其他相關文章！